[PATCH] Fix SPNEGO interoperability with servers implementing RFC2478

[Stefan (metze) Metzmacher]

Hi Greg, hi David,

> On 08/04/2014 10:10 AM, David Woodhouse wrote:
>> If the intention was that new servers and clients must *always* require
>> MIC processing without regard to backward compatibility, there was
>> absolutely no need for that change. Just send and check/require the MIC
>> unconditionally (when the underlying mechanism supports it), and that's
>> all there is to it.
> 
> "Always" is oversimplifying.  The MIC is not required when the
> optimistic mech is negotiated, or when the negotiated mech does not
> support integrity protection.  (We do not currently check the latter
> condition.  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.)
> The client can still deduce the MIC requirement without the benefit of
> the requires-mic flag, of course.

NTLMSSP in windows 2000 and 2003 supports integrity and privacy protection.

>> The only way that the addition of the REQUEST-MIC state makes sense, is
>> for clients to be able to tell the difference between RFC4178-compliant
>> and older servers.
> 
> Section 5 flatly states: "In all other cases, MIC tokens MUST be
> exchanged after the mechanism context is fully established."  I cannot
> reconcile your interpretation with that statement.  Appendix C also
> states, "If at least one of the two peers implements the updated pseudo
> mechanism in this document, the negotiation is protected."
> 
> It is conceivable that the bit was added for interoperablity, and then
> the interoperability constraints were tightened for security, to the
> point where the bit is no longer actually needed.  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.
> 
>> FWIW I tested on Windows 7, with a fake server. My client (using SSPI)
>> sends a Kerberos token, and the server sends back:
>>      Proxy-Authenticate: Negotiate oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=
>> That is, a SPNEGO "no, try GSS-NTLMSSP" with ACCEPT-INCOMPLETE. At which
>> point Windows happily falls back to GSS-NTLMSSP as requested.
> 
> 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.

There're also strange tricks where windows tries to workaround the situation
where the client generated a MechListMic, but the server ignores it.

See http://msdn.microsoft.com/en-us/library/gg465664.aspx
[MS-SPNG] 3.3.5.1 NTLM RC4 Key State for MechListMIC and First Signed
Message
I think this doesn't work as intended as they forgot to also reuse the
same sequence number...

So this is tricky to get right and needs a lot of testing.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu.ezproxyberklee.flo.org/pipermail/krbdev/attachments/20140805/c2e88489/attachment.bin