RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2068535 - Modify supported_enctypes (kdc.conf) and add aes256/128-sha2 enctypes due to FIPS
Summary: Modify supported_enctypes (kdc.conf) and add aes256/128-sha2 enctypes due to ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: krb5
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Julien Rische
QA Contact: Filip Dvorak
Filip Hanzelka
URL:
Whiteboard:
Depends On: 2016312 2124463
Blocks: 2105975 2114771
TreeView+ depends on / blocked
 
Reported: 2022-03-25 15:44 UTC by Filip Dvorak
Modified: 2023-05-14 13:26 UTC (History)
8 users (show)

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.
Clone Of:
: 2105975 2114771 (view as bug list)
Environment:
Last Closed: 2023-05-09 08:25:24 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/rpms krb5 merge_requests 28 0 None opened Add AES SHA-2 HMAC familly as default KDC enctypes 2022-12-23 13:13:08 UTC
Red Hat Issue Tracker FREEIPA-8085 0 None None None 2022-03-25 15:50:57 UTC
Red Hat Issue Tracker RHELPLAN-116852 0 None None None 2022-03-25 15:51:00 UTC
Red Hat Product Errata RHSA-2023:2570 0 None None None 2023-05-09 08:26:08 UTC

Comment 1 Julien Rische 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.
Comment 2 Julien Rische 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.
Comment 3 Julien Rische 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.
Comment 4 Alexander Sosedkin 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.
Comment 5 Julien Rische 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
Comment 6 Julien Rische 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.
Comment 7 Julien Rische 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.
Comment 11 Julien Rische 2022-12-23 13:13:09 UTC 
C9S merge request:
https://gitlab.com/redhat/centos-stream/rpms/krb5/-/merge_requests/28
Comment 13 Michal Polovka 2023-02-08 17:55:00 UTC 
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.
Comment 16 Michal Polovka 2023-02-10 10:19:26 UTC 
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.
Comment 24 errata-xmlrpc 2023-05-09 08:25:24 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.