+++ This bug was initially created as a clone of Bug #2068535 +++

--- Additional comment from Julien Rische on 2022-03-30 16:47:18 UTC ---

I initially thought that generating the KDC supported encryption type list based on permitted encryption types from the crypto-policy would make sense. But looking at the definition of the supported_enctypes parameter:

"Specifies  the  default  key/salt  combinations  of principals for this realm.  Any principals created through kadmin(1) will have keys of these types. The default value for this tag is aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal."

This tends to make me think we should enable as many encryption types as possible, especially the strongest ones. The earlier we enable key generation for these recent encryption types by default, the easier it will be for administrators to eventually permit them on client side, since users and services that created their password/key in the meantime will be able to use these new encryption types at this point.

--- Additional comment from Julien Rische on 2022-04-21 16:27:39 UTC ---

The solution I described in my previous comment is missing a part of the problem: FIPS-enabled hosts are only able to use aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192 encryption types. Hence, even if a non FIPS-compliant encryption type is set as supported_enctypes, but not used for authentication because it is not set as permitted_enctypes, it will still cause the creation of a new key to fail because the crypto-policies will block forbidden algorithms. This results in an internal cryptography error.

As a consequence, in case of a FIPS-enabled host, just adding the latest encryption types is not enough. Non-compliant encryption types have to be removed too.

So the question is: Should we just add newer encryption types and expect FIPS users to update the default KDC configuration accordingly, or have the supported_enctypes setting generated by the update-crypto-policies tool, similarly to /etc/krb5.conf.d/crypto-policies.

--- Additional comment from Julien Rische on 2022-05-03 11:51:34 UTC ---

Alexander, would it be possible to have a crypto-policies configuration file generated for KDC "supported_enctypes" similarly to what we have for "/etc/krb5.conf.d/crypto-policies"? This would avoid to have key creation to fail with the default configuration in a non-IPA KDC setup.

--- Additional comment from Alexander Sosedkin on 2022-05-03 15:04:15 UTC ---

Yes, it is possible to generate additional configuration files.
If reusing the already existing one is somehow impossible or overly impractical,
please file a bug for crypto-policies and describe in details
what the file should contain and how to generate it, how to name it etc.

--- Additional comment from Julien Rische on 2022-05-04 16:37:38 UTC ---

Looking at the kdc.conf manual page[1], I realize that contrary to the "permitted_enctypes" parameter, "supported_enctypes" lies in the realm configuration block. This is an obstacle to having update-crypto-policies generating a specific configuration file for this setting because it would require it to know the name of the realm.

Atop of that, I just did some tests and it is not possible to use "include" or "includedir" instructions in a realm block. Also, in case there are multiple blocks for the same realm, their settings are not combined, only the first one is taken into account. As a result, it is impossible to have one part of the realm configuration in one file, and the rest of the configuration in another file.

With these constraints in mind, I am not sure it is actually possible to have update-crypto-policies generating this file because it would have to contain various other realm parameters that are unrelated to the crypto-policy...

[1] https://web.mit.edu/kerberos/krb5-1.19/doc/admin/conf_files/kdc_conf.html#realms

--- Additional comment from Julien Rische on 2022-07-11 11:12:55 UTC ---

Since the format of the kdc.conf file does not allow to reproduce the behavior of /etc/krb5.conf.d/crypto-policies, we will add aes256-cts-hmac-sha384-192:normal and aes128-cts-hmac-sha256-128:normal to the "supported_enctypes" in the default KDC configuration for the EXAMPLE.COM realm. We will document the fact all the other encryption types should be removed in FIPS mode. Their presence in this mode should cause an internal cryptography error.

--- Additional comment from Julien Rische on 2022-07-12 10:15:14 UTC ---

In the process, we will switch the master_key_type of the EXAMPLE.COM realm parameter from aes256-cts-hmac-sha1-96 (not configured, set by default) by aes256-cts-hmac-sha384-192. This setting is required in FIPS mode, but since the master key does not have any compatibility requirements (contrary to the supported_entypes parameter, which must match the encryption types used by the clients), there is no reason not to use it on new KDC setups.

We will wait for the 1.20 rebase to apply these changes.