On Fri, 2018-12-21 at 15:35 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization > > 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 > > == Detailed Description == > > 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.) > > 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/ 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) > * Release engineering: [https://pagure.io/releng/issue/8012 #8012] > * 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. > > == 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.) Hi, How does this ties with crypto policies? libkrb5 is already under crypto policies and has these ciphers disabled by default. Is this change about removing them from the code or removing them from the capabilities of the KDC which is not covered by crypto policies? > == 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. I guess there will be different experience in client side where these are already disabled by default in fedora, and in server side which they are not. regards, Nikos _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
