[cifs-protocol] RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

Bill Wesse billwe at microsoft.com
Fri Oct 31 16:06:38 GMT 2008


I am curious about your thoughts concerning the below; I did a bit more looking into the traces:

A note concerning 'spnego_ntlmssp.cap': the Network Monitor 3.1 parser
incorrectly marks the token as an 'InnerContextToken' instead of an
'InitialContextToken'.

>From what I can see, spnego_ntlmssp.cap frame 6 conforms to RFC 2743.

Generic Security Service Application Program Interface Version 2, Update 1
http://www.ietf.org/rfc/rfc2743.txt?number=2743
3.1: Mechanism-Independent Token Format

      1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that
         constructed form, definite length encoding follows.
      2. Token length octets
      3. 0x06 -- Tag for OBJECT IDENTIFIER
      4. Object identifier length
      5. Object identifier octets

   The token tag is immediately followed by a mechanism-defined token
   object.

      MechType ::= OBJECT IDENTIFIER
      InitialContextToken ::=
      [APPLICATION 0] IMPLICIT SEQUENCE {
              thisMech MechType,
              innerContextToken ANY DEFINED BY thisMech
              }

==============================================================================
spnego_ntlmssp.cap

Frame: Number = 6
- Smb: C; Session Setup Andx, NTLM NEGOTIATE MESSAGE
    Command: Session Setup Andx 115(0x73)
  + NTStatus: 0x0, Facility = FACILITY_SYSTEM,
    Severity = STATUS_SEVERITY_SUCCESS, Code = (0) STATUS_SUCCESS
  + SMBHeader: Command, TID: 0x0000, PID: 0xFEFF, UID: 0x0000, MID: 0x0040
  - CSessionSetupAndXNTLMESS:
   + Capabilities: 0xA00000D4
   - SecurityBlob:
    - GssApi:
     - ApplicationHeader:
      + AsnId: Application Constructed Tag (0)
      + AsnLen: Length = 72, LengthOfLength = 0
     + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
     - InnerContextToken: 0x1 <-- text should be 'InitialContextToken'
      - SpnegoToken: 0x1
       - Tag0:  AsnId: Context Specific Constructed Tag (0)
       - NegTokenInit: 0x1
        - SequenceHeader: AsnId: Sequence and SequenceOf types (Universal 16)
        - Tag0:  AsnId: Context Specific Constructed Tag (0)
        - MechTypes:
         + SequenceHeader:
         + MechType: NLMP (1.3.6.1.4.1.311.2.2.10)
        - Tag2:  AsnId: Context Specific Constructed Tag (2)
        - OctetStringHeader: AsnId: OctetString type (Universal 4)
        - MechToken: NTLM NEGOTIATE MESSAGE
         - NLMP: NTLM NEGOTIATE MESSAGE
            Signature: NTLMSSP
            MessageType: Negotiate Message (0x00000001)
          - NegotiateFlags: 0xE2088297 (NTLM v2128-bit encryption, Always Sign)
          + WorkstationDomainHeader: Length: 0, Offset: 0
          + WorkstationNameHeader: Length: 0, Offset: 0
          + Version: Windows 5.1 Build 10250 NLMPv15

Regards,
Bill Wesse
MCSE, MCTS / 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: Wednesday, October 29, 2008 3:48 PM
To: 'Adam Simpkins'
Cc: 'cifs-protocol at samba.org'
Subject: RE: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

Thanks! I will proceed with that info.

Regards,
Bill Wesse
MCSE, MCTS / 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: Adam Simpkins [mailto:simpkins at cisco.com]
Sent: Wednesday, October 29, 2008 3:09 PM
To: Bill Wesse
Cc: 'cifs-protocol at samba.org'
Subject: Re: (More): Status: SRX080803600053: [MS-NLMP] raw NTLMSSP tokens in GSS-API/SPNEGO

On Wed, Oct 29, 2008 at 09:37:05AM -0700, Bill Wesse wrote:
> Adam, thank you very much for your persistence.
>
> I apologize for responding against the two issues with the same
> answer. In order to make sure I don't commit another mix-up, I have
> superseded SRX080803600053 with SRX081029600208.
>
> I did a careful backtrack on the question/response history, and
> noticed something that surprised and disappointed me: in the below
> partial RESPONSE text, we are essentially claiming that our own XP
> Client is sending an invalid NTLM SSP token.
>
> I think we confused how gss_ntlmssp.cap was generated (XP <-> 2003)
> with how raw_ntlmssp.cap was generated (which, as you noted, had the
> security blob stripped).

No, you had this part correct.  raw_ntlmssp.cap contains an unmodified
SESSION_SETUP_ANDX request generated by an XP client.  (However, in
order to generate it, I stripped the security blob from the server's
NEGOTIATE response.  If the server includes a security blob in the
NEGOTIATE response, XP clients always use SPNEGO.  With no security
blob, they use raw NTLM SSP without SPNEGO or GSS.  In the past, I
have seen some servers in the field generate NEGOTIATE responses with
no security blob, but I don't recall what OS or version they were
running.)

The gss_ntlmssp.cap traces was taken using a custom client configured
to always generate a GSS InitialContextToken for the very first
security blob exchanged.  This is the behavior one would expect from a
client that performed GSS authentication according to RFC 2743.

--
Adam Simpkins
simpkins at cisco.com



More information about the cifs-protocol mailing list