[cifs-protocol] RE: [Pfif] CAR: Error in SMB2 Netprot description. (SRX090604600250)

[Bill Wesse]

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-protocol at 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:jra at samba.org] 
Sent: Thursday, June 04, 2009 2:51 PM
To: Jeremy Allison
Cc: Interoperability Documentation Help; cifs-protocol at 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.