[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478
Stefan (metze) Metzmacher
metze at samba.org
Mon Aug 4 18:09:57 EDT 2014
Hi Greg, hi David,
> On 08/04/2014 10:10 AM, David Woodhouse wrote:
>> If the intention was that new servers and clients must *always* require
>> MIC processing without regard to backward compatibility, there was
>> absolutely no need for that change. Just send and check/require the MIC
>> unconditionally (when the underlying mechanism supports it), and that's
>> all there is to it.
> "Always" is oversimplifying. The MIC is not required when the
> optimistic mech is negotiated, or when the negotiated mech does not
> support integrity protection. (We do not currently check the latter
> condition. That may give us a path forward since NTLM as negotiated
> with an old Windows server won't support integrity protection, and we
> can check this after the internal context is established.)
> The client can still deduce the MIC requirement without the benefit of
> the requires-mic flag, of course.
NTLMSSP in windows 2000 and 2003 supports integrity and privacy protection.
>> The only way that the addition of the REQUEST-MIC state makes sense, is
>> for clients to be able to tell the difference between RFC4178-compliant
>> and older servers.
> Section 5 flatly states: "In all other cases, MIC tokens MUST be
> exchanged after the mechanism context is fully established." I cannot
> reconcile your interpretation with that statement. Appendix C also
> states, "If at least one of the two peers implements the updated pseudo
> mechanism in this document, the negotiation is protected."
> It is conceivable that the bit was added for interoperablity, and then
> the interoperability constraints were tightened for security, to the
> point where the bit is no longer actually needed. I was hoping to find
> support for this hypothesis in the history of the RFC 4178 drafts, but
> even the -00 version of the draft contains all of the elements we're
> talking about (the presence of the request-mic flag, the verbiage on how
> to react to it, and the flat requirement of exchanging MICs). So this
> is complete speculation.
>> FWIW I tested on Windows 7, with a fake server. My client (using SSPI)
>> sends a Kerberos token, and the server sends back:
>> Proxy-Authenticate: Negotiate oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=
>> That is, a SPNEGO "no, try GSS-NTLMSSP" with ACCEPT-INCOMPLETE. At which
>> point Windows happily falls back to GSS-NTLMSSP as requested.
> However, note that a current Windows server requires a MIC exchange if
> NTLMSSP with integrity protection is selected (even if it is the
> optimistic mechanism). See
> I am not sure if Windows has the same restriction on the client.
This is the ntlmssp code:
New versions of NTLMSSP indicate their knowledge about RFC4178 to the
which gives the SPNEGO layer a chance to decide if the peer expects a
There're also strange tricks where windows tries to workaround the situation
where the client generated a MechListMic, but the server ignores it.
[MS-SPNG] 220.127.116.11 NTLM RC4 Key State for MechListMIC and First Signed
I think this doesn't work as intended as they forgot to also reuse the
same sequence number...
So this is tricky to get right and needs a lot of testing.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 246 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140805/c2e88489/attachment.bin
More information about the krbdev