Thank you very much for the clarifications. I have filed separate document change requests for the [MS-SPNG] and [MS-SMB] addenda / changes you are requesting.
Please note that I will be out of the office next week; one of my colleagues will be keeping track of this request while I am gone (the assignment will be made sometime today). We will keep you informed as things develop! Regards, Bill Wesse MCSE / Escalation Engineer, US-CSS DSC PROTOCOL TEAM 8055 Microsoft Way Charlotte, NC 28273 TEL: 980-776-8200 CELL: 704-661-5438 FAX: 704-665-9606 We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted -----Original Message----- From: Adam Simpkins [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2008 1:44 AM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: Response (document change proposals): raw NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053 On Wed, Aug 13, 2008 at 09:59:37AM -0700, Bill Wesse wrote: > ----------------------------------------------------------------------------- > [MS-SPNG]: Simple and Protected Generic Security Service Application Program > Interface Negotiation Mechanism (SPNEGO) Protocol Extensions > > Change: > 3.1.5.2 mechTypes Identification of Kerberos > <5> > > To: > 3.1.5.2 mechTypes Identification of Kerberos > Windows XP, Windows Server 2003, Windows Vista, and Windows Server offer and > receive the mechType 1.2.840.113554.1.2.2 (Generic Security Service > Application Program Interface) when using Kerberos Version 5 technology), > { iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) > krb5(2) }.<5> Inside the actual note <5> in Appendix A, it would be nice to also mention that the inner mechToken/responseToken always contains the standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2. Windows servers do not accept the "truncated" OID in the thisMech field. > ----------------------------------------------------------------------------- > [MS-SMB]: Server Message Block (SMB) Protocol Specification > > 3.2.4.2.3 User Authentication > > Add a <Windows Behavior #> reference (suggested text shown below) to the > 'Extended Security' subtopic. > > <Windows Behavior #> > > Windows accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO > messages ([MS-SPNG] 3.2.5.2 Universal Receiver) in the SecurityBlob of an > SMB_COM_SESSION_SETUP_ANDX request packet. This was introduced in the NTLMv2 > implementation of Windows NT 4 Service Pack 4. > > Note: See the attached: > raw_ntlmssp.cap frame 7. > > GSSAPI/SPNEGO support for Kerberos and NTLMSSP was introduced in Windows > 2000. > > [RFC4178] section 3.2 (c)' implies a new inner context should be established. > This is done with Kerberos, but not with NTLMSSP. Additionally, Windows does > not accept GSS InitialContextTokens containing NTLMSSP within a new inner > context. > > Note: See the attached: > spnego_krb.cap frame 7 > spnego_ntlmssp.cap frame 6. > gss_ntlmssp.cap frame 7 (server responds with STATUS_INVALID_PARAMETER) Thanks for the proposed changes. I have a few suggestions that might improve upon this: In the first sentence, I think it would be correct to say "Windows accepts raw NTLM messages that are not embedded in [RFC2743] InitialContextTokens." GSS-API allows any (supported) mechanism to be used without SPNEGO; however, it does require that the first token always be an InitialContextToken. The Windows specific behavior here is simply the missing InitialContextToken, not the lack of SPNEGO. (It would also be nice to fix this in MS-SPNG. As I have mentioned here and in previous emails, the "Universal Receiver" behavior described in MS-SPNG isn't particularly a Windows-specific extension; only the lack of an InitialContextToken for NTLMSSP is.) I think it would also be better to reference gss_ntlmssp.cap after the first paragraph, rather than the second. gss_ntlmssp.cap shows how the SecurityBlob should look like (according to RFC 2743) when SPNEGO is not in use, and raw_ntlmssp.cap shows what Windows clients actually generate. For the second paragraph, I don't believe I ever sent you a trace showing how the SecurityBlob should look like when SPNEGO is in use and NTLMSSP is selected as the mechanism. I can probably generate one if you would like, to contrast with the current Windows behavior (spnego_ntlmssp.cap). With these changes, it could look perhaps something like: Windows accepts raw NTLM NEGOTIATE messages that are not embedded in [RFC2743] InitialContextTokens in the SecurityBlob of an SMB_COM_SESSION_SETUP_ANDX request packet. This was introduced in the NTLMv2 implementation of Windows NT 4 Service Pack 4. Windows servers do not accept NTLM messages that are properly contained inside a GSS InitialContextToken. The server responds with STATUS_INVALID_PARAMETER. Note: See the attached: raw_ntlmssp.cap frame 7. gss_ntlmssp.cap frame 7. GSSAPI/SPNEGO support for Kerberos and NTLMSSP was introduced in Windows 2000. When SPNEGO is in use, [RFC4178] section 3.2 (c) implies a new inner context should be established, and the initial mechToken should be an [RFC2743] InitialContextToken. This is done with Kerberos, but not with NTLMSSP. When NTLMSSP is chosen as the optmistic or supported mechanism, Windows servers do not accept well an InitialContextToken in the mechToken/responseToken field. Note: See the attached: spnego_krb.cap frame 7 spnego_ntlmssp.cap frame 6. spnego_gss_ntlmssp.cap [This doesn't exist yet, but I can generate a trace to contain the RFC-compliant format when SPNEGO is in use and NTLMSSP is selected.] Also, one other request with regard to the changes: I would prefer if these exact versions of raw_ntlmssp.cap and gss_ntlmssp.cap aren't included in the WSPP documentation. These files refer to Cisco in the NativeOS and NativeLanMan fields in some of the SESSION_SETUP_ANDX requests. I'm out of the office this week, but I should be able to generate some "santized" trace files next week that can be included in the documentation. Again, thanks for the time and attention you have given to this matter. -- Adam Simpkins [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol