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

[Adam Simpkins]

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