Although not sure if it's the right place to discuss contents of the wiki page, can you please drop the following sentence?

" It's now so bad that it can be entirely broken in 13 hours for $300: <link>"

We shouldn't advertise any commercial service (here especially from 3rd party) to crack others' belongings.

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.

Although not sure if it's the right place to discuss contents of the wiki page, can you please drop the following sentence?
" It's now so bad that it can be entirely broken in 13 hours for $300: <link>"
We shouldn't advertise any commercial service (here especially from 3rd party) to crack others' belongings.

While I appreciate the notion that a commercial service should not be advertised I believe that it is important that reviewers understand the ease by which DES keys can be brute forced. This is especially true since the estimated time to brute force a Kerberos v5 service ticket encryption key was approximately 24 hours just five years ago.

What I would like to see is a reference to where the 13 hours and $300 numbers came from.

Hmm, I don't want to advertise (no affiliation with them, obviously) but I also do want a citation - do you have a language suggestion? I could also add a note like "citation withheld so as not to advertise; ask rharwood if you need it"

@jaltman, the exact numbers come from their price page

RelEng doesn't need to do any work for this change, but I will leave the ticket open for the ongoing discussion.

Thanks for filing the ticket.

Releng work is complete. Closing as fixed.