How to reliably avoid obsolete crypto?

[riastradh]

I understand there are existing Kerberos realms that have compatibility requirements which can't just be broken.

However, suppose I am:

1. a user joining a new Kerberos realm for client-side SSO with a modern KDC, or
2. an operator setting up a new Kerberos service in an existing Kerberos realm with no compatibility requirements, or
3. an admin creating a new Kerberos realm with no compatibility requirements, or
4. someone in charge trying to root out obsolete crypto in an existing deployment and either remove it or at least identify its uses.

What can I do to guarantee users and services will not be vulnerable to obsolete crypto such as RC4, or find which ones are? If anything tries to use that, I want to guarantee it fails noisily before exposing, e.g., breakable ciphertexts on the network to an adversary.

I know I can review the literature to find the state of the art, and I can specify options like kinit -e aes256-cts-hmac-sha1-96, or ktutil add -e aes256-cts-hmac-sha1-96, &c., but that requires me to keep track of the state of the art and update individual command lines with individual cryptosystem choices, which is a nonstarter. Let's suppose that the Heimdal maintainers have agreed to classify some cryptosystems as 'bad' and some as 'good' (and separately argue which ones are which) -- in some way other than throwing in the towel and creating a totally incompatible krb6.

1. Can I put something in my client-side krb5.conf to make Heimdal noisily fail any time a KDC or service tries to use obsolete crypto?
2. Can I put something in my service's krb5.conf, or GSSAPI calls, or libkrb5 API calls, or ktadmin/ktutil setup, to treat authentication attempts with obsolete crypto as failed authentication? Or, is there an easy way to audit keytabs for entries that are vulnerable to obsolete crypto, and to remove those entries?
3. Can I put something in my KDC's krb5.conf or database to avoid even creating keys in the KDC or keytabs for obsolete crypto?

[nicowilliams]

permitted_enctypes in the configuration of the clients, servers, and KDCs, is enough to prevent the use of enctypes you do not wish to see used. It is not enough to prevent long-term keys of other enctypes being set on principals when you change their keys/passwords, but it is enough to prevent their use.

The allow_weak_crypto configuration parameter should default to no, but it only covers especially weak enctypes, not ones that should be weak but which forbidding would result in poor interoperability.