[18910] in Kerberos_V5_Development
Re: [PATCH] Fix SPNEGO interoperability with servers implementing
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 25 18:57:19 2014
Message-ID: <53D2E0C1.8000604@mit.edu>
Date: Fri, 25 Jul 2014 18:57:05 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <1406317515.9484.12.camel@infradead.org>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
