[cifs-protocol] Status: raw NTLMSSP tokens in GSS-API/SPNEGO
(SRX080803600053)
Bill Wesse
billwe at microsoft.com
Fri Sep 5 11:20:54 GMT 2008
Good morning Adam. Documentation development advises me they are waiting for feedback from the Security team on Windows Behaviors with regards to NTLM and SPNEGO blobs.
Thanks for your patience.
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: Bill Wesse
Sent: Thursday, September 04, 2008 9:24 AM
To: 'Adam Simpkins'
Subject: RE: [cifs-protocol] Re: Response (document change proposals): raw NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053
Thanks for the heads up Adam - sorry I haven't responded sooner. Development has not yet provided any response information.
I have alerted the assigned developers!
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: Wednesday, September 03, 2008 2:51 PM
To: Bill Wesse
Subject: Re: [cifs-protocol] Re: Response (document change proposals): raw NTLMSSP tokens in GSS-API/SPNEGO? SRX080803600053
Bill,
I haven't seen an update on this issue in a while. Any news?
--
Adam Simpkins
simpkins at cisco.com
On Wed, Aug 20, 2008 at 05:14:48PM -0700, Adam Simpkins wrote:
> 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
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at cifs.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol
More information about the cifs-protocol
mailing list