[cifs-protocol] [MS-SMB2] Error in SMB2 Netprot description.
SRX090604600250, SRX090604600324, SRX090604600333
Bill Wesse
billwe at microsoft.com
Fri Jun 5 09:04:44 GMT 2009
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-protocol at 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-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.
More information about the cifs-protocol
mailing list