[cifs-protocol] [EXTERNAL] Re: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details - TrackingID#2309080040007879
Jeff McCashland (He/him)
jeffm at microsoft.com
Wed Sep 20 18:37:31 UTC 2023
Hi Andrew,
Just to be clear, are you referring to this behavior note for section 3.5.4.4.10 NetrLogonGetCapabilities (Opnum 21)?:
<197> Section 3.5.4.4.10: Windows RPC layer may return its own error code instead of STATUS_INVALID_LEVEL. The error code that a client gets depends on where the calling application is getting the error from:
1. If the client is running on Windows and calling Windows RPC APIs, they may get the Win32 error code RPC_S_INVALID_TAG ([MS-ERREF] section 2.2).
2. If the client is running on third-party operating systems or getting the error code from the wire, they may get nca_s_fault_invalid_tag (0x1C000006). ([C706-RSCP]).
3. The conversion between the on-the-wire nca_s_fault_invalid_tag and Win32 error code RPC_S_INVALID_TAG is specified in [MS-RPCE] section 3.1.1.5.5.
Since the original question cited section 3.1.4.1 Session-Key Negotiation, I gather you're asking how the Client should proceed if an error is returned from NetrLogonGetCapabilities in Session-Key Negotiation steps 11 and/or 14, and if the behavior is different based on the different possible errors returned.
3.1.4.1 Session-Key Negotiation
Session-key negotiation between a client and a server is performed over an unprotected RPC channel.
The following diagram illustrates the negotiation flow.
[...]
11. The client calls the NetrLogonGetCapabilities method to get Negotiaged flags by setting QueryLevel to 1 (section 3.4.5.2.10).
12. The server SHOULD<72> return the negotiated flags for the current exchange.
13. The client SHOULD<73> compare the received ServerCapabilities (section 3.5.4.4.10) with the negotiated NegotiateFlags (section 3.5.4.4.2), and if there is a difference, the session key negotiation is aborted.
14. The client calls the NetrLogonGetCapabilities method to get Requested flags by setting QueryLevel to 2 (section 3.4.5.2.10).
15. The server SHOULD<74> return the client capabilities received during a negotiation request from client.
Since returning the results is stated as SHOULD, my initial assumption is that if an error is returned, the client simply does not return results.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
-----Original Message-----
From: Andrew Bartlett <abartlet at samba.org>
Sent: Monday, September 18, 2023 3:04 PM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>; metze <metze at samba.org>; Ralph Böhme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: [EXTERNAL] Re: [cifs-protocol] [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details - TrackingID#2309080040007879
So, what metze is getting as is that the details of what to do if the behaviour in note <197> is triggered. If the correct fault (mapped to an error code) is received by the client, due to noticing an older unpatched server (or Samba), what is the secure and correct behaviour?
Andrew Bartlett
On Mon, 2023-09-18 at 15:55 +0000, Jeff McCashland (He/him) via cifs- protocol wrote:
> Hi Metze,
>
> I haven't seen any response to my request below.
>
> Could you give me an idea of when you may be able to provide more
> information on your [MS-NRPC] concern?
>
> Best regards,
> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
> Protocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-
> 08:00) Pacific Time (US and Canada)
> Local country phone number found here:
> http://suppo/
> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%
> 7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserved=0
> | Extension 1138300
>
> -----Original Message-----
> From: Jeff McCashland (He/him)
> Sent: Tuesday, September 12, 2023 3:49 PM
> To: Stefan Metzmacher <
> metze at samba.org
> >; Ralph Böhme <
> slow at samba.org
> >
> Cc:
> cifs-protocol at lists.samba.org
> ; Microsoft Support <
> supportmail at microsoft.com
> >
> Subject: RE: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details
> - TrackingID#2309080040007879
>
> Hi Metze,
>
> I have reviewed [MS-NRPC] section 3.1.4.1 Session-Key negotiation, and
> I don't seen any mention of downgrade at all. I admit this is a
> document I'm not deeply familiar with.
>
> Could you specify which steps you are referring to, what you mean by a
> downgrade, and specifically where you feel more detail is needed?
>
> Best regards,
> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
> Protocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-
> 08:00) Pacific Time (US and Canada) Local country phone number found
> here:
> http://suppo/
> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%
> 7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserved=0
> | Extension 1138300
>
> -----Original Message-----
> From: Jeff McCashland (He/him)
> Sent: Friday, September 8, 2023 1:46 PM
> To: Stefan Metzmacher <
> metze at samba.org
> >; Ralph Böhme <
> slow at samba.org
> >
> Cc:
> cifs-protocol at lists.samba.org
> ; Microsoft Support <
> supportmail at microsoft.com
> >
> Subject: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details -
> TrackingID#2309080040007879
>
> [support on CC, updated Subject with new SR ID]
>
> Hi Metze,
>
> We have created SR 2309080040007879 to track this issue. I will look
> into it and get back to you.
>
> Best regards,
> Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
> Protocol Open Specifications Team
> Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-
> 08:00) Pacific Time (US and Canada) Local country phone number found
> here:
> http://suppo/
> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%
> 7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=4gRUKI2XhxFHCTSs0ELokyBuTZ700fJgxsJ2n5AJmB0%3D&reserved=0
> | Extension 1138300
>
> -----Original Message-----
> From: Stefan Metzmacher <
> metze at samba.org
> >
> Sent: Thursday, September 7, 2023 11:27 PM
> To: Jeff McCashland (He/him) <
> jeffm at microsoft.com
> >; Ralph Böhme <
> slow at samba.org
> >
> Cc:
> cifs-protocol at lists.samba.org
>
> Subject: [EXTERNAL] Re: [MS-NRPC] DCERPC_NCA_S_FAULT_INVALID_TAG
> returned instead of STATUS_INVALID_LEVEL -
> TrackingID#2307200040007944
>
> Hi Jeff,
>
> > We have updated [MS-NRPC] for the next release to address this
> > issue. We have added the following Behavior Note to section
> > 3.5.4.4.10:
> >
> > <197> Section 3.5.4.4.10: Windows RPC layer may return its own error
> > code instead of STATUS_INVALID_LEVEL. The error code that a client
> > gets depends on where the calling application is getting the error
> > from:
> > 1. If the client is running on Windows and calling Windows RPC APIs,
> > they may get the Win32 error code RPC_S_INVALID_TAG ([MS- ERREF]
> > section 2.2).
> > 2. If the client is running on third-party operating systems or
> > getting the error code from the wire, they may get
> > nca_s_fault_invalid_tag (0x1C000006). ([C706-RSCP] DCE 1.1: Remote
> > Procedure Call - Reject Status Codes and Parameters).
> > 3. The conversion between the on-the-wire nca_s_fault_invalid_tag
> > and Win32 error code RPC_S_INVALID_TAG is specified in [MS-RPCE]
> > Section 3.1.1.5.5.
> >
> > I hope that helps.
>
> Yes, thanks!
>
> In addition I think 3.1.4.1 Session-Key Negotiation could be much more
> verbose in a way that it would describe how safe downgrade is possible
> and how an unsafe downgrade is detected.
>
> metze
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
>
> https://list/
> s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C01%7Cjeffm%
> 40microsoft.com%7C0c04f797e40e47e482ff08dbb8931c2c%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C638306714208453677%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7C&sdata=RhwUpKut09WPrb1%2FkCcelIzwPXoG0g4u8%2B8K%2BRAKbY8%3D
> &reserved=0
>
--
Andrew Bartlett (he/him) https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org/
Samba Team Lead https://catalyst.net.nz/services/samba
Catalyst.Net Ltd
Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company
Samba Development and Support: https://catalyst.net.nz/services/samba
Catalyst IT - Expert Open Source Solutions
More information about the cifs-protocol
mailing list