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-29
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.

Starting in krb5-1.16.1-25.fc28/krb5-1.16.1-25.fc29/krb5-1.17-3.fc30, deprecation checks exist in three places: in klist output, in KDC logs on ticket issuance, and when loading K/M.

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. All users should be seeing deprecation strings starting in krb5-1.16.1-25.fc28/krb5-1.16.1-25.fc29/krb5-1.17-3.fc30.

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).

If you're an admin, there are more things you can do - issuing a weak K/M, or preparing a site with principals that have weak long-term keys. Inspect klist output and KDC logs (look for the string "DEPRECATED").

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

We started logging deprecations in krb5-1.16.1-25.fc28/krb5-1.16.1-25.fc29/krb5-1.17-3.fc30. Site administrators need to perform all cipher upgrades/rekeying prior to updating. In the event that they do not, they will need to downgrade krb5, perform the updates, and then apply the new version.

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