On Fri, Aug 08, 2008 at 09:27:54AM -0700, Bill Wesse wrote: > Good afternoon Mr. Simpkins. I have provided summaries concerning your > follow up questions on the original questions 1, 2 & 4. In addition, I > have attached the full text and responses (with the material below > interpolated) for the sake of completeness. > > To summarize, you raised several issues (I have provided indented > response summaries; there are more complete responses in the follow up > section for each question, and an attachment with both original and > follow up text). > > Please let me know if there is anything that I have not answered fully > (or misconstrued); I want to make sure we pare this down to specific > document changes or product bugs that may apply.
Thank you for investigating these issues, and for your detailed reply. I have responded to your comments below: > Full Responses: > =============== > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Question 1 Follow-up: > --------------------- <snip> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Response: > > Thanks for correcting my terminology on the text 'negotiate message is > encapsulated', which should have been 'the mechToken (inside the SPNEGO > NegTokenInit) is what's at 0x97-0xBE'. > > I agree - the below extract from 'RFC 4178 section 3.2 (c)' implies that a > new inner context should be established (as is done with Kerberos, as shown > in spnego_krb.cap frame 7). > > The possibility of guaranteeing an update to a majority of deployed Windows > clients and servers approaches the impossible. This constrains Windows > versions to preserve backward compatibility for some time to come. Any updates > would need to be accomodated per the follow up on Question 2, below. Yes, that's perfectly understandable. I agree that it's not really feasible to fix the existing behavior at this point. Although the servers could perhaps be updated to also accept RFC-compliant requests from clients, clients obviously can't be updated for backwards compatibility with existing servers. I'm not really asking that the existing Windows behavior be changed here, merely that this deviation from the RFC be documented. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Question 2 Follow-up: > --------------------- > Windows servers do not seem to accept well-formed GSS InitialContextTokens > containing NTLMSSP (re: gss_ntlmssp.cap frame 7), as is done with Kerberos > (re: spnego_krb.cap frame 7). > > Response: > > This refers to the same GSS-API construction information referenced in > Question 1. above. > > As noted, this appears to be an interoperability deficiency. Action on our > part may well require bug filings against newer versions of Windows. > Could you advise me of any known implementations that do this? That would > be necessary for evidence to justify any Windows updates. I'm not aware of any CIFS implementations that currently do this. As above, while it would be nice to update Windows server's to also accept NTLMSSP InitialContextTokens, documenting the current behavior is more important. Currently MS-SMB indicates that the SecurityBlob in the SESSION_SETUP_ANDX request should be a GSS authentication token. It should be mentioned somewhere in this document that Windows servers do not accept well-formed GSS InitialContextTokens for NTLMSSP, but (as mentioned in Question 4) that they do accept "raw" NTLMSSP messages that are not properly wrapped in an InitialContextToken. I haven't tested Windows behavior with protocols other than SMB, but it seems likely that they could also share the same behavior. The MS-NTHT and MS-NLMP documents might also be affected. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Question 4 Follow-up: > --------------------- > > Response: > > raw_ntlmssp.cap frame 7: > > Microsoft's implementation does indeed accept raw NTLMSSP data (per Reference > A below) in the SecurityBlob in an SMB_COM_SESSION_SETUP_ANDX request packet. > This does not relate to SPNEGO negotiation, and was introduced in the NTLMv2 > implementation on Windows NT 4 Service Pack 4. I think the part that I find confusing here is the fact that this is documented in MS-SPNG, although it does not relate to SPNEGO negotiation. It would be nice if it were at least referenced in the relevant sections in MS-SMB. > Reference A: > [MS-SMB] 3.2.4.2.3 > User Authentication / 'Implicit NTLM I don't believe this is reference relevant here. The "Implicit NTLM" section describes the behavior when the CAP_EXTENDED_SECURITY bit in ServerCapabilities is not set. In this case, there is no SecurityBlob in the request, and GSS authentication is not used. The NTLM data is sent in the CaseSensitivePassword and CaseInsensitivePassword fields. > Kerberos support (under GSSAPI/SPNEGO) was, of course, introduced in > Windows 2000 (along with NTLMSSP; Reference A does not apply here). > > spnego_krb.cap frame 7: > > Kerberos behavior (per Reference B below), is indeed Windows Behavior. I > assume that you are referring to the follow up to Question 1 (RFC 4178 > section 3.2 (c)). In this case, the Windows Behavior that applies also > refers to Reference C below, which is specific to the Kerberos OID > encoding (erroneous: 1.2.840.48018.1.2.2, correct: 1.2.840.113554.1.2.2). The behavior I was referring to is the fact that Windows servers accept GSS authentication using Kerberos without SPNEGO (i.e., with the Kerberos OID, 1.2.840.113554.1.2.2, in the thisMech field, not the SPNEGO OID.) I assume this is what the Kerberos aspect of note <8> is describing. The point I was making is that this behavior complies with RFC 2743, RFC 1964, RFC 4121, and RFC 4120. It does not seem to be a Windows-specific extension. I was not referring to the erroneous OID that Windows clients and servers use during SPNEGO (OID 1.2.840.48018.1.2.2, from note <5>). In fact, based on my testing, Windows servers do not accept this OID when SPNEGO is not in use--they only accept the correct Kerberos OID. (I have verified this at least with Windows Server 2003 SP2. I can provide traces if desired.) The erroneous OID appears to only be accepted in the SPNEGO mechTypes and supportedMech fields, and never in the GSS InitialContextToken's thisMech field (regardless of whether or not SPNEGO is in use). Even when SPNEGO is in use and 1.2.840.48018.1.2.2 is listed as the preferred OID, Windows clients still send 1.2.840.113554.1.2.2 as the thisMech field of the InitialContextToken in the optimistic mechToken. Based on my reading of the documentation, notes <8> and <5> do not appear to be particularly related to each other. -- Adam Simpkins [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
