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

Fri Sep 19 15:19:02 GMT 2008

Good morning! I indeed should have noted the change was made to [MS-SPNG] instead of [MS-NLMP] (thanks for catching that).

I have just submitted your comments (shown immediately below) as a change request against [MS-SPNG].

...the phrase "that are not embedded in [RFC4178] SPNEGO messages" should be changed to "that are not embedded in [RFC2743] GSS-API InitialContextTokens"...

I have also submitted another change request to add a reference from "[MS-SMB] section 3.2.4.2.3" to "[MS-SPNG] Section 3.2.5.2 Universal Receiver" to the 'Extended Security' subtopic. This was actually in the original change request (which was against [MS-SMB], but the [MS-SPNG] text was the only resulting change). Sorry we missed the original target.

Regards,
Bill Wesse
MCSE / 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: Thursday, September 18, 2008 4:48 PM
To: Bill Wesse
Cc: 'cifs-protocol at samba.org'
Subject: Re: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

On Thu, Sep 18, 2008 at 06:29:00AM -0700, Bill Wesse wrote:
> Good afternoon Mr. Simpkins. We have completed our investigations
> concerning your request for correction assistance regarding NTLM
> authentication using SPNEGO (in [MS-NLMP]), and have provided the
> document changes shown below. These changes will be available in a
> future document refresh.
>
> Please note that your other comments (shown in 'Remaining Issues'
> below are still under investigation. I will keep you updated as
> developments occur.
>
> ==============================================================================
> Original Comment:
> When NTLM authentication is negotiated over SPNEGO, Windows clients
> do not properly wrap the initial NTLM token inside a GSS-API
> InitialContextToken (described in RFC 2743 section 3.1).
>
> [MS-NLMP] Document Change:

Did you mean [MS-SPNG] instead of [MS-NLMP] here?  MS-NLMP section
3.2.5.2 doesn't seem relevant.

> <#> Section 3.2.5.2:  This behavior is present on Windows Vista,
> Windows Server 2003, Windows XP, and Windows 2000. For backward
> compatibility and historical reasons, the Windows implementation of
> SPNEGO has the following behavior: it accepts raw Kerberos messages
> that are based on [RFC4121] and [RFC4120], and it accepts raw NTLM
> messages that are not embedded in [RFC4178] SPNEGO messages. This
> behavior is known as the Universal Receiver behavior.

This doesn't seem like much of a change to me.  The wording is
slightly different but the meaning appears to be the same as the
original text.  As I've mentioned in several previous emails, the
windows extension is that it accepts raw NTLM messages that are not
embedded in [RFC2743] GSS-API InitialContextTokens.  At the very
least, the phrase "that are not embedded in [RFC4178] SPNEGO messages"
should be changed to "that are not embedded in [RFC2743] GSS-API
InitialContextTokens".

>From the very first email I sent regarding this issue:

  On Fri, Aug 01, 2008 at 05:12:13PM -0700, Adam Simpkins wrote:
  > The one thing I did find that could potentially be considered to
  > explain this behavior is in item <8> in Appendix A of MS-SPNG:
  >
  >       For backward compatibility and historical reasons, a Windows
  >       implementation of SPNEGO has the following behavior: it accepts
  >       raw Kerberos messages that are based on [RFC4121] and [RFC4120],
  >       and it accepts raw NTLM messages that are not embedded in
  >       [RFC4178] SPNEGO messages. This behavior is known as the
  >       universal receiver behavior.
  >
  > I find this passage slightly strange--for Kerberos, this seems to be
  > standard behavior, and not a Windows extension.  Any conforming
  > GSS-API implementation that supports both SPNEGO and Kerberos should
  > accept InitialContextTokens containing either SPNEGO or Kerberos
  > tokens.
  >
  > Therefore, the Windows behavior could perhaps best be described not by
  > the statement above, but by "the Windows GSS-API implementation
  > accepts as the first token a raw NTLM message that is not embedded in
  > an [RFC2743] InitialContextToken."  This wording could also be
  > considered to explain the fact that Windows servers accept the a raw
  > NTLM token in the SPNEGO mechToken.

If this text is changed to properly indicate that Windows servers
accept NTLM messages not embedded in GSS-API InitialContextTokens, it
will probably also be necessary to clarify that this occurs both with
and without SPNEGO.  When SPNEGO is not in use, Windows servers accept
a raw NTLM message instead of the GSS-API InitialContextToken (see the
trace raw_ntlmssp.cap frame 7).  When SPNEGO is in use, Windows
servers accept a raw NTLM message in the SPNEGO mechToken/respToken
field, instead of a GSS InitialContextToken (see trace
spnego_raw_ntlmssp.cap frame 6).

This issue is closely related to the second remaining issue, which is
that Windows server's don't accept NTLM messages properly embedded in
GSS InitialContextTokens, both with SPNEGO (spnego_gss_ntlmssp.cap)
and without (gss_ntlmssp.cap).

> Remaining Issues:
>
> [MS-SPNG]
>
> Inside the actual note <5> in Appendix A, it would be nice to also
> mention that the inner mechToken/responseToken always contains the
> standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when
> the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2.  Windows
> servers do not accept the "truncated" OID in the thisMech field.
>
> Another related point that should probably be documented is that
> Windows servers do not seem to accept well-formed GSS
> InitialContextTokens containing NTLMSSP.  I have attached a trace of
> that, too (gss_ntlmssp.cap frame 7).  (The server is the same Windows
> Server 2003 system as in the other traces.)

One of your previous emails also mentioned proposed changes to
[MS-SMB] section 3.2.4.2.3.  See:
  http://lists.samba.org/archive/cifs-protocol/2008-August/000319.html
and my response:
  http://lists.samba.org/archive/cifs-protocol/2008-August/000327.html

Do you have any update on the status of that change?

--
Adam Simpkins
simpkins at cisco.com