[16566] in Kerberos_V5_Development
Re: wrong checksum type for arcfour-hmac-md5
daemon@ATHENA.MIT.EDU (Stefan (metze) Metzmacher)
Tue Dec 28 08:26:08 2010
Message-ID: <4D19E55B.40209@samba.org>
Date: Tue, 28 Dec 2010 14:25:47 +0100
From: "Stefan (metze) Metzmacher" <metze@samba.org>
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@oracle.com>
In-Reply-To: <20100916164752.GI3982@oracle.com>
Cc: Luke Howard <lukeh@padl.com>, "krbdev@mit.edu Dev List" <krbdev@mit.edu>
Content-Type: multipart/mixed; boundary="===============1446529906=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1446529906==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig6C59C84AE6020886976741D2"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6C59C84AE6020886976741D2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am 16.09.2010 18:47, schrieb Nicolas Williams:
> On Thu, Sep 16, 2010 at 12:39:32PM -0400, Greg Hudson wrote:
>> On Thu, 2010-09-16 at 12:21 -0400, Luke Howard wrote:
>>> Here we have to balance security against interoperability. Is it
>>> possible to get the third-party server fixed?
>>
>> I don't think there's a security issue here; the authenticator checksu=
m
>> doesn't need to be keyed. The question is what the fix looks like:
>>
>> 1. Samba uses a proper GSSAPI checksum in its homegrown GSSAPI code.
>> This is the ideal fix, but might be too difficult.
>>
>> 2. Samba uses krb5_auth_con_set_req_cksumtype() to cause an MD5 checks=
um
>> to be used when the enctype is RC4.
>>
>> 3. MIT krb5 switches to using MD5 checksums with RC4 keys in
>> authenticators only.
>>
>> The downside of (3) is that it's extra complexity in our code base for=
>> the sake of an improper use case (Samba using regular AP-REQ checksums=
>> in a GSSAPI AP-REQ). The upside is that it makes us consistent with
>> Heimdal and MS clients.
>=20
> I prefer (1) -- it's not that hard since MIT krb5 already has the
> necessary hook for this, and that is how the MIT krb5 GSS mech installs=
> that 0x8003 "checksum". Besides, it will give Samba's implementation o=
f
> the krb5 mech a better chance to evolve, which will probably turn out t=
o
> be necessary in the future.
>=20
> (Incidentally, many, many years after RFC1964 we're still paying a
> price for that 0x8003 hack. It pays to do things cleanly.)
I've fixed it using the 0x8003 checksum in cifs-utils.
This discovered we used a strange method to specify null channel bindings=
in samba. Now we use 16 zero bytes to specify GSS_C_NO_CHANNEL_BINDINGS
correctly.
That finally fixed the bug.
metze
--------------enig6C59C84AE6020886976741D2
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.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0Z5VsACgkQm70gjA5TCD8xAwCfbwb1FYmeWzV1cMfMasi/UW9W
kB4AnjCzkWnX4YA3iLzy9pfaXuJ4DeXT
=UodM
-----END PGP SIGNATURE-----
--------------enig6C59C84AE6020886976741D2--
--===============1446529906==
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
--===============1446529906==--
