After RFC 8429: Deprecate Triple-DES (3DES) and RC4 in Kerberos
rharwood at redhat.com
Mon Nov 5 13:01:12 EST 2018
Benjamin Kaduk <kaduk at mit.edu> writes:
> On Mon, Nov 05, 2018 at 10:57:50AM -0500, Derek Atkins wrote:
>> Greg Hudson <ghudson at 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).
>> Maybe we need an "allow_very_weak_crypto" in addition to the
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20181105/78cf2377/attachment.bin
More information about the krbdev