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

[Bill Wesse]

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.


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

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

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


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: Bill Wesse
Sent: Wednesday, October 15, 2008 3:33 PM
To: 'Adam Simpkins'
Subject: RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

Thanks for the correction - this question is indeed still pending development response (I expect some response within the next week or so on this). I apologize for my error.

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: Wednesday, October 15, 2008 2:39 PM
To: Bill Wesse
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

On Wed, Oct 15, 2008 at 07:09:09AM -0700, Bill Wesse wrote:
> Good morning! The [MS-SPNG] document now references RFC4178 instead of RFC2743 in the Windows Behavior note!

Thanks!

> Please let me know if we have answered all of your questions satisfactorily; if so, I will consider your question resolved. Thanks for helping us improve our documentation.
>

I think there was still the issue about Windows servers not accepting NTLM messages properly embedded in GSS InitialContextTokens:

On Fri, Oct 03, 2008 at 07:11:02AM -0700, Bill Wesse wrote:
> Comment:
>
> [MS-SPNG]
>
> 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.)
>
> 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:
>
> This is still being investigated. Part of the answer is that that
> MS-SPNG
> 3.2.5.2 Universal Receiver covers this:
>
>    http://msdn.microsoft.com/en-us/library/cc213115.aspx.


The Universal Receiver updates document that Windows servers do accept raw NTLM messages not embedded in SPNEGO messages.  However, unless I missed it, I don't think there was an update about the fact that Windows servers don't accept well-formed NTLM GSS-API tokens, both with and without SPNEGO.

Thanks for your diligence and patience getting all of these issues wrapped up!

--
Adam Simpkins
simpkins at cisco.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: [MS-SPNG]_Changes.pdf
Type: application/pdf
Size: 48211 bytes
Desc: [MS-SPNG]_Changes.pdf
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20081028/284294a5/MS-SPNG_Changes-0001.pdf