[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

Greg Hudson ghudson at MIT.EDU
Fri Jul 25 11:44:46 EDT 2014

On 07/25/2014 06:42 AM, David Woodhouse wrote:
> A server conforming to RFC4178 MUST send request-mic there, but it
> is equally clear that on the client side, we should deal with its
> absence. For example, the language in §5 (c) is as follows:
>     "if the negState was request-mic in the first reply from the
>      target, a mechlistMIC token MUST be included; otherwise..."

This is followed by "(Note that the MIC token exchange is required
if a mechanism other than the initiator's first choice is chosen.)"  A
mechanism may require multiple hops to complete, so there can be
multiple SPNEGO exchanges even when the client's preferred mechanism was

> Other language in RFC4178 which supports this interpretation includes
> the whole of Appendix C, which explains the changes since RFC2478.

It is not clear to me that appendix C promises compatibility with Server
2003 in any case but when the preferred mechanism is negotiated.

> So the vulnerability is that a hypothetical attacker can trick us into
> selecting a mechanism that both client and server were prepared to use
> anyway, and which the server *would* have accepted if we'd happened to
> try it first.

It may seem like a marginal gain in security, but RFC 4178 went to
considerable effort to prevent this kind of downgrade attack, and I
don't think we want to just throw that out the window.  Nor do I think
our SPNEGO implementation should assume that one of the fallback
mechanisms is too weak to reliably provide MIC protection, or that
SPNEGO is taking place within a higher-level negotiation which is
subject to downgrade.

Heimdal has a complicated but acceptable compromise, which is to query
the negotiated security context for whether the peer ought to have
updated SPNEGO, and only insist on a downgrade MIC exchange if the
mechanism says yes.  I think we would accept a good implementation of
that facility (where "good" includes not making any overly long
functions significantly longer).  We should probably use the same query
OID as Heimdal, although I really wish that OID were fail-closed instead
of fail-open.

I have opened https://krbdev.mit.edu/rt/Ticket/Display.html?id=7975
about this negotiation scenario.  Although I am not in favor of the
simple solution, I do agree that it is important to solve the
interoperability problem in some way.

More information about the krbdev mailing list