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

Bill Wesse billwe at microsoft.com
Tue Nov 4 10:57:00 GMT 2008 

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:simpkins at cisco.com]
Sent: Monday, November 03, 2008 4:29 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 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: spnego_ntlmssp.cap
Type: application/octet-stream
Size: 2447 bytes
Desc: spnego_ntlmssp.cap
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20081104/2e707b2a/spnego_ntlmssp-0001.obj

More information about the cifs-protocol mailing list