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 [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
