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:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 2:56 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
