[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

[Greg Hudson]

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.

> 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
https://github.com/krb5/krb5/commit/bff6bbf52401f9464df365d76f0987fbf8101c5e

I am not sure if Windows has the same restriction on the client.

> If it's the client that sends the last token, as is the case in NTLMSSP,
> there's no downgrade attack here. Either we send our final packet
> without a MIC, or perhaps we'd send it with an unsolicited MIC of the
> tampered packets, and either way the server is doing to reject that. 

A downgrade attack against the client does not necessarily involve the
real server's participation after authentication.  Perhaps the attacker
wants to collect early ciphertext from the client which can be more
easily cryptoanalyzed, for instance.

In the context of HTTP this is meaningless, because the mechanism isn't
used to protect the data stream.  But the SPNEGO implementation does not
make this assumption.