I neglected to provide you with the case number, which is: SRX090604600250.
Regards, Bill Wesse MCSE, MCTS / Senior 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: Bill Wesse Sent: Thursday, June 04, 2009 4:32 PM To: Jeremy Allison Cc: Interoperability Documentation Help; [email protected] Subject: RE: [Pfif] CAR: Error in SMB2 Netprot description. Jeremy - thanks for the network capture - I will begin working on this tomorrow morning (Friday, GMT - 5). The [MS-SMB] document (reference below) 3.2.4.2.3 User Authentication 'Implicit NTLM' subsection talks about this; I will cross-compare [MS-SMB2] against this, and proceed with any appropriate document change requests. [MS-SMB]: Server Message Block (SMB) Protocol Specification 3.2.4.2.3 User Authentication http://msdn.microsoft.com/en-us/library/cc246379(PROT.13).aspx Implicit NTLM Regards, Bill Wesse MCSE, MCTS / Senior 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: Jeremy Allison [mailto:[email protected]] Sent: Thursday, June 04, 2009 2:51 PM To: Jeremy Allison Cc: Interoperability Documentation Help; [email protected] Subject: Re: [Pfif] CAR: Error in SMB2 Netprot description. On Thu, Jun 04, 2009 at 11:39:38AM -0700, Jeremy Allison wrote: > On Thu, Jun 04, 2009 at 11:33:41AM -0700, Jeremy Allison wrote: > > Hi all, > > > > I believe there is an error in [MS-SMB2] — v20090521 in the > > description of 2.2.4 SMB2 NEGOTIATE Response. > > > > At the end of this section on page 35 it says: > > > > "Buffer (variable): The variable-length buffer that contains the security > > buffer for the response, as specified by SecurityBufferOffset and > > SecurityBufferLength. The buffer MUST contain a token as produced by the > > GSS protocol as specified in section 3.3.5.3." > > > > The "MUST" statement is incorrect. The Windows client behavior is > > that if a null buffer is returned in this field, then the client > > will downgrade to using raw-NTLMSSP blobs for sessionsetup instead > > of SPNEGO wrapped blobs. > > > > I can provide proof of this as a packet trace on request. > > > > I think this is important to fix for the SMB2 client > > implementations, which otherwise are forced to implement SPNEGO ASN.1 > > parsing. > > Sorry, should have realized - there are two more "MUSTS" > which are incorrect. > > Section "2.2.5 SMB2 SESSION_SETUP Request" also has a MUST at the end > of the section: > > "Buffer (variable): A variable-length buffer that contains the security > buffer for the request, as specified by SecurityBufferOffset and > SecurityBufferLength. The buffer MUST contain a token as produced by the GSS > protocol as specified in section 3.3.5.5." > > and also "2.2.6 SMB2 SESSION_SETUP Response" has a MUST at the end of > the section: > > "Buffer (variable): A variable-length buffer that contains the security > buffer for the response, as specified by SecurityBufferOffset and > SecurityBufferLength. The buffer MUST contain a token as produced by the GSS > protocol as specified in section 3.2.5.3." > > The values in these buffers can be a raw NTLMSSP data blob instead of > a GSS blob. > > No need to open a new CAR, just attach these ammendments to the > existing one. As requested, here is the wireshark capture trace showing this behavior. Jeremy.
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
