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 _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol