(Separate weak RC4 option from weak single-DES option) |
(Restate what we're going to do in the Detailed Descriotion.) |
||
| Line 33: | Line 33: | ||
== Detailed Description == | == Detailed Description == | ||
We are going to entirely remove all uses of these algorithms from krb5. This includes session keys, long-term keys, and K/M. | |||
For formal deprecation announcements, there have been two RFCs. First was [https://tools.ietf.org/html/rfc6649 rfc6649], which deprecated single-DES (and export strength RC4). More recently, there has also been [https://tools.ietf.org/html/rfc8429 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.) | For formal deprecation announcements, there have been two RFCs. First was [https://tools.ietf.org/html/rfc6649 rfc6649], which deprecated single-DES (and export strength RC4). More recently, there has also been [https://tools.ietf.org/html/rfc8429 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.) | ||
Revision as of 20:46, 8 January 2019
krb5 crypto modernization
Summary
krb5 will be removing support for DES, 3DES, crc-32, and MD4 entirely; they will not be allowed in session keys or long-term keys. Additionally, RC4 and MD5 will be marked deprecated and dangerous.
Owner
- Name: Robbie Harwood
- Email: rharwood at fp dot o
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2019-01-08
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
We are going to entirely remove all uses of these algorithms from krb5. This includes session keys, long-term keys, and K/M.
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.
Unfortunately, it's not possible for RC4 to be removed entirely at this time because it is still in demand for Active Directory integration (which also affects freeIPA and samba). For this reason, it's moved to a config option - probably allow_weak_rc4.
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
Users of RC4 who need to continue doing so will need to add allow_weak_crypto = True to /etc/krb5.conf.
Users who have weak long-term keys (keytabs, password derived keys, and K/M) without stronger versions also present will need to upgrade them. More information on this process can be found at MIT's DES retirement docs. rharwood will investigate providing a script to detect what changes administrators will need to make where possible.
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)
- 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.