Good morning Mr. Simpkins. I have conducted an initial
investigation of the questions you raised concerning NTLMSSP tokens carried in
GSS-API/SPNEGO. The below splits your comments and questions into 4 parts. I
have also provided extracts from various references in the responses.
Please let me know if I have sufficiently addressed your
concerns; please do not hesitate to comment on my answers and pose any
additional questions.
==============================================================================
Question 1
==========
spnego_ntlmssp.cap
frame 6
Question / Comment:
-------------------
This was taken between a client running Windows XP SP3 and a
server running
Windows Server 2003 SP2 (Enterprise Edition).
Frame 6 contains the initial SESSION_SETUP_ANDX
request. This contains a
GSS-API InitialContextToken that uses SPNEGO. The
mechToken inside the
SPNEGO NegTokenInit contains just raw NTLMSSP data.
According to RFC 4178
section 3.2 item (c), this should be a GSS
InitialContextToken.
Response:
---------
Please correct me if I missed anything.
I have annotated spnego_ntlmssp.cap frame 6
below, and it seems to me
that we meet the specification, given that
[RFC2078] defines the
InnerContextToken (+ ThisMech: SpnegoToken
(1.3.6.1.5.5.2) ([RFC2078]))
to be defined as mechanism-specific, not
requiring ASN.1 encoding.
Please see 'Reference 1' below; [MS-SMB]
specifies additional information
in sections 2.2.4 and 3.2.4.2.3:
SecurityBlob (variable): This
field MUST be the authentication token
sent to the server, as
specified in section 3.2.4.2.3 and [RFC4178].
[RFC4178] specifies the 'InitialContextToken'
to be in the format
defined in [RFC2078]:
[APPLICATION 0]
IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
o See 'Reference 2' [RFC2078] below Section 3.1
for the description
of the InitialContextToken.
Definition:
innerContextToken
ANY DEFINED BY thisMech
o [RFC4178] : See 'Reference 5' below for
the BNF.
3.2. Negotiation Tokens
The syntax of the negotiation
tokens follows the InitialContextToken
syntax defined in [1]
([RFC2078])
See 'Reference 5' [RFC4178]
below for the negotiation token BNF.
o In the capture details below, 'NtlmSsp: NTLM
NEGOTIATE MESSAGE' is
indented, since NTLM is considered
a separate protocol by Network
Monitor 3.2. As you know, the
InnerContextToken is from offset
0x7F - 0xBE, and the negotiate
message is encapsulated at offset
0x97 - 0xBE.
See 'Reference 1 / Extended
Security' [MS-SMB] below.
ThisMech: SpnegoToken
(1.3.6.1.5.5.2) See 'Reference 3' below.
OID Repository - Home
http://www.oid-info.com/
iso(1) identified-organization(3)
dod(6) internet(1) security(5)
mechanisms(5) snego(2)
Child OID: modules(4)
Ref:
http://www.ietf.org/rfc/rfc2743.txt
------------------------------------------------------------------------------
Capture Details (Network Monitor 3.2)
- CSessionSetupAndXNTLMESS:
WordCount: 12 (0xC)
ANDXCommand: No Secondary Command
255(0xFF)
AndXReserved: 0 (0x0)
ANDXOffset: 236 (0xEC)
MaxBufferSize: 16644 (0x4104)
MaxMpxCount: 50 (0x32)
VcNumber: 0 (0x0)
SessionKey: 0 (0x0)
SecurityBlobLength: 74 (0x4A)
Reserved: 0 (0x0)
+ Capabilities: 0xA00000D4
ByteCount: 177 (0xB1)
- SecurityBlob:
- GssApi:
+ ApplicationHeader:
+ ThisMech: SpnegoToken
(1.3.6.1.5.5.2) ([RFC2078])
- InnerContextToken: 0x1
- SpnegoToken: 0x1
+ Tag0:
-
NegTokenInit:
([RFC2478] NegotiationToken, negTokenInit [0] NegTokenInit)
+ SequenceHeader:
+ Tag0:
-
MechTypes:
([RFC2478] mechTypes [0] MechTypeList OPTIONAL)
+
SequenceHeader:
+ MechType:
NtlmSsp (1.3.6.1.4.1.311.2.2.10)
+
Tag2:
([RFC2478] mechToken [2] OCTET STRING OPTIONAL)
+
OctetStringHeader:
MechToken:
0x1
(NtlmSsp: NTLM NEGOTIATE MESSAGE)
+ UnicodeParameters:
ANDXPadding: Binary Large Object (2
Bytes)
- NtlmSsp: NTLM NEGOTIATE MESSAGE
Signature: NTLMSSP
MessageType: Negotiate Message
(0x00000001)
- NtlmsspNegotiateMessage:
+ NegotiateFlags: 0xE2088297 (NTLM v2128-bit
encryption, Always Sign)
+ WorkstationDomainHeader: Length: 0, Offset: 0
+ WorkstationNameHeader: Length: 0, Offset: 0
+ Version: Windows 5.1 Build 10250 NTLMSSPv15
0075
60 48 06 06 2B 06 01 05 05 02 GssApi:
007E
A0 InnerContextToken: (SpnegoToken:)
0080 3E 30 3C A0 0E 30 0C 06 0A 2B 06 01 04 01 82 37
0090 02 02 0A A2 2A 04 28
0096
4E 54 4C 4D 53 53 50 00 01 MechToken: (NtlmSsp: NTLM NEGOTIATE MESSAGE)
00A0 00 00 00 97 82 08 E2 00 00 00 00 00 00 00 00 00
00B0 00 00 00 00 00 00 00 05 01 28 0A 00 00 00 0F
==============================================================================
Question 2
==========
gss_ntlmssp.cap
frame 7
Question / Comment:
-------------------
Another related point that should probably be documented is
that Windows
servers do not seem to accept well-formed GSS
InitialContextTokens containing
NTLMSSP. I have attached a trace of that, too.
(The server is the same
Windows Server 2003 system as in the other traces.)
Response:
---------
I believe this refers to the same GSS-API
construction information I
referenced in Question 1. above.
ThisMech: NtlmSsp (1.3.6.1.4.1.311.2.2.10)
OID Repository - Home
http://www.oid-info.com/
iso(1) identified-organization(3) dod(6)
internet(1) private(4)
enterprise(1) microsoft(311) 2
Child OID: modules(4)
Ref: http://www.ietf.org/rfc/rfc2743.txt
------------------------------------------------------------------------------
Capture Details (Network Monitor 3.2)
- CSessionSetupAndXNTLMESS:
WordCount: 12 (0xC)
ANDXCommand: No Secondary Command
255(0xFF)
AndXReserved: 0 (0x0)
ANDXOffset: 146 (0x92)
MaxBufferSize: 16384 (0x4000)
MaxMpxCount: 50 (0x32)
VcNumber: 1 (0x1)
SessionKey: 0 (0x0)
SecurityBlobLength: 46 (0x2E)
Reserved: 0 (0x0)
+ Capabilities: 0x8000C25C
ByteCount: 87 (0x57)
- SecurityBlob:
- GssApi:
+ ApplicationHeader:
+ ThisMech: NtlmSsp (1.3.6.1.4.1.311.2.2.10)
InnerContextToken: 0x1
+ UnicodeParameters:
ANDXPadding: Binary Large Object (2
Bytes)
- NtlmSsp: NTLM NEGOTIATE MESSAGE
Signature: NTLMSSP
MessageType: Negotiate Message
(0x00000001)
- NtlmsspNegotiateMessage:
+ NegotiateFlags: 0xA0000217 (NTLM v1128-bit
encryption, , Sign)
+ WorkstationDomainHeader: Length: 0, Offset: 0
+ WorkstationNameHeader: Length: 0, Offset: 0
0081 60
2C
GssApi:
0083
06 0A 2B 06 01 04 01 82 37 02 02 0A ThisMech: NtlmSsp
(1.3.6.1.4.1.311.2.2.10)
008F
4E InnerContextToken: 0x1 (NtlmSsp: NTLM NEGOTIATE MESSAGE)
0090 54 4C 4D 53 53 50 00 01 00 00 00 17 02 00 A0 00
00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==============================================================================
Question 3
==========
spnego_krb.cap
frame 7
Question / Comment:
-------------------
This was taken between a client running Windows XP SP3 and a
server running
Windows Server 2003 SP2 (Enterprise Edition), using Kerberos
over SPNEGO.
In this trace, the mechToken is a GSS InitialContextToken.
Response:
---------
I agree totally; thank you for the detail.
ThisMech: SpnegoToken (1.3.6.1.5.5.2) See
'Reference 3' ([RFC2743]) below.
OID Repository - Home
http://www.oid-info.com/
iso(1) identified-organization(3) dod(6)
internet(1) security(5)
mechanisms(5) snego(2)
Child OID: modules(4)
Ref: http://www.ietf.org/rfc/rfc2743.txt
NtlmSsp: NTLM NEGOTIATE MESSAGE
- this is indented, since NTLM is considered a
separate protocol by Network
Monitor 3.2. The InnerContextToken
is from offset 0x7F - 0xBE. The
negotiate message is encapsulated
(offset 0x97 - 0xBE).
------------------------------------------------------------------------------
Capture Details (Network Monitor 3.2)
- CSessionSetupAndXNTLMESS:
WordCount: 12 (0xC)
ANDXCommand: No Secondary Command
255(0xFF)
AndXReserved: 0 (0x0)
ANDXOffset: 2772 (0xAD4)
MaxBufferSize: 16644 (0x4104)
MaxMpxCount: 50 (0x32)
VcNumber: 0 (0x0)
SessionKey: 0 (0x0)
SecurityBlobLength: 2610 (0xA32)
Reserved: 0 (0x0)
+ Capabilities: 0xA00000D4
ByteCount: 2713 (0xA99)
- SecurityBlob:
- GssApi:
+ ApplicationHeader:
+ ThisMech: SpnegoToken
(1.3.6.1.5.5.2)
- InnerContextToken: 0x1
- SpnegoToken: 0x1
+ Tag0:
- NegTokenInit:
+ SequenceHeader:
+ Tag0:
+ MechTypes:
+ Tag2:
+
OctetStringHeader:
- MechToken: 0x1
+
MsKerberosToken: 0x1
0070
60 82 0A 2E 06 06 2B 06 01 05 05 GssApi:
0080 02
....
0081 A0 82 0A 22 30 82 0A 1E A0 24
30 22 06 09 2A InnerContextToken:
0090 86 48 82 F7 12 01 02 02 06 09 2A 86 48 86 F7 12
00A0 01 02 02 06 0A 2B 06 01 04 01 82 37 02 02 0A A2
00B0 82 09 F4 04 82 09 F0
....
00B7
60
82 09 EC 06 09 2A 86 48 MechToken: (MsKerberosToken:)
00C0 86 F7 12 01 02 02
00C6
01 00 6E 82 09 DB 30 82 09 D7 InnerContextToken:
00D0 A0 03 02 01 05 A1 03 02 01 0E A2 07 03 05 00 20
....
==============================================================================
Question 4
==========
raw_ntlmssp.cap
frame 7
Question / Comment:
-------------------
Here's another trace of a Windows XP SP3 client sending raw
NTLMSSP
(no SPNEGO) to a server. This server is just a proxy
in front of a Windows
Server 2003 machine, but I configured it to strip off the
securit blob from
the server's NEGOTIATE response before sending it to the
client.
This causes the client to send raw NTLMSSP instead of SPNEGO.
Based on the documentation in MS-SMB 2.2.4 and MS-SMB
3.2.4.2.3, I would
expect the client to send a GSS authentication token here
(i.e., an
InitialContextToken). However, in this case the client
sends raw NTLMSSP
data.
A reasonable explanation for this would be that Microsoft's
GSS-API
implementation accepts raw NTLMSSP data for the first token,
in addition to
normal GSS InitialContextTokens. I think this is what
item <8> of MS-SPNG
Appendix A is trying to explain, but it mentions this as an
extension of
SPNEGO, not GSS-API. Assuming that this is a general
extension that Microsoft
has made to their GSS-API implementation, this would also
explain the lack of
the InitialContextToken for NTLMSSP when SPNEGO is used.
Response:
---------
You are indeed correct - this, of course, per
[MS-SPNG] <8>, is not
GSS-API. Please see 'Reference 1 / Implicit
NTLM' ([MS-SMB]) below
for additional information.
Reference:
[MS-SPNG]: Simple and Protected Generic
Security Service Application
Program Interface Negotiation Mechanism
(SPNEGO) Protocol Extensions
<8> Section 3.2.5.2: This behavior is
present on Windows 2000, Windows XP,
Windows Server 2003,
and Windows Vista. For backward compatibility and
historical reasons, a
Windows implementation of SPNEGO has the
following behavior: it
accepts raw Kerberos messages that are based on
[RFC4121] and
[RFC4120], and it accepts raw NTLM messages that are not
embedded in [RFC4178]
SPNEGO messages. This behavior is known as the
universal receiver
behavior.
------------------------------------------------------------------------------
Capture Details (Network Monitor 3.2)
- CSessionSetupAndXNTLMESS:
WordCount: 12 (0xC)
ANDXCommand: No Secondary Command
255(0xFF)
AndXReserved: 0 (0x0)
ANDXOffset: 202 (0xCA)
MaxBufferSize: 4356 (0x1104)
MaxMpxCount: 50 (0x32)
VcNumber: 0 (0x0)
SessionKey: 0 (0x0)
SecurityBlobLength: 40 (0x28)
Reserved: 0 (0x0)
+ Capabilities: 0xA00000D4
ByteCount: 143 (0x8F)
SecurityBlob:
+ UnicodeParameters:
ANDXPadding: Binary Large Object (2
Bytes)
- NtlmSSP: NTLM NEGOTIATE MESSAGE
Signature: NTLMSSP
MessageType: Negotiate Message
(0x00000001)
- NtlmsspNegotiateMessage:
+ NegotiateFlags: 0xA2088207 (NTLM v2128-bit
encryption, Always Sign)
+ WorkstationDomainHeader: Length: 0, Offset: 0
+ WorkstationNameHeader: Length: 0, Offset: 0
+ Version: Windows 5.1 Build 10250 NTLMSSPv15
0075
4E 54 4C 4D 53 53 50 00 01 00 00 SecurityBlob: (NtlmSSP: NTLM NEGOTIATE
MESSAGE)
0080 00 07 82 08 A2 00 00 00 00 00 00 00 00 00 00
0090 00 00 00 00 00 00 05 01 28 0A 00 00 00 0F
==============================================================================
Reference 1:
============
[MS-SMB] Server Message Block (SMB) Protocol Specification
2.2.4 SMB_COM_SESSION_SETUP_ANDX Client Request Extension
...
SecurityBlob (variable): This field MUST be the
authentication token sent
to the server, as specified in section
3.2.4.2.3 and [RFC4178].
3.2.4.2.3 User Authentication
-----------------------------
...
Extended Security
-----------------
If the CAP_EXTENDED_SECURITY bit in
ServerCapabilities is set, the
SMB_COM_SESSION_SETUP_ANDX command MUST be
generated, as defined here.
Otherwise, the client MUST generate the
authentication portion, as
described in section Implicit NTLM.
The client MUST do one of the following:
o Pass the GSSNegotiateToken (if valid) to the
configured GSS
authentication mechanism to obtain
a GSS output token for the
authentication protocol exchange.
-OR-
o Choose to ignore the GSSNegotiateToken
received from the server, and give
an empty input token to the
configured GSS authentication protocol to
obtain a GSS output token for the
authentication protocol exchange.
In either case, it initializes the
GSS authentication protocol with the
MutualAuth and Delegate options,
which are specified in [MS-KILE] section
3.2.1.1.<152>
The client creates an
SMB_COM_SESSION_SETUP_ANDX request (section 2.2.4)
message. The client MUST set
CAP_EXTENDED_SECURITY in the Capabilities
field, SMB_FLAGS2_EXTENDED_SECURITY in the SMB
header Flags2 field, the
SecurityBlob field to the output token
generated above, and the
SecurityBlobLength to the token length. The Uid
field in the SMB header
MUST be set to 0.
Implicit NTLM
-------------
If the CAP_EXTENDED_SECURITY bit in
ServerCapabilities is not set, the
SMB_COM_SESSION_SETUP_ANDX request MUST be
generated, as defined here.
This is not new to the extension, but is
included for completeness.
The server MUST construct an NTLM
CHALLENGE_MESSAGE, as specified in
[MS-NLMP]. The CHALLENGE_MESSAGE is used by the
server to challenge the
client to prove its identity. The following
parameters MUST be set to the
following values.
o The Signature field is set to an 8-byte
character array that MUST contain
the ASCII string ('N', 'T', 'L',
'M', 'S', 'S', 'P', '\0').
...
The client creates the appropriate
AUTHENTICATE_MESSAGE to respond to the
CHALLENGE_MESSAGE, as specified in [MS-NLMP].
The client MUST build an
SMB_COM_SESSION_SETUP_ANDX , as specified in
[CIFS] section 4.1.2. The following fields MUST
be set to these values:
o The CaseSensitivePasswordLength field is set
to the Length of the
NtChallengeResponse from the
AUTHENTICATE_MESSAGE.
o The CaseSensitivePassword field is set to the
value of the
NtChallengeResponse field from the
AUTHENTICATE_MESSAGE.
o The CaseInsensitivePasswordLength field is
set to the Length of the
LmChallengeResponse from the
AUTHENTICATE_MESSAGE.
o The CaseInsensitivePassword field is set to
the value of the
LmChallengeResponse field from the
AUTHENTICATE_MESSAGE.
o The AccountName field is set to the value of
the UserName field
from the AUTHENTICATE_MESSAGE.
o The Pr
spnego_ntlmssp.pcap (3K) 
Some parts of this message have been removed.
Learn more about Nabble's