[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

[David Woodhouse]

On Fri, 2014-07-25 at 11:44 -0400, Greg Hudson wrote:
> On 07/25/2014 06:42 AM, David Woodhouse wrote:
> > 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.

If that isn't the intention, the I wonder why the request-mic state was
added at all. If servers required to send it and clients were expected
to abort the connection when they didn't see it, surely there's no
point? They could have just continued to use accept-incomplete as in
RFC2478, and always behave as if it were sent — basically making the MIC
mandatory where the underlying mechanism supports it.

Then there wouldn't be any need for them to explain what the client
should do when request-mic *isn't* sent, as they did.

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

Perhaps I'm missing something, but I don't think the patch just throws
that protection out of the window, does it?

A server compliant with RFC4178 will not only send request-mic, but it
will also expect us to actually *send* a MIC. If a hypothetical attacker
downgrades 'request-mic' in the reply to 'accept-incomplete', the server
isn't actually going to accept our authentication, surely? So my patch
doesn't seem to open us up to a viable downgrade attack there unless
I've misunderstood something.

My patch is only about interoperability with Windows RFC2478ish servers,
which don't send request-mic and won't check for or generate a MIC. And
it's a straight choice of whether we want to interoperate with those or
not, surely? Yes, *if* we talk to such a server then there's a downgrade
attack. We can be downgraded to a mechanism that is configured to be
acceptable, but just isn't preferred.

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

So we'd ask the NTLMSSP mechanism, after it's succeeded in establishing
a security context, what version of Windows it thinks it was talking to
and thus whether it's reasonable for us to have seen accept-incomplete
where we wanted request-mic? 

That could work, I suppose, but I'm not 100% convinced that it isn't
spoofable too by our hypothetical attacker by tampering with the NTLMSSP
exchange — which would render the whole thing just a pointless piece of
complexity. I'd have to check (or ask Simo ☺).

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

As I said, just disabling IAKERB or preferably being able to install
GSS-NTLMSSP at a higher priority would help. But there *are* cases where
we actually try krb5, with the *wrong* SPN, and then have to fall back
to NTLMSSP. So fixing the "real" problem would be good, from more than
just an engineering purity point of view.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140725/60c42431/attachment.bin