[cifs-protocol] RE: raw NTLMSSP tokens in GSS-API/SPNEGO?

[Bill Wesse]

Good afternoon Mr. Simpkins. First, I apologize for my late response.

I have created a new case for your questions concerning the [MS-NLSP] document. Myself, or one of my team members will taking ownership of the case and contact you soon.

Thank you for your forbearance of my mistake in not responding sooner.

Regards,
Bill Wesse
MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM
8055 Microsoft Way
Charlotte, NC 28273
TEL:  980-776-8200
CELL: 704-661-5438
FAX:  704-665-9606
We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Adam Simpkins [mailto:simpkins at cisco.com]
Sent: Friday, August 01, 2008 8:12 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: raw NTLMSSP tokens in GSS-API/SPNEGO?

I am requesting correction assitance regarding NTLM authentication
using SPNEGO:

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

RFC 4178 is somewhat vague on this matter, but a close reading reveals
that the first mechToken/responseToken sent by the initiator must be
wrapped in a GSS-API InitialContextToken.  In particular, RFC 4178
section 3.2 item (c) states:

      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().  If a response mechanism token is
      returned, it MUST be included in the response negotiation token.
      Otherwise, the target will not generate a response mechanism token
      in the first reply.

Given that the initial inner token is passed to
GSS_Accept_sec_context(), it must be a GSS-API InitialContextToken.

Windows clients follow this behavior when Kerberos is negotiated, but
not when NTLM is negotiated.  When NTLM is in use, they send a raw
NTLM message, not contained in an InitialContextToken.  I can provide
SMB traces of this behavior if desired.

I haven't been able to find mention of this Microsoft-specific
behavior in MS-SPNG or in MS-NLMP.

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.

Did I miss something in the documentation, or could it be updated to
describe this deviation from the standard?

--
Adam Simpkins
simpkins at cisco.com