Good morning again! Our documentation development team advises me the following change will be implemented in a future posting of [MS-SMB]:
[MS-SMB]: Server Message Block (SMB) Protocol Specification Section 3.2.4.2.3 User Authentication (Extended Security subtopic) Current Text: In either case, it initializes the GSS authentication protocol with the MutualAuth and Delegate options, which are specified in [MS-KILE] section 3.2.1.1.<173> Request to update with: In either case, it initializes the GSS authentication protocol with the MutualAuth and Delegate options, which are specified in [MS-KILE] section 3.2.1.1.<173> See also [MS-SPNG] section 3.2.5.2. Regards, Bill Wesse MCSE / 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 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: Bill Wesse Sent: Friday, October 03, 2008 10:11 AM To: 'Adam Simpkins' Cc: '[EMAIL PROTECTED]' Subject: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO Good morning Adam - here are some updates for you concerning your comments. ============================================================================== Comment: [MS-SPNG] 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. ------------------------------------------------------------------------------ Response: Work is in progress concerning a document change to address this. ============================================================================== 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. Regards, Bill Wesse MCSE / 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 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: Bill Wesse Sent: Friday, September 19, 2008 11:19 AM To: 'Adam Simpkins' Cc: '[EMAIL PROTECTED]' Subject: RE: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO Good morning! I indeed should have noted the change was made to [MS-SPNG] instead of [MS-NLMP] (thanks for catching that). I have just submitted your comments (shown immediately below) as a change request against [MS-SPNG]. ...the phrase "that are not embedded in [RFC4178] SPNEGO messages" should be changed to "that are not embedded in [RFC2743] GSS-API InitialContextTokens"... I have also submitted another change request to add a reference from "[MS-SMB] section 3.2.4.2.3" to "[MS-SPNG] Section 3.2.5.2 Universal Receiver" to the 'Extended Security' subtopic. This was actually in the original change request (which was against [MS-SMB], but the [MS-SPNG] text was the only resulting change). Sorry we missed the original target. Regards, Bill Wesse MCSE / 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: Thursday, September 18, 2008 4:48 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' Subject: Re: Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO On Thu, Sep 18, 2008 at 06:29:00AM -0700, Bill Wesse wrote: > Good afternoon Mr. Simpkins. We have completed our investigations > concerning your request for correction assistance regarding NTLM > authentication using SPNEGO (in [MS-NLMP]), and have provided the > document changes shown below. These changes will be available in a > future document refresh. > > Please note that your other comments (shown in 'Remaining Issues' > below are still under investigation. I will keep you updated as > developments occur. > > ============================================================================== > Original Comment: > When NTLM authentication is negotiated over SPNEGO, Windows clients > do not properly wrap the initial NTLM token inside a GSS-API > InitialContextToken (described in RFC 2743 section 3.1). > > [MS-NLMP] Document Change: Did you mean [MS-SPNG] instead of [MS-NLMP] here? MS-NLMP section 3.2.5.2 doesn't seem relevant. > <#> Section 3.2.5.2: This behavior is present on Windows Vista, > Windows Server 2003, Windows XP, and Windows 2000. For backward > compatibility and historical reasons, the 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. This doesn't seem like much of a change to me. The wording is slightly different but the meaning appears to be the same as the original text. As I've mentioned in several previous emails, the windows extension is that it accepts raw NTLM messages that are not embedded in [RFC2743] GSS-API InitialContextTokens. At the very least, the phrase "that are not embedded in [RFC4178] SPNEGO messages" should be changed to "that are not embedded in [RFC2743] GSS-API InitialContextTokens". >From the very first email I sent regarding this issue: On Fri, Aug 01, 2008 at 05:12:13PM -0700, Adam Simpkins wrote: > The one thing I did find that could potentially be considered to > explain this behavior is in item <8> in Appendix A of MS-SPNG: > > 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. > > I find this passage slightly strange--for Kerberos, this seems to be > standard behavior, and not a Windows extension. Any conforming > GSS-API implementation that supports both SPNEGO and Kerberos should > accept InitialContextTokens containing either SPNEGO or Kerberos > tokens. > > Therefore, the Windows behavior could perhaps best be described not by > the statement above, but by "the Windows GSS-API implementation > accepts as the first token a raw NTLM message that is not embedded in > an [RFC2743] InitialContextToken." This wording could also be > considered to explain the fact that Windows servers accept the a raw > NTLM token in the SPNEGO mechToken. If this text is changed to properly indicate that Windows servers accept NTLM messages not embedded in GSS-API InitialContextTokens, it will probably also be necessary to clarify that this occurs both with and without SPNEGO. When SPNEGO is not in use, Windows servers accept a raw NTLM message instead of the GSS-API InitialContextToken (see the trace raw_ntlmssp.cap frame 7). When SPNEGO is in use, Windows servers accept a raw NTLM message in the SPNEGO mechToken/respToken field, instead of a GSS InitialContextToken (see trace spnego_raw_ntlmssp.cap frame 6). 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). > Remaining Issues: > > [MS-SPNG] > > 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. > > 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.) One of your previous emails also mentioned proposed changes to [MS-SMB] section 3.2.4.2.3. See: http://lists.samba.org/archive/cifs-protocol/2008-August/000319.html and my response: http://lists.samba.org/archive/cifs-protocol/2008-August/000327.html Do you have any update on the status of that change? -- Adam Simpkins [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol