Good morning again! We have split the 3 documentation problems you reported into 3 separate cases; this is normal for our issue housekeeping. I will be working all three.
Here is a short list, followed by the problem description for each: [MS-SMB2] Error in SMB2 Netprot description: SRX090604600250 [MS-SMB2] SESSION_SETUP Request: SRX090604600324 [MS-SMB2] SMB2 SESSION_SETUP Response: SRX090604600333 ============================================================================== [MS-SMB2] Error in SMB2 Netprot description: SRX090604600250 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. ============================================================================== [MS-SMB2] SESSION_SETUP Request: SRX090604600324 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." The values in these buffers can be a raw NTLMSSP data blob instead of a GSS blob. Jeremy Allison, Samba Team/PFIF. ============================================================================== [MS-SMB2] SMB2 SESSION_SETUP Response: SRX090604600333 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. 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:45 PM To: Jeremy Allison Cc: Interoperability Documentation Help; cifs-proto...@samba.org Subject: RE: [Pfif] CAR: Error in SMB2 Netprot description. (SRX090604600250) 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; cifs-proto...@samba.org 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:j...@samba.org] Sent: Thursday, June 04, 2009 2:51 PM To: Jeremy Allison Cc: Interoperability Documentation Help; cifs-proto...@samba.org 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 cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol