Thank you very much for your considerations. I have filed a documentation change request against [MS-NLMP] concerning NTLMSSP InitialContextTokens (see 'Expected' below)..
============================================================================== Change Comment / Request: The documentation updates so far have addressed the fact that the Windows implementation accepts raw NTLM SSP tokens that are not correctly embedded in GSS InitialContextTokens. However, I don't recall any updates addressing the fact that the Windows implementation does not accept well-formed GSS InitialContextTokens containing NTLM SSP. This could probably be addressed by updating [MS-NLMP] somewhere to indicate that the NTLM implementation of GSS_Init_sec_context() never outputs a GSS InitialContextToken for the first token, and GSS_Accept_sec_context() does not accept well-formed GSS InitialContextTokens. Updating [MS-NLMP] this way would address both the behavior with and without SPNEGO, since SPNEGO should merely be invoking GSS_Init_sec_context()/GSS_Accept_sec_context() to handle the inner NTLM SSP mechToken. The "Universal Receiver" section of [MS-SPNG] probably wouldn't even be relevant anymore. I'm not sure where the best place in [MS-NLMP] would be to mention this. Section 1.4 talks about the GSS-API interface to NTLM. It references section 3.4.6, but that only talks about the GSS_WrapEx() call. ============================================================================== Ref: The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism http://www.ietf.org/rfc/rfc4178.txt?number=4178 3.2. Negotiation Procedure If the initiator's preferred mechanism is accepted, and an optimistic mechanism token was included, this mechanism token MUST be passed to the selected mechanism by invoking GSS_Accept_sec_context(). GSS_Accept_sec_context() is defined in RFC 2743, and the first token passed to it must use the format specified in section 3.1 (i.e., it must be an InitialContextToken). In this trace, the mechToken contains raw NTLMSSP data, not an InitialContextToken containing NTLMSSP data. Based on the references I listed above, this behavior appears to be different than what is required by RFC 4178 and RFC 2743. See attached spnego_ntlmssp.cap, frame 6. Perhaps there is some confusion here because RFC 4178 section 3.2 mentions two separate calls to GSS_Accept_sec_context(). Initially, the entire GSS token (bytes 0x75-0xBE in this trace) is passed to GSS_Accept_sec_context(), as mentioned at the beginning of item (c), so it can be processed by the SPNEGO mechanism. Then, if the SPNEGO mechanism accepts the initiator's preferred mechanism, and the initiator included an optimistic mechToken (bytes 0x97-0xBE in this trace), the optimistic mechToken must be passed to GSS_Accept_sec_context() so it can be processed by the negotiated mechanism. This behavior is from the end of item (c), which I quote above. Based on my understanding, this second call to GSS_Accept_sec_context() is establishing a new "inner" context that uses the negotiated mechanism. Therefore this call to GSS_Accept_sec_context() is the also first call for this context, so it should receive an InitialContextToken. Admittedly, RFC 4178 could be a bit clearer in this regard. However, other available SPNEGO implementations appear to agree with my interpretation. For example, this appears to be how the MIT Kerberos implementation behaves: http://anonsvn.mit.edu/cgi-bin/viewcvs.cgi/trunk/src/lib/gssapi/spnego/spnego_mech.c?rev=19831&view=markup They pass the received tokens to gss_init_sec_context()/ gss_accept_sec_context() with a separate inner context. As a result, the initial mechToken is always a GSS InitialContextToken. Expected: Even though we are not claiming compliance with RFC4178, the interpretation of '3.2. Negotiation Procedure' is a point of interest concerning how we embed the NTLM NEGOTIATE MESSAGE MechToken (Netmon 3.2 trace extract below, from the attached spnego_ntlmssp.cap, frame 6. The customer is requesting that we annotate this concerning that 'the Windows implementation does not accept well-formed GSS InitialContextTokens containing NTLM SSP'. - SecurityBlob: - GssApi: + ApplicationHeader: + ThisMech: SpnegoToken (1.3.6.1.5.5.2) - InnerContextToken: 0x1 - SpnegoToken: 0x1 + Tag0: - NegTokenInit: 0x1 + SequenceHeader: + Tag0: + MechTypes: + Tag2: + OctetStringHeader: - MechToken: NTLM NEGOTIATE MESSAGE + NLMP: NTLM NEGOTIATE MESSAGE Regards, Bill Wesse MCSE, MCTS / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: +1(980) 776-8200 CELL: +1(704) 661-5438 FAX: +1(704) 665-9606 -----Original Message----- From: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 4:29 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Mon, Nov 03, 2008 at 07:24:08AM -0800, Bill Wesse wrote: > While I agree with your comments concerning RFC 4178 / > GSS_Accept_sec_context(), that is not the case with the Windows > implementation, which accepts raw NTLM and Kerberos tokens - as specified in > the SPNEGO document ([MS-SPNG] 3.2.5.2 Universal Receiver), and as evidenced > in the network traces. I must also note that RFC 4178 is not in the list of > normative references for the [MS-NLMP] specification document (although, as > you know, RFC 2743 is). > > As you know, our documentation people have already addressed this to a > certain extent, in previous responses they have provided for you. But it > appears that we have not met your needs completely. > > So I am obliged to ask you for any further recommendations concerning changes > and clarifications you deem appropriate to [MS-SPNG] and [MS-NLMP]. The documentation updates so far have addressed the fact that the Windows implementation accepts raw NTLM SSP tokens that are not correctly embedded in GSS InitialContextTokens. However, I don't recall any updates addressing the fact that the Windows implementation does not accept well-formed GSS InitialContextTokens containing NTLM SSP. This could probably be addressed by updating [MS-NLMP] somewhere to indicate that the NTLM implementation of GSS_Init_sec_context() never outputs a GSS InitialContextToken for the first token, and GSS_Accept_sec_context() does not accept well-formed GSS InitialContextTokens. Updating [MS-NLMP] this way would address both the behavior with and without SPNEGO, since SPNEGO should merely be invoking GSS_Init_sec_context()/GSS_Accept_sec_context() to handle the inner NTLM SSP mechToken. The "Universal Receiver" section of [MS-SPNG] probably wouldn't even be relevant anymore. I'm not sure where the best place in [MS-NLMP] would be to mention this. Section 1.4 talks about the GSS-API interface to NTLM. It references section 3.4.6, but that only talks about the GSS_WrapEx() call. -- Adam Simpkins [EMAIL PROTECTED] > -----Original Message----- > From: Adam Simpkins [mailto:[EMAIL PROTECTED] > Sent: Friday, October 31, 2008 3:14 PM > To: Bill Wesse > Cc: '[EMAIL PROTECTED]' > Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in > GSS-API/SPNEGO > > On Fri, Oct 31, 2008 at 09:06:38AM -0700, Bill Wesse wrote: > > I am curious about your thoughts concerning the below; I did a bit > > more looking into the traces: > > > > A note concerning 'spnego_ntlmssp.cap': the Network Monitor 3.1 parser > > incorrectly marks the token as an 'InnerContextToken' instead of an > > 'InitialContextToken'. > > I haven't used Network Monitor to look at the traces (I mostly use > Wireshark), but based on the output you list below, the > InnerContextToken label appears to be correct. The > InitialContextToken is the entire GSS token, consisting of both the > ThisMech and InnerContextToken fields, plus the APPLICATION 0 header > tag. > > > > > From what I can see, spnego_ntlmssp.cap frame 6 conforms to RFC 2743. > > The outer (SPNEGO) token is a proper GSS InitialContextToken, so that > aspect is in compliance with RFC 2743. However, the mechToken field > in the SPNEGO negTokenInit should also be a GSS InitialContextToken, > but isn't. > > Please refer to our earlier discussion regarding RFC 4178 section 3.2: > > http://lists.samba.org/archive/cifs-protocol/2008-August/000284.html > http://lists.samba.org/archive/cifs-protocol/2008-August/000299.html
spnego_ntlmssp.cap
Description: spnego_ntlmssp.cap
_______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
