[16770] in Kerberos_V5_Development
Re: RC4 Weak Key checks
daemon@ATHENA.MIT.EDU (Markus Sander)
Mon Apr 18 11:18:03 2011
Message-ID: <4DAC5621.7070003@gmx.de>
Date: Mon, 18 Apr 2011 17:17:53 +0200
From: Markus Sander <msander@gmx.de>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <4D8B5641.3020103@secure-endpoints.com>
Content-Type: multipart/mixed; boundary="===============1688848880=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1688848880==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigEE4A7BB972ABA6E103C287FF"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEE4A7BB972ABA6E103C287FF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Am 24.03.2011 15:33, schrieb Jeffrey Altman:
> In k5_arcfour_init() src/lib/crypto/enc_provider/rc4.c MIT's
> implementation of RC4 has a check for two families of weak keys.
> Those beginning with either of the following three octet sequences:
>=20
> arcfour_weakkey1[] =3D {0x00, 0x00, 0xfd};
> arcfour_weakkey2[] =3D {0x03, 0xfd, 0xfc};
>=20
> If a key in either of these families is detected in k5_arcfour_init(),
> the error KRB5DES_WEAK_KEY is returned to the caller.
>=20
> In my reading of RFC 3961 and RFC 4757 I do not come across any
> indication that a weak key test should be applied when RC4 is used with=
> Kerberos or GSS. When used with GSS the weak key test is especially
> problematic. For example, each call to gss_wrap() generates a new per
> message RC4 key as each message is treated by RFC 4757 as a new RC4
> keystream. The RC4 key is generated using the sequence number as input=
> using the following call sequence:
>=20
> gss_wrap -> gss_seal -> k5glue_seal -> krb5_gss_seal -> kg_seal ->
> make_seal_token_v1 -> kg_make_seq_num -> kg_arcfour_docrypt ->
> k5_arcfour_docrypt -> k5_arcfour_init
>=20
> An application calling gss_wrap() experiences a random behavior. When =
a
> KRB5DES_WEAK_KEY error is returned from k5_arcfour_init(), it is never
> handled and the gss_wrap() call fails. This can happen relatively
> quickly or can require hundreds of thousands of messages. Regardless,
> if the GSS context is used to send enough messages, the error will be
> thrown.
>=20
> In examining other implementations of RC4 I can find no weak key check.=
> I am questioning whether MIT's implementation should have one and if s=
o
> whether it should be used in conjunction with GSS.
>=20
> If the weak key check is maintained, it implies that in any given GSS
> context certain sequence numbers cannot be used. Since there is no
> standard for how these sequence numbers should be skipped, the inclusio=
n
> of the weak key check is an interoperability problem with existing
> deployed GSS implementations.
>=20
> I would appreciate the feedback of the members of this list.
I was bitten by this. I detailed the problem as we/our customer
experienced it on the OpenLDAP mailing list. The post is available from
http://www.openldap.org/lists/openldap-technical/201103/msg00231.html
Removing the weak key check made the problem go away.
--------------enigEE4A7BB972ABA6E103C287FF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2sViIACgkQwnQbKGDWVvqCzACg1SDu46hkgaYNimrNtedPxLgO
8AMAoNomx0TMFd1sVAJRO5YkYCV2icKT
=YRLW
-----END PGP SIGNATURE-----
--------------enigEE4A7BB972ABA6E103C287FF--
--===============1688848880==
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
--===============1688848880==--
