[18937] in Kerberos_V5_Development
Re: [PATCH] Fix SPNEGO interoperability with servers implementing
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Aug 4 19:03:05 2014
MIME-Version: 1.0
In-Reply-To: <1407192780.28796.18.camel@infradead.org>
Date: Mon, 4 Aug 2014 18:02:55 -0500
Message-ID: <CAK3OfOhwH4eZogJvhA-ufu8zfb+hZbdQCQ290sHyVtE9Dkk_BQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>, Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Mon, Aug 4, 2014 at 5:53 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> It's not clear that there's *any* way a client can safely infer from the
> NTLMSSP exchange that a server really *is* one of the RFC2478ish Windows
> versions. Any feature we use to detect a 'newer' server can be disabled
> by the attacker¹, AFAICT. I can't see a better option than just to allow
> fallback without REQUEST-MIC but *only* to NTLMSSP. And perhaps only if
> enabled by a krb5.conf option? Either abusing allow_weak_crypto or
> adding something more appropriate...
That seems reasonable to me, yes.
If you're willing to fallback on a mechanism that can't do integrity
protection then you can't have downgrade detection.
Of course, if you have credentials for a mechanism like Kerberos that
can tell you a priori that you stand a good chance of succeeding, and
it does tell you that, then you shouldn't offer any other mechanisms
weaker than Kerberos. (This is a common idiom in SSHv2 GSS key
exchange clients: call gss_init_sec_context() first, and if that
doesn't fail, offer the mechanism, else don't.)
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
