[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

David Woodhouse 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:
> https://git.samba.org/?p=idra/gss-ntlmssp.git;a=summary
> https://git.samba.org/?p=idra/gss-ntlmssp.git;a=commitdiff;h=bdb7be8468140550b59d1ec6694130f51ba9a799
> 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
fairly clear-cut.

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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20140804/8e53ec03/attachment.bin

More information about the krbdev mailing list