[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

David Woodhouse dwmw2 at infradead.org
Mon Aug 4 14:29:06 EDT 2014

On Mon, 2014-08-04 at 13:36 -0400, Greg Hudson wrote:
>  That may give us a path forward since NTLM as negotiated
> with an old Windows server won't support integrity protection, and we
> can check this after the internal context is established.)

... as negotiated with an old Windows server, or with an attacker
sitting in the middle clearing the interesting bits in the feature
flags :)

There's no point in that check. You might as well reduce it to "if
NTLMSSP". Which I already did :)

> The client can still deduce the MIC requirement without the benefit of
> the requires-mic flag, of course.

In practice I'm happy for the client to still produce and "require" the
MIC. My first patch did precisely that, in fact, and *only* avoided the
GSS_S_DEFECTIVE_TOKEN return, leaving sc->mic_reqd=1. That works because
when we produce a MIC it's ignored by the server anyway — and although
we "require" one, fairly much no clients actually feed the final token
back into gss_init_sec_context() after a successful authentication
anyway. Many protocols like IMAP don't even have a *way* for that to
happen, and web clients just don't bother. If they get a 200 successful
response, they're done.

>  I was hoping to find
> support for this hypothesis in the history of the RFC 4178 drafts, but
> even the -00 version of the draft contains all of the elements we're
> talking about (the presence of the request-mic flag, the verbiage on how
> to react to it, and the flat requirement of exchanging MICs).  So this
> is complete speculation.

Are any of the authors still available to ask? If their implementation
in Windows isn't considered to be sufficient evidence of their intent,
that is...

-------------- 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/cff5df7d/attachment.bin

More information about the krbdev mailing list