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

[Adam Simpkins]

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.


> -----------------------------------------------------------------------------
> [MS-SMB]: Server Message Block (SMB) Protocol Specification
> 
> 3.2.4.2.3  User Authentication
> 
> Add a <Windows Behavior #> reference (suggested text shown below) to the
> 'Extended Security' subtopic.
> 
> <Windows Behavior #>
> 
> Windows accepts raw NTLM messages that are not embedded in [RFC4178] SPNEGO
> messages ([MS-SPNG] 3.2.5.2 Universal Receiver) 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.
> 
>    Note: See the attached:
>       raw_ntlmssp.cap frame 7.
> 
> GSSAPI/SPNEGO support for Kerberos and NTLMSSP was introduced in Windows
> 2000.
> 
> [RFC4178] section 3.2 (c)' implies a new inner context should be established.
> This is done with Kerberos, but not with NTLMSSP. Additionally, Windows does
> not accept GSS InitialContextTokens containing NTLMSSP within a new inner
> context.
> 
>    Note: See the attached:
>       spnego_krb.cap frame 7
>       spnego_ntlmssp.cap frame 6.
>       gss_ntlmssp.cap frame 7 (server responds with STATUS_INVALID_PARAMETER)


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

In the first sentence, I think it would be correct to say "Windows
accepts raw NTLM messages that are not embedded in [RFC2743]
InitialContextTokens."  GSS-API allows any (supported) mechanism to be
used without SPNEGO; however, it does require that the first token
always be an InitialContextToken.  The Windows specific behavior here
is simply the missing InitialContextToken, not the lack of SPNEGO.
(It would also be nice to fix this in MS-SPNG.  As I have mentioned
here and in previous emails, the "Universal Receiver" behavior
described in MS-SPNG isn't particularly a Windows-specific extension;
only the lack of an InitialContextToken for NTLMSSP is.)

I think it would also be better to reference gss_ntlmssp.cap after
the first paragraph, rather than the second.  gss_ntlmssp.cap shows
how the SecurityBlob should look like (according to RFC 2743) when
SPNEGO is not in use, and raw_ntlmssp.cap shows what Windows clients
actually generate.

For the second paragraph, I don't believe I ever sent you a trace
showing how the SecurityBlob should look like when SPNEGO is in use
and NTLMSSP is selected as the mechanism.  I can probably generate one
if you would like, to contrast with the current Windows behavior
(spnego_ntlmssp.cap).


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.

  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.]


Also, one other request with regard to the changes: I would prefer if
these exact versions of raw_ntlmssp.cap and gss_ntlmssp.cap aren't
included in the WSPP documentation.  These files refer to Cisco in the
NativeOS and NativeLanMan fields in some of the SESSION_SETUP_ANDX
requests.

I'm out of the office this week, but I should be able to generate some
"santized" trace files next week that can be included in the
documentation.

Again, thanks for the time and attention you have given to this
matter.

-- 
Adam Simpkins
simpkins at cisco.com