jaltman added a new comment to an issue you are following: `` The risk from using weak encryption types for session keys is very different than the risk from use for long-term secrets whether client principals or service principals. Cracking of the long-term secrets is what http://www.openafs.org/pages/security/OPENAFS-SA-2013-003.txt addressed. Weak encryption type long term secrets are at significant risk because they often remain unchanged for months if not years; and might co-exist with stronger encryption type secrets derived from the same password.
Weak session keys on the other hand have a much shorter lifespan and pose a much smaller risk. Not for lack of effort but there are many organizations that still have not purged their Kerberos realms of DES and 3DES keys. Not to mention the many AFS cells that have yet to upgrade all servers to OpenAFS 1.6.6 or later OR AuriStorFS and as a result are not capable of using AES256-CTS-HMAC-SHA1-96 encryption types for long term secrets. OpenAFS does not support AES256-CTS-HMAC-SHA512-384 at all. Even when the long term secrets for service principals have been upgraded to strong encryption types, the application protocols might still require a DES key. OpenAFS 1.6.6 or later and AuriStorFS do support https://tools.ietf.org/id/draft-kaduk-afs3-rxkad-k5-kdf-00.html but there are still many deployed clients in the world that do not. Sites are likely to be reluctant to cut off these older clients just so they can say they are DES free when the AFS rxkad security class is going to derive a 56-bit DES compatible key for use with fcrypt no matter what. It is for this reason that Heimdal Kerberos decided that even if DES was disabled it would still permit the generation of DES encryption types for session keys.
Similar issues are present for many Java Kerberos implementations and for protocols such as telnet and ftp.
Here are some other things to ponder when a KDC is upgraded to a version without DES / 3DES functionality:
1. How will a DES or 3DES long term master key for the KDB be replaced if there is no DES and 3DES?
2. How will client and service principals that only have DES and/or 3DES keys behave?
3. How will an end user whose client principal has only DES and/or 3DES change the password if there is no DES and/or 3DES implementation?
It seems to me that it would be wiser to leave the DES implementation in place but to disable the support for selection of weak keys for long term service principal secrets. Thereby ensuring that if a service principal has the ordered key list DES, 3DES, AES256 that the AES256 key will now be selected in preference to DES or 3DES.
It also seems to me that disabling DES and 3DES long term secrets for client principals that have a stronger encryption type makes sense.
As well as treating any client principal that only has DES and/or 3DES long term secrets as if the password had expired in order to force a password change which would as a result generate a stronger encryption type secret.
Finally, I would leave the session key functionality alone.
This set of changes is much less likely to leave end users in a no-win situation.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8012