From Fedora Project Wiki
(Ready for wrangler)
(mark rc4 as not going away)
Line 5: Line 5:
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
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.
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 ==
== Owner ==
Line 39: Line 39:


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.
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 `allow_weak_crypto`.


<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->

Revision as of 16:20, 21 December 2018

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

Current status

  • Targeted release: Fedora 30
  • Last updated: 2018-12-21
  • 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.

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


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