[19855] in Kerberos_V5_Development
Re: After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos
daemon@ATHENA.MIT.EDU (Robbie Harwood)
Mon Nov 5 13:01:33 2018
From: Robbie Harwood <rharwood@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Derek Atkins <derek@ihtfp.com>
In-Reply-To: <20181105160412.GJ54966@kduck.kaduk.org>
Date: Mon, 05 Nov 2018 13:01:12 -0500
Message-ID: <jlg36sfcsk7.fsf@redhat.com>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: multipart/mixed; boundary="===============1197813497968892283=="
Errors-To: krbdev-bounces@mit.edu
--===============1197813497968892283==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha512; protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Benjamin Kaduk <kaduk@mit.edu> writes:
> On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:
>> Greg Hudson <ghudson@mit.edu> writes:
>>> On 11/01/2018 10:30 AM, Weijun Wang wrote:
>>>
>>>> Now that RFC 8429 is published and 3DES and RC4 are deprecated, is
>>>> there any plan to remove them from etype list of KDC-REQ?
>>>
>>> For RC4, I would like Microsoft to take the lead. 3DES is our
>>> responsibility, and is probably not in nearly as much use (although
>>> I'd have to at least check if we're still using it internally at
>>> MIT), so it is probably not as painful to deprecate.
>>>
>>> There is some ambiguity in how weak an enctype needs to be to
>>> qualify for being affected by allow_weak_crypto. The primary
>>> concerns about des3-cbc-sha1 are its 64-bit block size and the fast
>>> speed of its string-to-key operation; both of these are far less
>>> problematic than the practical ability to recover a random
>>> single-DES key. It would also be a shame if administrators wound up
>>> enabling DES in order to make DES3 work (or RC4).
>>=20
>> Maybe we need an "allow_very_weak_crypto" in addition to the
>> "allow_weak_crypto"?
>
> Perhaps ... though what is keeping us from biting the bullet and just
> not exposing single-DES at all (forcing sites that need it to stay on
> an old software branch)?
I've started some of this work, but haven't looked at it in a while.
Among other things, srvtab and krb4 support need to go. I don't think
there should be any attachment to any of its dependencies of course,
just that it is more to do.
I would be very happy to see the single-DES code removed.
Thanks,
=2D-Robbie
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlvghWgACgkQJTL5F2qV
pELuxQ//aprLOHn+mOUzgTx16bmiyXmpWvowqRxpNkO0vlJT27SF+WPhTMLAjY9i
rDCkMH+xd6SM45elINmDQNNMziS1KYd7VMZL+f577aRWG8lrHhtBvxaeFeUQNPOe
9Vb46HWV+6RnKeCGEjrGNsaPM6D2onUDqkbGMKEtATsFnZNdRdsG1cHzIMO+fDtQ
/Outn3u6iV7aRjx68GSQok2w5vdJ+7/CaW2jLpDEX3L7g9kJW/zlMQFcshFJ2fmS
pzCgxhbsjLceFDvhJUnox7qWnhTFWnQaQiI1fiXTfyY8fZTq9ctAXN1bFXrcWS5I
t7lsGcm6pFwGIzR4Ql1KBwUgFDCUypL5T6vuczpEuq/93qxwaVWuy2eL8QwgtI/l
AOmX2cDmd2g0pzXAe8Kfud3HP6yjSOwyEHc/mJLMAmOluDVQG7BGtobj4PQQ3B86
FZCy3Tbf1681tZxtcXd5cyzDqbGDjFtMitl9Anp9jdqCz8c4g0N4aYuhyxq4txqm
kngUPsVCRhpaunP498Ylee79NFHNZYPoXnMri9T+90/qOHzmHn1/XN2aQnNUmfHn
D2MPF9A/vw0vuP/4I0j0Oipfj/DF1XcBFlFFlgPdUMpQsFtTbVg0cqx4uSaJ4Q87
VJdoMcePS4DuoBZS8rR2HUsVoMObDWhz1sOGZJNerZsxKv488OI=
=GBaa
-----END PGP SIGNATURE-----
--=-=-=--
--===============1197813497968892283==
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
--===============1197813497968892283==--
