m (Change announced) |
m (clarify md4 state) |
||
(12 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, 3DES, crc-32 | krb5 will be removing support for DES, 3DES, and crc-32 entirely; they will not be allowed in session keys or long-term keys. Additionally, RC4, MD4, and MD5 will be marked deprecated and dangerous. | ||
== Owner == | == Owner == | ||
Line 20: | Line 20: | ||
== Current status == | == Current status == | ||
* Targeted release: [[Releases/ | * 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: | * 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 40: | Line 43: | ||
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 ` | 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 71: | Line 76: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Users of RC4 who need to continue doing so will need to add `allow_weak_crypto = | Users of RC4 who need to continue doing so will need to add `allow_weak_crypto = rc4` 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 81: | Line 90: | ||
== User Experience == | == 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 == | == Dependencies == | ||
Line 107: | 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 115: | Line 124: | ||
--> | --> | ||
[[Category: | [[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 --> |
Latest revision as of 21:30, 17 September 2019
krb5 crypto modernization
Summary
krb5 will be removing support for DES, 3DES, and crc-32 entirely; they will not be allowed in session keys or long-term keys. Additionally, RC4, MD4, 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 31
- Last updated: 2019-09-17
- Tracker bug: #1670398
- Release notes tracker: #291
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 = rc4
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.