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

[Bill Wesse]

Adam, thank you very much for your persistence.

I apologize for responding against the two issues with the same answer. In order to make sure I don't commit another mix-up, I have superseded SRX080803600053 with SRX081029600208.

I did a careful backtrack on the question/response history, and noticed something that surprised and disappointed me: in the below partial RESPONSE text, we are essentially claiming that our own XP Client is sending an invalid NTLM SSP token.

I think we confused how gss_ntlmssp.cap was generated (XP <-> 2003) with how raw_ntlmssp.cap was generated (which, as you noted, had the security blob stripped).

I expect to file a new bug concerning this later today, after reviewing the latest internal builds of the documents.

RESPONSE:
...
The RAW NTLM SSP token in your sniff gss_ntlmssp.cap contains the GSS
InitialContextToken syntax using the NTLM SSP OID and this is not a valid
NTLM SSP token.
...

Network traces:

Windows XP SP3 and a server running Windows Server 2003 SP2 (Enterprise Edition).

GSS InitialContextTokens with SPNEGO:
spnego_ntlmssp.cap frames 6, 7, 8 & 9

GSS InitialContextTokens without SPNEGO:
gss_ntlmssp.cap frames 7 & 8


Regards,
Bill Wesse
MCSE, MCTS / 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: Tuesday, October 28, 2008 2:56 PM
To: Bill Wesse
Cc: 'cifs-protocol at samba.org'
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

On Tue, Oct 28, 2008 at 02:45:19AM -0700, Bill Wesse wrote:
> Good morning Mr. Simpkins. I have attached '[MS-SPNG]_Changes.pdf',
> which shows the changes we have made to [MS-SPNG], as well as the
> responses to your comments and questions (below).
> Please let me know if this answers your questions satisfactorily; if
> so, I will consider your question resolved. Thanks for helping us
> improve our documentation.

Thanks for the reply, I still believe the last two items below need
addressing:


> COMMENT:
> NegTokenInit's MechToken contains an NTLMSSP blob -  not per RFC.
>
> RESPONSE: This is explained in  [MS-SPNG] 3.2.5.2 of the Windows Behavior notes.
>
> 3.2.5.2      Universal Receiver
> <8>
> "This behavior is present on Windows 2000, Windows XP, Windows Server 2003, and Windows Vista. 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."

Yes, this part of the case can be resolved.

> COMMENT:
> mechType identification should be more clearly referenced in main body of the document.
>
> RESPONSE: Please see the attached document '[MS-SPNG]_Changes.pdf'.
>
> COMMENT:
> OID 1.2.840.113554.1.2.2 is ALWAYS included in the mechToken/responseToken.
>
> RESPONSE: Please see the attached document '[MS-SPNG]_Changes.pdf'.

Thanks, that looks good.



> COMMENT:
> Another related point that should probably be documented is that Windows servers do not seem to accept well-formed GSS InitialContextTokens containing NTLMSSP
>
> RESPONSE:
> The SPNEGO universal responder behavior says that the SPNEGO server accepts RAW NTLM and RAW Kerberos tokens. The RAW NTLM SSP token in your sniff contains the GSS InitialContextToken syntax using the NTLM SSP OID and this is not a valid NTLM SSP token. In section 2.2 of the MS NTLM document (MS-NLMP) we can see that NTLMSSP does not use the GSS InitialContextToken syntax and all the NTLM token messages are in one of the NEGOTIATE_MESSAGE (2.2.1.1), CHALLENGE_MESSAGE (2.2.1.2) or AUTHENTICATE_MESSAGE (2.2.1.3) syntax. The failure to accept InitialContextToken wrapped NTLM tokens is not considered as a behavior of SPNEGO but the behavior of NTLM SSP. In this case, SPNEGO only accepts valid NTLM tokens where your NTLM tokens in the sniff with the GSS InitialContextToken syntax is considered invalid by the NTLM SSP.

Do we really have to go over this point again?  We discussed this at
length in previous emails.

[MS-SMB] states that when CAP_EXTENDED_SECURITY is set, the
SecurityBlob contained in the SESSION_SETUP_ANDX request is a GSS
token.  See [MS-SMB] 3.3.5.3 and 3.2.5.3.  RFC 2743 section 3.1
defines the format for the initial token of a GSS context
establishment sequence (i.e., a GSS InitialContextToken, containing
the mechanism specific token as the innerContextToken).

With NTLM SSP chosen as the GSS mechanism, this would clearly mean
that the very first token exchanged should be a GSS
InitialContextToken containing a NTLM SSP token.


> 5.)
>
> QUESTION:
> 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).
>
> RESPONSE:
> The SPNEGO universal responder behavior says that the SPNEGO server accepts RAW NTLM and RAW Kerberos tokens. The RAW NTLM SSP token in your sniff gss_ntlmssp.cap contains the GSS InitialContextToken syntax using the NTLM SSP OID and this is not a valid NTLM SSP token. In section 2.2 of the MS NTLM document (MS-NLMP) we can see that NTLMSSP does not use the GSS InitialContextToken syntax and all the NTLM token messages are in one of the NEGOTIATE_MESSAGE (2.2.1.1), CHALLENGE_MESSAGE (2.2.1.2) or AUTHENTICATE_MESSAGE (2.2.1.3) syntax. The failure to accept InitialContextToken wrapped NTLM tokens is not considered as a behavior of SPNEGO but the behavior of NTLM SSP. In this case, SPNEGO only accepts valid NTLM tokens where your NTLM tokens in the sniff gss_ntlmssp.cap with the GSS InitialContextToken syntax is considered invalid by the NTLM SSP. Per spnego_gss_ntlmssp.cap: the embedded NTLM token not have any GSS InitialContextToken syntax.

Again, we've previously discussed this issue.  See my arguments
regarding RFC 4178 section 3.2 item (c) in the following mail:

http://lists.samba.org/archive/cifs-protocol/2008-August/000284.html

In your reply, you agreed with my reading of the RFC.  See the
Question 1 and Question 2 sections in the following mail:

http://lists.samba.org/archive/cifs-protocol/2008-August/000299.html

--
Adam Simpkins
simpkins at cisco.com