[16729] in Kerberos_V5_Development
Re: RC4 Weak Key checks
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Fri Mar 25 15:23:06 2011
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4D8CEB8E.8020402@secure-endpoints.com>
Date: Fri, 25 Mar 2011 15:22:54 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <1300985060.10465.28.camel@t410>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============0410272541=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0410272541==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigDCDD22A88454AC7CF86C464C"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDCDD22A88454AC7CF86C464C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 3/24/2011 12:44 PM, Greg Hudson wrote:
> I want to hear from Sam and/or Ken before making a decision, but here's=
> what I can tell from a bit of research:
>=20
> * Weak key checks have been in our code since it appeared in our tree i=
n
> October 2001. The code was committed by Sam but was probably written b=
y
> someone else.=20
The code in MIT Kerberos was written by David Cross <crossd@cs.rpi.edu>.
The implementation for Heimdal which does not contain RC4 weak key
checks was written by Luke Howard.
I can find no evidence that Microsoft Kerberos SSP performs weak key
checks. Perhaps the consortium can obtain an explicit answer from
Microsoft.
> I wasn't able to find any discussion of RC4 weak keys on
> the lists, although I could easily have missed it.
I have found no discussions on either krbdev or the ietf working group
mailing list. The Informational RFC was published as an individual
submission. As far as I can tell there was no comparison of the RFC
submission with the MIT implementation prior to publication. There
certainly was no discussion on the kerberos wg list.
> * The weak key checks are probably based on
> http://impic.org/papers/WeakKeys-report.pdf appendix A.
Sure. The keys match.
> * The attack based on these weak keys reduces the search space by 11
> bytes, and requires about 2^26 messages with known plaintexts to succee=
d
> with 50% probability.
>=20
> * The use of confounders in rc4-hmac appears to foil this attack,
> although I can't say that with high confidence.
>=20
> If the attack is not foiled by confounders, it's pretty bad for
> rc4-hmac-exp (you get a 2^53 work factor to recover a key after scannin=
g
> about 61 million messages with known plaintexts) but isn't very
> interesting for rc4-hmac; 2^117 is still a very high work factor for an=
> attack on a legacy enctype.
My reading of the security considerations section of 4757 is that a new
key is generated for each message transmitted using the gss context in
order to address the key weakness. However, the statements are far from
explicit.
> I agree that simply erroring out on weak keys without any standards
> support for avoiding them is not a great solution, especially when one
> in 2^24 keys is weak.
The way the code exists today RC4-HMAC is not a usable enc-type in
combination with GSS when one side of the connection is MIT.
Recommending that RC4-HMAC not be used is not practical in an AD centric
environment.
Jeffrey Altman
Secure Endpoints, Inc.
--------------enigDCDD22A88454AC7CF86C464C
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.9 (MingW32)
iQEcBAEBAgAGBQJNjOuQAAoJENxm1CNJffh4opMIAN4Sn+W1ZEK/BIcJDdPZPiHc
hlyah8/sea2RUJB9bsoozodzhfADT8IWyVR1iGaNjmXlsjjGNGN/g75KxfQvtfU7
X4xDwSKMWMa+/TPi6aP0qRTljTIJtpf2TjOwXLdQqnn2bnJApCohFiZz1lYFIBPg
f6rta7ZgL6bK1le0bUnr5fWzPnPrIszPcTVbbmSUTd/idCmtvXbkHdDklh5MFPXM
KIQr3tOxzJuI4HiQkMmNzSuFtF86LVv10Qu1MbB0nv1SXa4kU90ohu3wW1fKTtqn
ZBg2MyqSiIrtgDuZAegl15wRREqD6ZpPirAZIhonVZ4H0j3Y2dE3cMoqVCICkVU=
=sVsu
-----END PGP SIGNATURE-----
--------------enigDCDD22A88454AC7CF86C464C--
--===============0410272541==
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
--===============0410272541==--
