krb5 crypto modernization
Summary
krb5 will be removing support for DES, RC4, 3DES, crc-32, MD4, and MD5 entirely. They will not be allowed in session keys or long-term keys.
Owner
- Name: Robbie Harwood
- Email: rharwood at fp dot o
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2018-12-20
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
For formal deprecation announcements, there have been two RFCs. First was rfc6649, which deprecated single-DES (and export strength RC4). More recently, there has also been rfc8429 which deprecated the rest of RC4 as well as 3DES. (Note that 3DES was paired with SHA1, RC4 with MD5, and DES with MD4, MD5, or crc32, and that these were the only usages of these digests in krb5's Kerberos implementation.)
Of particular note, single-DES has been known-bad since the mid 90s. It's now so bad that it can be entirely broken in 13 hours for $300: https://crack.sh/kerb5/ But even though other encryption types in this list are less bad, none are what we'd call good - especially since krb5 supports much stronger encryption, such as AES256/SHA2.
Finally, field data suggests that complete removal is preferable to disabling by default. Admins have unfortunately been using allow_weak_crypto (which restored disabled-by-default single-DES functionality to krb5) to this day. A mere config setting doesn't suffice to convey how bad this is, nor does it indicate the appropriate level of urgency of migration. For that reason, and in anticipation that our crypto backends might one day also remove these algorithms, we are going straight to removal as well, rather than repeating allow_weak_crypto or similar.
Benefit to Fedora
Improved crpytography is good for security. Fedora will be leading on this change; no other distributions or OS releases have limited the bad ciphers that Kerberos can use.
Scope
- Proposal owners: rharwood
- Other developers: N/A (not a System Wide Change)
- Release engineering: #8012
- List of deliverables: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
N/A (not a System Wide Change)
How To Test
If you'd like to test either this change or your site's readiness for more modern cryptography, that's great! krb5.conf(5) has several encryption type (enctype) -related settings - of particular note is permitted_enctypes. Set to only removed enctyptes to verify they don't work anymore; set to only modern enctypes to verify that you're ready. (Then just perform your normal tasks with krb5, such as kinit).
C-friendly users might wish to take a look at t_enctypes.c in the krb5 source tree. (How this will be affected depends on how the removal work internally, which I haven't worked out yet.)
User Experience
Ideally no change! Worst case some users will see krb5 produce error messages about bad enctypes not being able to be used (has no enctype, could not fullfill enctype, etc.). These pains are the feeling of the world grinding forward security-wise.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
- Contingency deadline: N/A (not a System Wide Change)
- Blocks release? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)
Release Notes
krb5 removes support for several known-bad encryption types. Hopefully users will see no changes.