[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

David Woodhouse dwmw2 at infradead.org
Mon Aug 4 19:22:30 EDT 2014


On Mon, 2014-08-04 at 18:02 -0500, Nico Williams wrote:
> On Mon, Aug 4, 2014 at 5:53 PM, David Woodhouse <dwmw2 at 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.

That was the patch I posted at 14:10:16 GMT, albeit without the
krb5.conf bit. Which, on reflection, seems like the wrong thing to do
anyway; this is SPNEGO code not krb5 so krb5.conf isn't the right place
to tweak its behaviour.

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

Hm, I frequently need to fall back to NTLMSSP when I *do* have Kerberos
credentials. SPN mismatches are all too common. And since the Windows
clients will silently fall back to NTLMSSP, the admins neither notice
nor care.

We get a slightly higher hit rate for Kerberos in our environment by
enabling 'rdns-=true' but that has its own issues...

-- 
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/20140805/9a580685/attachment.bin


More information about the krbdev mailing list