[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

[Greg Hudson]

On 07/25/2014 03:45 PM, David Woodhouse wrote:
> If that isn't the intention, the I wonder why the request-mic state was
> added at all.

I'm not sure.  It wouldn't be the first time that a protocol used
explicit state where implicit state would serve.

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

I think the server will wind up returning accept-incomplete because it
hasn't yet received a mic from the client.  But the client won't
necessarily see that; the attacker could alter the final message from
the server to have accept-complete state.

> 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, we have to tolerate a downgrade attack in order to interoperate
with these servers; but if we have a reason to believe we aren't talking
to an old SPNEGO implementation, we don't need to tolerate downgrade
attacks.

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

(In IRC, David indicated that he believed NTLM is subject to downgrading
the relevant bit without knowing the shared secret, but I can't confirm
that.)

It would in the case where NTLM is one of the fallback mechanisms, but
not in all negotiation scenarios.  If the negotiated mechanism is not
implemented in Server 2003, then we don't have to tolerate a downgrade
without MIC.  Likewise if the negotiated mechanism is krb5 and used RFC
4121.