[cifs-protocol] Re: Status: raw NTLMSSP tokens in GSS-API/SPNEGO?
simpkins at cisco.com
Fri Aug 8 23:42:25 GMT 2008
On Fri, Aug 08, 2008 at 09:27:54AM -0700, Bill Wesse wrote:
> Good afternoon Mr. Simpkins. I have provided summaries concerning your
> follow up questions on the original questions 1, 2 & 4. In addition, I
> have attached the full text and responses (with the material below
> interpolated) for the sake of completeness.
> To summarize, you raised several issues (I have provided indented
> response summaries; there are more complete responses in the follow up
> section for each question, and an attachment with both original and
> follow up text).
> Please let me know if there is anything that I have not answered fully
> (or misconstrued); I want to make sure we pare this down to specific
> document changes or product bugs that may apply.
Thank you for investigating these issues, and for your detailed reply.
I have responded to your comments below:
> Full Responses:
> Question 1 Follow-up:
> Thanks for correcting my terminology on the text 'negotiate message is
> encapsulated', which should have been 'the mechToken (inside the SPNEGO
> NegTokenInit) is what's at 0x97-0xBE'.
> I agree - the below extract from 'RFC 4178 section 3.2 (c)' implies that a
> new inner context should be established (as is done with Kerberos, as shown
> in spnego_krb.cap frame 7).
> The possibility of guaranteeing an update to a majority of deployed Windows
> clients and servers approaches the impossible. This constrains Windows
> versions to preserve backward compatibility for some time to come. Any updates
> would need to be accomodated per the follow up on Question 2, below.
Yes, that's perfectly understandable. I agree that it's not really
feasible to fix the existing behavior at this point. Although the
servers could perhaps be updated to also accept RFC-compliant requests
from clients, clients obviously can't be updated for backwards
compatibility with existing servers.
I'm not really asking that the existing Windows behavior be changed
here, merely that this deviation from the RFC be documented.
> Question 2 Follow-up:
> Windows servers do not seem to accept well-formed GSS InitialContextTokens
> containing NTLMSSP (re: gss_ntlmssp.cap frame 7), as is done with Kerberos
> (re: spnego_krb.cap frame 7).
> This refers to the same GSS-API construction information referenced in
> Question 1. above.
> As noted, this appears to be an interoperability deficiency. Action on our
> part may well require bug filings against newer versions of Windows.
> Could you advise me of any known implementations that do this? That would
> be necessary for evidence to justify any Windows updates.
I'm not aware of any CIFS implementations that currently do this. As
above, while it would be nice to update Windows server's to also accept
NTLMSSP InitialContextTokens, documenting the current behavior is more
Currently MS-SMB indicates that the SecurityBlob in the
SESSION_SETUP_ANDX request should be a GSS authentication token. It
should be mentioned somewhere in this document that Windows servers do
not accept well-formed GSS InitialContextTokens for NTLMSSP, but (as
mentioned in Question 4) that they do accept "raw" NTLMSSP messages that
are not properly wrapped in an InitialContextToken.
I haven't tested Windows behavior with protocols other than SMB, but it
seems likely that they could also share the same behavior. The MS-NTHT
and MS-NLMP documents might also be affected.
> Question 4 Follow-up:
> raw_ntlmssp.cap frame 7:
> Microsoft's implementation does indeed accept raw NTLMSSP data (per Reference
> A below) in the SecurityBlob in an SMB_COM_SESSION_SETUP_ANDX request packet.
> This does not relate to SPNEGO negotiation, and was introduced in the NTLMv2
> implementation on Windows NT 4 Service Pack 4.
I think the part that I find confusing here is the fact that this is
documented in MS-SPNG, although it does not relate to SPNEGO
It would be nice if it were at least referenced in the relevant sections
> Reference A:
> [MS-SMB] 188.8.131.52.3
> User Authentication / 'Implicit NTLM
I don't believe this is reference relevant here. The "Implicit NTLM"
section describes the behavior when the CAP_EXTENDED_SECURITY bit in
ServerCapabilities is not set. In this case, there is no SecurityBlob
in the request, and GSS authentication is not used. The NTLM data is
sent in the CaseSensitivePassword and CaseInsensitivePassword fields.
> Kerberos support (under GSSAPI/SPNEGO) was, of course, introduced in
> Windows 2000 (along with NTLMSSP; Reference A does not apply here).
> spnego_krb.cap frame 7:
> Kerberos behavior (per Reference B below), is indeed Windows Behavior. I
> assume that you are referring to the follow up to Question 1 (RFC 4178
> section 3.2 (c)). In this case, the Windows Behavior that applies also
> refers to Reference C below, which is specific to the Kerberos OID
> encoding (erroneous: 1.2.840.48018.1.2.2, correct: 1.2.840.1135184.108.40.206).
The behavior I was referring to is the fact that Windows servers accept
GSS authentication using Kerberos without SPNEGO (i.e., with the
Kerberos OID, 1.2.840.1135220.127.116.11, in the thisMech field, not the
SPNEGO OID.) I assume this is what the Kerberos aspect of note <8> is
describing. The point I was making is that this behavior complies
with RFC 2743, RFC 1964, RFC 4121, and RFC 4120. It does not seem to
be a Windows-specific extension.
I was not referring to the erroneous OID that Windows clients and
servers use during SPNEGO (OID 1.2.840.48018.1.2.2, from note <5>).
In fact, based on my testing, Windows servers do not accept this OID
when SPNEGO is not in use--they only accept the correct Kerberos OID.
(I have verified this at least with Windows Server 2003 SP2. I can
provide traces if desired.) The erroneous OID appears to only be
accepted in the SPNEGO mechTypes and supportedMech fields, and never
in the GSS InitialContextToken's thisMech field (regardless of whether
or not SPNEGO is in use). Even when SPNEGO is in use and
1.2.840.48018.1.2.2 is listed as the preferred OID, Windows clients
still send 1.2.840.113518.104.22.168 as the thisMech field of the
InitialContextToken in the optimistic mechToken.
Based on my reading of the documentation, notes <8> and <5> do not
appear to be particularly related to each other.
simpkins at cisco.com
More information about the cifs-protocol