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

[Bill Wesse]

Good morning once again Adam. I am sending this, as I have not received your response to my email of Sept 10 (shown below).

Please note the information provided below lists remaining issues, which our document developers are still working on. I will update you as information develops.

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: Bill Wesse
Sent: Wednesday, September 10, 2008 7:14 AM
To: 'Adam Simpkins'
Cc: 'cifs-protocol at samba.org'
Subject: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

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