[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 20:11:27 UTC 2023 

Hi Andrew,

I will do so, and let you know.

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

From: Andrew Bartlett <abartlet at samba.org>
Sent: Wednesday, September 20, 2023 11:57 AM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>; metze <metze at samba.org>; Ralph Böhme (samba) <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: Re: [cifs-protocol] [EXTERNAL] Re: [MS-NRPC] 3.1.4.1 Session-Key Negotiation lacking details - TrackingID#2309080040007879

Thanks so much for your time and investigation Jeff,

Please do continue to investigate, yes, this is the correct area we need described.

We know that windows will fail if step 14 does not get the 'correct (for a server that does not implement level 2)' error code from <197> step 2.  But if it does get the 'correct' fault/error code, what is the correct way to know that the negotiation was still fit to continue against a down-level server.   That is, we are missing a step 16 for the client behaviour in the failure case on 14/15.

We need more than initial assumptions as this is a security behaviour we need to get right, while maintaining service against both patched and unpatched (Samba is not yet patched on the server side) servers.

Thanks,

Andrew Bartlett

On Wed, 2023-09-20 at 18:37 +0000, Jeff McCashland (He/him) via cifs-protocol wrote:

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>

http://support.microsoft.com/globalenglish


 | Extension 1138300



-----Original Message-----

From: Andrew Bartlett <
<mailto:abartlet at samba.org>

abartlet at samba.org<mailto:abartlet at samba.org>


>

Sent: Monday, September 18, 2023 3:04 PM

To: Jeff McCashland (He/him) <
<mailto:jeffm at microsoft.com>

jeffm at microsoft.com<mailto:jeffm at microsoft.com>


>; metze <
<mailto:metze at samba.org>

metze at samba.org<mailto:metze at samba.org>


>; Ralph Böhme <
<mailto:slow at samba.org>

slow at samba.org<mailto:slow at samba.org>


>

Cc:
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>


; Microsoft Support <
<mailto:supportmail at microsoft.com>

supportmail at microsoft.com<mailto: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/>

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 <
<mailto:metze at samba.org>

metze at samba.org<mailto:metze at samba.org>




; Ralph Böhme <
<mailto:slow at samba.org>

slow at samba.org<mailto:slow at samba.org>






Cc:
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>




; Microsoft Support <
<mailto:supportmail at microsoft.com>

supportmail at microsoft.com<mailto: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/>

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 <
<mailto:metze at samba.org>

metze at samba.org<mailto:metze at samba.org>




; Ralph Böhme <
<mailto:slow at samba.org>

slow at samba.org<mailto:slow at samba.org>






Cc:
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>




; Microsoft Support <
<mailto:supportmail at microsoft.com>

supportmail at microsoft.com<mailto: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/>

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 <
<mailto:metze at samba.org>

metze at samba.org<mailto:metze at samba.org>






Sent: Thursday, September 7, 2023 11:27 PM

To: Jeff McCashland (He/him) <
<mailto:jeffm at microsoft.com>

jeffm at microsoft.com<mailto:jeffm at microsoft.com>




; Ralph Böhme <
<mailto:slow at samba.org>

slow at samba.org<mailto:slow at samba.org>






Cc:
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto: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
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>





<https://list/>

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/>

https://samba.org/~abartlet/




Samba Team Member (since 2001)
<https://samba.org/>

https://samba.org/




Samba Team Lead
<https://catalyst.net.nz/services/samba>

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>

https://catalyst.net.nz/services/samba






Catalyst IT - Expert Open Source Solutions







_______________________________________________

cifs-protocol mailing list
<mailto:cifs-protocol at lists.samba.org>

cifs-protocol at lists.samba.org<mailto:cifs-protocol at lists.samba.org>



<https://lists.samba.org/mailman/listinfo/cifs-protocol>

https://lists.samba.org/mailman/listinfo/cifs-protocol




--
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20230920/c04c57e4/attachment.htm>

More information about the cifs-protocol mailing list