Bug 2068535
| Summary: | Modify supported_enctypes (kdc.conf) and add aes256/128-sha2 enctypes due to FIPS | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Filip Dvorak <fdvorak> | |
| Component: | krb5 | Assignee: | Julien Rische <jrische> | |
| Status: | CLOSED ERRATA | QA Contact: | Filip Dvorak <fdvorak> | |
| Severity: | medium | Docs Contact: | Filip Hanzelka <fhanzelk> | |
| Priority: | low | |||
| Version: | 9.0 | CC: | asosedki, dvozenil, fdvorak, fhanzelk, jrische, mpolovka, myusuf, pasik | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | krb5-1.20.1-4.el9 | Doc Type: | Enhancement | |
| Doc Text: |
.New realm configuration template for KDC enabling FIPS 140-3-compliant key encryption
This update provides a new, `EXAMPLE.COM`, example realm configuration in the `/var/kerberos/krb5kdc/kdc.conf` file. It brings two changes:
* The FIPS 140-3-compliant `AES HMAC SHA-2` family is added to the list of supported types for key encryption.
* The encryption type of the KDC master key is switched from `AES 256 HMAC SHA-1` to `AES 256 HMAC SHA-384`.
WARNING: This update is about standalone MIT realms. Do not change the Kerberos Distribution Center (KDC) configuration in RHEL Identity Management.
Using this configuration template is recommended for new realms. The template does not affect any realm already deployed. If you are planning to upgrade the configuration of your realm according to the template, consider the following points:
For upgrading the master key, changing the setting in the KDC configuration is not enough. Follow the process described in the MIT Kerberos documentation:
https://web.mit.edu/kerberos/krb5-1.20/doc/admin/database.html#updating-the-master-key
Adding the `AES HMAC SHA-2` family to the supported types for key encryption is safe at any point because it does not affect existing entries in the KDC. Keys will be generated only when creating new principals or when renewing credentials. Note that keys of this new type cannot be generated based on existing keys. To make these new encryption types available for a certain principal, its credentials have to be renewed, which means renewing keytabs for service principals too.
The only case where principals should not feature an `AES HMAC SHA-2` key is the Active Directory (AD) cross-realm ticket-granting ticket (TGT) ones. Because AD does not implement RFC8009, it does not use the `AES HMAC SHA-2` encryption types family. Therefore, a cross-realm TGS-REQ using an `AES HMAC SHA-2`-encrypted cross-realm TGT would fail. The best way to keep the MIT Kerberos client from using `AES HMAC SHA-2` against AD is to not provide `AES HMAC SHA-2` keys for the AD cross-realm principals. To do so, ensure that you create the cross-realm TGT entries with an explicit list of key encryption types that are all supported by AD:
----
kadmin.local <<EOF
add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[MIT realm]@[AD realm]
add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[AD realm]@[MIT realm]
EOF
----
To ensure the MIT Kerboros clients use the `AES HMAC SHA-2` encryption types, you must also set these encryption types as `permitted` in both the client and the KDC configuration. On RHEL, this setting is managed by the crypto-policy system. For example, on RHEL 9, hosts using the `DEFAULT` crypto-policy allow `AES HMAC SHA-2` and `AES HMAC SHA-1` encrypted tickets, while hosts using the `FIPS` crypto-policy only accept `AES HMAC SHA-2` ones.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2105975 2114771 (view as bug list) | Environment: | ||
| Last Closed: | 2023-05-09 08:25:24 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 2016312, 2124463 | |||
| Bug Blocks: | 2105975, 2114771 | |||
|
Comment 1
Julien Rische
2022-03-30 16:47:18 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. 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. 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. 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 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. 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. C9S merge request: https://gitlab.com/redhat/centos-stream/rpms/krb5/-/merge_requests/28 Pre-verified manually using RHEL9.2 machine with krb5-server-1.20.1-5.el9.x86_64 1. install krb5-server-1.20.1-5.el9.x86_64 2. enable default EXAMPLE.COM realm in krb5.conf file 3. # kdb5_util create -s -P Secret123 Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M' 4. # kadmin.local Authenticating as principal root/admin with password. kadmin.local: getprinc K/M Principal: K/M Expiration date: [never] Last password change: [never] Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 0 days 00:00:00 Last modified: Wed Feb 08 12:45:55 EST 2023 (db_creation) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 1, aes256-cts-hmac-sha384-192 MKey: vno 1 Attributes: DISALLOW_ALL_TIX REQUIRES_PRE_AUTH LOCKDOWN_KEYS Policy: [none] 5. # kadmin.local -q "ank -pw bob bob" Authenticating as principal root/admin with password. No policy specified for bob; defaulting to no policy Principal "bob" created. 6. # kadmin.local Authenticating as principal root/admin with password. kadmin.local: getprinc bob Principal: bob Expiration date: [never] Last password change: Wed Feb 08 12:49:18 EST 2023 Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 0 days 00:00:00 Last modified: Wed Feb 08 12:49:18 EST 2023 (root/admin) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 7 Key: vno 1, aes256-cts-hmac-sha384-192 Key: vno 1, aes128-cts-hmac-sha256-128 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 Key: vno 1, camellia256-cts-cmac Key: vno 1, camellia128-cts-cmac Key: vno 1, DEPRECATED:arcfour-hmac MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Requested enctypes present, marking as pre-verified: tested. Verified manually using RHEL9.2 machine and krb5-server-1.20.1-5.el9.x86_64 1. dnf install krb5-server Installed: krb5-pkinit-1.20.1-5.el9.x86_64 krb5-server-1.20.1-5.el9.x86_64 libkadm5-1.20.1-5.el9.x86_64 words-3.0-39.el9.noarch 2. # enable default EXAMPLE.COM realm in etc//krb5.conf file 3. kdb5_util create -s -P Secret123 Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M' 4. kadmin.local Authenticating as principal root/admin with password. kadmin.local: getprinc K/M Principal: K/M Expiration date: [never] Last password change: [never] Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 0 days 00:00:00 Last modified: Fri Feb 10 05:17:16 EST 2023 (db_creation) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 1, aes256-cts-hmac-sha384-192 MKey: vno 1 Attributes: DISALLOW_ALL_TIX REQUIRES_PRE_AUTH LOCKDOWN_KEYS Policy: [none] 5. kadmin.local -q "ank -pw bob bob" 6. kadmin.local Authenticating as principal root/admin with password. kadmin.local: getprinc bob Principal: bob Expiration date: [never] Last password change: Fri Feb 10 05:18:20 EST 2023 Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 0 days 00:00:00 Last modified: Fri Feb 10 05:18:20 EST 2023 (root/admin) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 7 Key: vno 1, aes256-cts-hmac-sha384-192 Key: vno 1, aes128-cts-hmac-sha256-128 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 Key: vno 1, camellia256-cts-cmac Key: vno 1, camellia128-cts-cmac Key: vno 1, DEPRECATED:arcfour-hmac MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Requested enctypes present, marking as verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: krb5 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:2570 |