From Fedora Project Wiki
(Ready for wrangler)
m (Delaying to Fedora 31)
(14 intermediate revisions by 2 users not shown)
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 20: Line 20:
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/30 | Fedora 30 ]]  
+
* Targeted release: [[Releases/31 | Fedora 31 ]]  
 
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 30: Line 30:
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 
-->
 
-->
* Tracker bug: <will be assigned by the Wrangler>
+
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1670398 #1670398]
 +
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/291 #291]
  
 
== 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.)
Line 39: Line 42:
  
 
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 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.
  
 
<!-- 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. -->
Line 69: Line 76:
  
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  
+
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 [https://web.mit.edu/kerberos/krb5-1.16/doc/admin/advanced/retiring-des.html 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 ==
 
== 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'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.)
 
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.)
Line 79: Line 90:
 
== User Experience ==
 
== 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.
+
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 ==
 
== Dependencies ==
Line 94: Line 105:
 
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+
* Blocks release? N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
  
Line 105: Line 116:
 
== Release Notes ==
 
== Release Notes ==
  
krb5 removes support for several known-bad encryption types.  Hopefully users will see no changes.
+
krb5 removes support for several known-bad encryption types.  Hopefully users will see no changes, but to be sure you won't, we started logging deprecation warnings in krb5-1.16.1-25.fc28/krb5-1.16.1-25.fc29/krb5-1.17-3.fc30.  For more information on upgrading from deprecated enctypes, see [https://web.mit.edu/kerberos/krb5-1.17/doc/admin/advanced/retiring-des.html MIT's DES deprecation guide].
  
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
 
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
Line 113: Line 124:
 
-->
 
-->
  
[[Category:ChangeReadyForWrangler]]
+
[[Category:ChangeAcceptedF30]]
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- When your change proposal page is completed and ready for review and announcement -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
 
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Revision as of 16:40, 8 March 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

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

N/A (not a System Wide Change)

Release Notes

krb5 removes support for several known-bad encryption types. Hopefully users will see no changes, but to be sure you won't, we started logging deprecation warnings in krb5-1.16.1-25.fc28/krb5-1.16.1-25.fc29/krb5-1.17-3.fc30. For more information on upgrading from deprecated enctypes, see MIT's DES deprecation guide.