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: '[EMAIL PROTECTED]' 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:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2008 3:09 PM To: Bill Wesse Cc: '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol