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

[Adam Simpkins]

On Fri, Oct 31, 2008 at 09:06:38AM -0700, Bill Wesse wrote:
> 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'.

I haven't used Network Monitor to look at the traces (I mostly use
Wireshark), but based on the output you list below, the
InnerContextToken label appears to be correct.  The
InitialContextToken is the entire GSS token, consisting of both the
ThisMech and InnerContextToken fields, plus the APPLICATION 0 header
tag.

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

The outer (SPNEGO) token is a proper GSS InitialContextToken, so that
aspect is in compliance with RFC 2743.  However, the mechToken field
in the SPNEGO negTokenInit should also be a GSS InitialContextToken,
but isn't.

Please refer to our earlier discussion regarding RFC 4178 section 3.2:

http://lists.samba.org/archive/cifs-protocol/2008-August/000284.html
http://lists.samba.org/archive/cifs-protocol/2008-August/000299.html



> 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'

InnerContextToken is correct here.

The "GssApi:" label above indicates the InitialContextToken.  It
could perhaps be changed to "GssApi: InitialContextToken" if
desired.

>       - 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

Based to my interpretation of RFC 4178, this MechToken field should be
a GSS InitialContextToken containing NTLM SSP, instead of just a raw
NTLM SSP token.

Note that this seems to be exactly the same issue that occurs when
SPNEGO isn't in use.  The Microsoft NTLM SSP implementation never
outputs a GSS InitialContextToken for the first token (as we've seen
without SPNEGO in the raw_ntlmssp.cap trace).  If the SPNEGO
implementation is just calling GSS_Init_sec_context() to get the inner
MechToken field (as described in RFC 4178), then this single NTLM SSP
issue would be causing this behavior with SPNEGO too.


>          - 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

-- 
Adam Simpkins
simpkins at cisco.com