[18935] in Kerberos_V5_Development
Re: [PATCH] Fix SPNEGO interoperability with servers implementing
daemon@ATHENA.MIT.EDU (Stefan (metze) Metzmacher)
Mon Aug 4 18:10:43 2014
Message-ID: <53E004B5.5080104@samba.org>
Date: Tue, 05 Aug 2014 00:09:57 +0200
From: "Stefan (metze) Metzmacher" <metze@samba.org>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>, David Woodhouse <dwmw2@infradead.org>
In-Reply-To: <53DFC4A6.5090505@mit.edu>
Cc: Simo Sorce <simo@redhat.com>, krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============1318092063=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1318092063==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="a92VS1NjevQL5EOMjg2JG6PCX5ACASFd6"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--a92VS1NjevQL5EOMjg2JG6PCX5ACASFd6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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* requir=
e
>> MIC processing without regard to backward compatibility, there was
>> absolutely no need for that change. Just send and check/require the MI=
C
>> unconditionally (when the underlying mechanism supports it), and that'=
s
>> all there is to it.
>=20
> "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 protectio=
n.
>> The only way that the addition of the REQUEST-MIC state makes sense, i=
s
>> for clients to be able to tell the difference between RFC4178-complian=
t
>> and older servers.
>=20
> 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."
>=20
> 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 ho=
w
> to react to it, and the flat requirement of exchanging MICs). So this
> is complete speculation.
>=20
>> 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=3D
>> That is, a SPNEGO "no, try GSS-NTLMSSP" with ACCEPT-INCOMPLETE. At whi=
ch
>> point Windows happily falls back to GSS-NTLMSSP as requested.
>=20
> 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/bff6bbf52401f9464df365d76f0987fbf81=
01c5e
>=20
> I am not sure if Windows has the same restriction on the client.
This is the ntlmssp code:
https://git.samba.org/?p=3Didra/gss-ntlmssp.git;a=3Dsummary
https://git.samba.org/?p=3Didra/gss-ntlmssp.git;a=3Dcommitdiff;h=3Dbdb7be=
8468140550b59d1ec6694130f51ba9a799
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 situat=
ion
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
--a92VS1NjevQL5EOMjg2JG6PCX5ACASFd6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlPgBLkACgkQm70gjA5TCD9spACgichJltiYPT/3HkX7mQlSTLp7
MR4An0Ffcatn3eqlVYlWmsMf7UFbRnOm
=Em3R
-----END PGP SIGNATURE-----
--a92VS1NjevQL5EOMjg2JG6PCX5ACASFd6--
--===============1318092063==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============1318092063==--
