[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