[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478
dwmw2 at infradead.org
Mon Aug 4 18:53:00 EDT 2014
On Tue, 2014-08-05 at 00:09 +0200, Stefan (metze) Metzmacher wrote:
> > However, note that a current Windows server requires a MIC exchange if
> > NTLMSSP with integrity protection is selected (even if it is the
> > optimistic mechanism). See
> > https://github.com/krb5/krb5/commit/bff6bbf52401f9464df365d76f0987fbf8101c5e
> > I am not sure if Windows has the same restriction on the client.
> This is the ntlmssp code:
> New versions of NTLMSSP indicate their knowledge about RFC4178 to the
> SPNEGO layer, which gives the SPNEGO layer a chance to decide if the
> peer expects a MechListMic or not.
That's an orthogonal (and solved) issue, surely?
It's one thing to say "NTLMSSP did negotiate a MIC, therefore we know
that Windows SPNEGO will require mechlistMIC even if NTLMSSP was the
optimistic mechanism and SPNEGO wouldn't normally require it." That's
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...
¹ I've been vaguely hacking gss-ntlmssp to mangle its own feature flags
as if there were such an attacker and prove this hypothesis. So far
I haven't succeeded but I'm blaming that mostly on my stupidity today.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140804/8e53ec03/attachment.bin
More information about the krbdev