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 <abart...@samba.org>
Sent: Monday, September 18, 2023 3:04 PM
To: Jeff McCashland (He/him) <je...@microsoft.com>; metze <me...@samba.org>;
Ralph Böhme <s...@samba.org>
Cc: cifs-protocol@lists.samba.org; Microsoft Support <supportm...@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 <
> me...@samba.org
> >; Ralph Böhme <
> s...@samba.org
> >
> Cc:
> cifs-protocol@lists.samba.org
> ; Microsoft Support <
> supportm...@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 <
> me...@samba.org
> >; Ralph Böhme <
> s...@samba.org
> >
> Cc:
> cifs-protocol@lists.samba.org
> ; Microsoft Support <
> supportm...@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 <
> me...@samba.org
> >
> Sent: Thursday, September 7, 2023 11:27 PM
> To: Jeff McCashland (He/him) <
> je...@microsoft.com
> >; Ralph Böhme <
> s...@samba.org
> >
> Cc:
> cifs-protocol@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@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
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
