[cifs-protocol] Re: Response (document change proposals): raw NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053

[Adam Simpkins]

Bill,

I've generated some new, cleaned up traces that can be included in the
documentation if you wish.  The accompanying README.txt file describes
each of the individual traces.

Below I've listed how the trace files relate to the existing
discussion.  I've also added a few additional comments about the
proposed changes:


On Thu, Aug 14, 2008 at 10:44:03PM -0700, Adam Simpkins wrote:
> On Wed, Aug 13, 2008 at 09:59:37AM -0700, Bill Wesse wrote:
> > ----------------------------------------------------------------------------
> > [MS-SPNG]: Simple and Protected Generic Security Service Application Program
> > Interface Negotiation Mechanism (SPNEGO) Protocol Extensions
> > 
> > Change:
> > 3.1.5.2 mechTypes Identification of Kerberos
> > <5>
> > 
> > To:
> > 3.1.5.2 mechTypes Identification of Kerberos
> > Windows XP, Windows Server 2003, Windows Vista, and Windows Server offer and
> > receive the mechType 1.2.840.113554.1.2.2 (Generic Security Service
> > Application Program Interface) when using Kerberos Version 5 technology),
> > { iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
> > krb5(2) }.<5>
> 
> Inside the actual note <5> in Appendix A, it would be nice to also
> mention that the inner mechToken/responseToken always contains the
> standard OID (1.2.840.113554.1.2.2) in the thisMech field, even when
> the supportedMech chosen by SPNEGO is 1.2.840.48018.1.2.2.  Windows
> servers do not accept the "truncated" OID in the thisMech field.

spnego_krb.cap shows the current Windows behavior of negotiating
1.2.840.48018.1.2.2. in the SPNEGO mechTypes list and supportedMech
field, but actually using 1.2.840.113554.1.2.2 inside the mechToken.

spnego_krb_ms_oid.cap shows that Windows servers fail the
authentication when 1.2.840.48018.1.2.2 is negotiated via SPNEGO and
this OID is also used as the thisMech field inside the mechToken.

krb_ms_oid.cap shows that Windows servers fail the authentication when
1.2.840.48018.1.2.2 is used as the thisMech field without SPNEGO.
And, for comparison, krb.cap shows that Windows servers accept the
standard KRB5 OID without SPNEGO.


> > ----------------------------------------------------------------------------
> > [MS-SMB]: Server Message Block (SMB) Protocol Specification
> > 
> > 3.2.4.2.3  User Authentication
> > 

<snip>

> Thanks for the proposed changes.  I have a few suggestions that might
> improve upon this:

<snip>

> With these changes, it could look perhaps something like:
> 
>   Windows accepts raw NTLM NEGOTIATE messages that are not embedded in
>   [RFC2743] InitialContextTokens in the SecurityBlob of an
>   SMB_COM_SESSION_SETUP_ANDX request packet. This was introduced in
>   the NTLMv2 implementation of Windows NT 4 Service Pack 4.  Windows
>   servers do not accept NTLM messages that are properly contained
>   inside a GSS InitialContextToken.  The server responds with
>   STATUS_INVALID_PARAMETER.
> 
>      Note: See the attached:
>         raw_ntlmssp.cap frame 7.
>         gss_ntlmssp.cap frame 7.

These references can remain unchanged.  The new trace files have the
same names and the SESSION_SETUP_ANDX requests are in the same frames.

>   GSSAPI/SPNEGO support for Kerberos and NTLMSSP was introduced in
>   Windows 2000.
>   
>   When SPNEGO is in use, [RFC4178] section 3.2 (c) implies a new
>   inner context should be established, and the initial mechToken
>   should be an [RFC2743] InitialContextToken.  This is done with Kerberos,
>   but not with NTLMSSP.  When NTLMSSP is chosen as the optmistic or
>   supported mechanism, Windows servers do not accept well an
>   InitialContextToken in the mechToken/responseToken field.
> 
>      Note: See the attached:
>         spnego_krb.cap frame 7
>         spnego_ntlmssp.cap frame 6.
>         spnego_gss_ntlmssp.cap [This doesn't exist yet, but I can
>                                 generate a trace to contain the
> 				RFC-compliant format when SPNEGO
> 				is in use and NTLMSSP is selected.]

With the new traces, these references would become:
        spnego_krb.cap frame 6.
	spnego_raw_ntlmssp.cap frame 6.
	spnego_gss_ntlmssp.cap frame 7.


Also, in addition to updating [MS-SMB] 3.2.4.2.3, any other protocols
affected by this behavior should also be updated.  I haven't done any
testing of this, but it seems likely that SMB2 would also exhibit the
same behavior, in which case [MS-SMB2] 3.3.5.5.3 should probably be
updated.  If NTLM-over-HTTP also behaves the same way, [MS-NTHT]
should also be updated.

If SMB2 and HTTP do behave this same way, then this behavior could
perhaps just be described once in [MS-NLMP] and then [MS-SMB],
[MS-SMB2], and [MS-NTHT] could just contain references to that
description.


In addition to the changes already proposed, I think it would also be
nice to update [MS-SPNG] 3.2.5.2 (Universal Receiver), and item <8> in
Appendix A.

As I have mentioned earlier, the "Universal Receiver" behavior with
regards to Kerberos does not appear to be a Windows extension.  This
behavior (demonstrated in krb.cap) complies with RFC 2743, RFC 1964,
and RFC 4121.

With regards to the NTLM "Universal Receiver" behavior, the only
aspect that seems to be a Windows extension is the fact that the
first message is not a GSS InitialContextToken.  If the first request
used a GSS InitialContextToken (as shown in gss_ntlmssp.cap), this
behavior would comply with RFC 2743.  The lack of a GSS
InitialContextToken is already documented by the proposed changes to
[MS-SMB] 3.2.4.2.3, and it doesn't seem to be related to SPNEGO itself.

Based on these facts, I think that [MS-SPNG] 3.2.5.2 and item <8> in
Appendix A could perhaps be removed entirely.

-- 
Adam Simpkins
simpkins at cisco.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auth_traces.zip
Type: application/zip
Size: 15183 bytes
Desc: not available
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080820/e32cb544/auth_traces.zip