As it is now KDC configuration is hard coded and the administrator is responsible for doing any changes to it, and in case of software upgrades to keep up-to-date the list of ciphers allowed, parameters etc. It would be simpler for KDC to follow the system-wide crypto policy [0] by default and unless the administrator changes the configuration the policies will be kept up to date and will be consistent with the policies followed in other parts of the system. The simplest approach for that would be for Kerberos to be able to include a file in its default configuration files, and thus include a file which has been auto-generated. That would also simplify an administrators job by not requiring to review configuration settings as recommended by: https://bettercrypto.org/static/applied-crypto-hardening.pdf [This is a proposal for collaboration, please let me know whether that can be done in our current setup of kerberos and how, and if not the steps that are required to achieve that goal] [0]. http://fedoraproject.org/wiki/Changes/CryptoPolicy
We've discussed this previously. For completeness, here's what I said in that discussion (it's now out of date since we have sha2 ciphers, which are appropriately prioritized): The two additional values I think we want to control are: - master_key_type Currently, this defaults to aes256-cts-hmac-sha1-96 which seems the most reasonable, but it might be nice to put a config handle in for this for futureproofing. - supported_enctypes This controls key/salt settings for realm principals. Unfortunately the default value includes arcfour/md5 and not camellia, so we want a handle for this. Based on what we're setting for permitted_enctypes, I would guess we want this to be: aes256-cts-hmac-sha1-96:normal camellia256-cts-cmac:normal aes128-cts-hmac-sha1-96:normal camellia128-cts-cmac:normal des3-cbc-sha1:normal There's a problem here though. Those are both set in the [realms] section, and the way that section works means that they're set on a per-realm basis. So I don't see a way to control these from crypto-policies right now. This is not the end of the world. master_key_type has a good default. Additionally, while the KDC may generate some keys we don't like as per its supported_enctypes, it won't actually use any of the enctypes not present in permitted_enctypes. (Side note - settings for KDC/kadmin portions of krb5 can be found in both krb5.conf and kdc.conf.) Some significant refactoring would be needed to make default values (i.e., set outside of a specific realm) for these settings work. We may undertake it at some point, but probably not in the near future.
The reason we excluded camellia is that it caused issues in some configurations and it is generally redundant with AES. So I would still keep camellia off by default, then add the sha2 variants of AES on top. We also probably want to drop des3 ? For the realm based section I think we can include the crypto policy file from there ? It will be on admins to keep it right, but all we need is probably to add some comments in the kdc.conf/krb5.conf file to that effect.
(In reply to Simo Sorce from comment #2) > For the realm based section I think we can include the crypto policy file > from there ? > It will be on admins to keep it right, but all we need is probably to add > some comments in the kdc.conf/krb5.conf file to that effect. File/directory includes (i.e., include/includedir) are top-level only in krb5 configuration.
Summary of mailing list discussion: - The impact of hypothetically supporting this in the KDC would be low, since clients already have crypto-policies support for what ciphers they accept. - Due to passwords not being stored on KDCs, we have no way to add new enctypes to a principal. So for an existing installation, there is no *benefit* to adding new enctypes, since they can't be used, and we run the risk of locking some principals out entirely if all their enctypes are removed. - A weaker impact of above: removing supported enctypes can break use in existing keytabs and ccaches. - There is no way to apply crypto-policies to the KDC at the moment due to the way the configuration files are structured. - Adjusting the format is a large undertaking, and upstream is not excited about doing this. I understand that all of this is sub-optimal from the crypto-policies point of view. However, something both we and upstream are keen on is wholesale removal of broken algorithms, starting with single-DES support. Please file a bug if this something you think that should be prioritized.