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

[Bill Wesse]

My pleasure!

Here is copy of tentative text changes to the [MS-SPNG] document (these are waiting for internal approval - I will advise you as soon as the text is finalized):

==============================================================================
OID 1.2.840.113554.1.2.2 is ALWAYS included in the mechToken/responseToken.
------------------------------------------------------------------------------

Original text:

<5> Section 3.1.5.2:  Windows versions offer and accept two distinct OIDs as
    identifiers for the Kerberos authentication mechanism. The SPNEGO
    extensions consider both OIDs as equivalent and make no distinction
    between them.

    Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
    than the OID { iso(1) member-body(2) United States(840) mit(113554)
    infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
    values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
    United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
    not a known member under that OID branch; this is an error.

    Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
    do not truncate the value, and they correctly offer and receive
    1.2.840.113554.1.2.2. For compatibility reasons, the erroneous value
    (1.2.840.48018.1.2.2) is still offered and accepted by systems that run
    Windows 2000. The presence of this value can be used to determine that the
    peer is a Windows 2000 implementation.

New text:

<5> Section 3.1.5.2:  Windows versions offer and accept two distinct OIDs as
    identifiers for the Kerberos authentication mechanism. The SPNEGO
    extensions consider both OIDs as equivalent and make no distinction
    between them.

    Windows 2000 incorrectly encoded the OID for the Kerberos protocol. Rather
    than the OID { iso(1) member-body(2) United States(840) mit(113554)
    infosys(1) gssapi(2) krb5(2) }, an implementation error truncated the
    values at 16 bits. Therefore, the OID became { iso(1) member-body(2)
    United States(840) ???(48018) infosys(1) gssapi(2) krb5 (2) }. 48018 is
    not a known member under that OID branch; this is an error. The singular
    presence of this incorrect OID (1.2.840.48018.1.2.2) can be used to
    determine that the peer is a Windows 2000 implementation.

    Windows XP and later do not truncate the OID, and they correctly offer
    and receive 1.2.840.113554.1.2.2. For compatibility reasons, on Windows XP
    and later, the erroneous value (1.2.840.48018.1.2.2) is sent in addition
    to the correct value (1.2.840.113554.1.2.2) Both values are considered
    equivalent and Windows makes no distinction between the two.

    The mechToken and responseToken always contain the standard OID
    (1.2.840.113554.1.2.2) within the thisMech field, even when the
    supportedMech chosen by SPNEGO is (1.2.840.48018.1.2.2). Windows Kerberos
    servers do not accept the "truncated" OID in the thisMech field.

Regards,
Bill Wesse
MCSE / 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
We're Hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted


-----Original Message-----
From: Adam Simpkins [mailto:simpkins at cisco.com]
Sent: Friday, October 03, 2008 10:08 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 Fri, Oct 03, 2008 at 07:18:05AM -0700, Bill Wesse wrote:
> Good morning again! Our documentation development team advises me the following change will be implemented in a future posting of [MS-SMB]:
>
> [MS-SMB]: Server Message Block (SMB) Protocol Specification
> Section 3.2.4.2.3 User Authentication (Extended Security subtopic)
>
> Current Text:
>
> 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.<173>
>
> Request to update with:
>
> 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.<173> See also [MS-SPNG] section 3.2.5.2.

Okay.  Thanks for the update.

--
Adam Simpkins
simpkins at cisco.com