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

Bill Wesse billwe at microsoft.com
Wed Sep 10 11:14:22 GMT 2008


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:

<#> 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.

==============================================================================
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.)


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



More information about the cifs-protocol mailing list