[cifs-protocol] Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

[Adam Simpkins]

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
simpkins at cisco.com



> -----Original Message-----
> From: Adam Simpkins [mailto:simpkins at cisco.com]
> Sent: Friday, October 31, 2008 3:14 PM
> To: Bill Wesse
> Cc: 'cifs-protocol at samba.org'
> 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