Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 2057471

Summary: Consequences of FIPS crypto policy tightening in RHEL 9
Product: Red Hat Enterprise Linux 9 Reporter: Alexander Bokovoy <abokovoy>
Component: ipaAssignee: Florence Blanc-Renaud <frenaud>
Status: CLOSED ERRATA QA Contact: Sumedh Sidhaye <ssidhaye>
Severity: unspecified Docs Contact: Jan Fiala <jafiala>
Priority: unspecified    
Version: 9.0CC: alee, asosedki, fdvorak, frenaud, gfialova, jafiala, jrische, jvilicic, myusuf, pasik, pvlasin, rcritten, ssidhaye, tscherf
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-4.9.8-7.el9_0 Doc Type: Known Issue
Doc Text:
.FIPS support for AD trust requires the AD-SUPPORT crypto subpolicy Active Directory (AD) uses AES SHA-1 HMAC encryption types, which are not allowed in FIPS mode on RHEL 9 by default. If you want to use RHEL 9 IdM hosts with an AD trust, enable support for AES SHA-1 HMAC encryption types before installing IdM software. Since FIPS compliance is a process that involves both technical and organizational agreements, consult your FIPS auditor before enabling the `AD-SUPPORT` subpolicy to allow technical measures to support AES SHA-1 HMAC encryption types, and then install RHEL IdM: [literal] ---- # update-crypto-policies --set FIPS:AD-SUPPORT ----
 Story Points: ---
Clone Of:
: 2067971 (view as bug list) Environment:
Last Closed: 2022-05-17 12:44:26 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: 2039684, 2053135, 2060798, 2064823, 2066316, 2066319, 2067121    
Bug Blocks: 2067971, 2124308, 2124310    
Attachments:
Description Flags
ipaserver-install.log from successful installation in FIPS mode none

Description Alexander Bokovoy 2022-02-23 12:57:28 UTC 
RHEL IdM servers can be configured in FIPS mode. If there is already an IdM deployment in FIPS mode and a new server is being added, it must also be deployed in FIPS mode. FIPS mode in RHEL 8 allows AES SHA-1 HMAC encryption types while in RHEL 9 it would not allow by default. However, RHEL 8 FIPS mode deployment would also provide AES SHA-2 HMAC encryption types support so there is overlapping encryption types for interoperability purposes.

When trust to Active Directory is established from RHEL IdM deployed in FIPS mode on RHEL 8, AES SHA-1 HMAC encryption types would be enabled on the RHEL 8 systems. Adding IdM server as a replica on RHEL 9 in FIPS mode would work but such servers will not be interoperable with Active Directory unless FIPS mode requirements were relaxed before deployment with AD-SUPPORT crypto subpolicy.

If RHEL IdM server was deployed in FIPS mode on RHEL 9 initially and later extended to support trust to Active Directory, existing keys for all IdM Kerberos services would not be compatible with encryption types supported by Active Directory and thus those keys will need to be regenerated. There is no ready-made mechanism to safely re-generate keys without causing outage to existing clients. 

Several additional steps would need to be done:

- RHEL system crypto policy would need to be extended with AD-SUPPORT crypto subpolicy
- keys for existing Kerberos principals need to be renewed with the help of ipa-getkeytab utility
- cross-realm TGT keys need to be renewed
- [more work?]
Comment 1 Alexander Bokovoy 2022-02-24 11:03:51 UTC 
Current findings when attempting to deploy IPA on RHEL 9 in FIPS mode with a test build of krb5:

- master key is defaulting to aes256-cts-hmac-sha1-96, needs to be updated to use aes256-cts-hmac-sha384-192 in install/share/kdc.conf.template
- install/share/kerberos.ldif needs to be extended to add 

krbDefaultEncSaltTypes: aes256-sha2:special
krbDefaultEncSaltTypes: aes128-sha2:special

- even if supported_enctypes is extended to include SHA2-HMAC-based encryption types, somehow those ignored and SHA-1-HMAC based enctypes used:

[root@master ~]# kadmin.local -x ipa-setup-override-restrictions
Authenticating as principal root/admin with password.
kadmin.local:  ank -randkey -e aes256-cts-hmac-sha1-96:normal,aes256-cts-hmac-sha1-96:special,aes128-cts-hmac-sha1-96:normal,aes128-cts-hmac-sha1-96:special,aes256-cts-hmac-sha384-192:normal,aes256-cts-hmac-sha384-192:special,aes128-cts-hmac-sha256-128:normal,aes128-cts-hmac-sha256-128:special foobar
No policy specified for foobar; defaulting to no policy
Principal "foobar" created.
kadmin.local:  getprinc foobar
Principal: foobar
Expiration date: [never]
Last password change: Thu Feb 24 05:25:08 EST 2022
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Feb 24 05:25:08 EST 2022 (root/admin)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
Key: vno 1, aes256-cts-hmac-sha384-192
Key: vno 1, aes128-cts-hmac-sha256-128
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
kadmin.local:  delprinc foobar
Are you sure you want to delete the principal "foobar"? (yes/no): yes
Principal "foobar" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
kadmin.local:  ank -randkey foobar
No policy specified for foobar; defaulting to no policy
Principal "foobar" created.
kadmin.local:  getprinc foobar
Principal: foobar
Expiration date: [never]
Last password change: Thu Feb 24 05:25:39 EST 2022
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Feb 24 05:25:39 EST 2022 (root/admin)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

If both kdc.conf.template and kerberos.ldif updated, creating KDC instance succeeds. However, later we fail when requesting RA certificate from CA because OpenSSL 3.0.0 FIPS crypto provider has no support for PKCS12KDF: https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-FIPS.html

  [error] CalledProcessError: CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmp8hnp8pj0', '-passin', 'file:/tmp/tmpo9mamzb8'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n')
CalledProcessError(Command ['/usr/bin/openssl', 'pkcs12', '-nokeys', '-clcerts', '-in', '/root/ca-agent.p12', '-out', '/var/lib/ipa/tmp8hnp8pj0', '-passin', 'file:/tmp/tmpo9mamzb8'] returned non-zero exit status 1: 'Error verifying PKCS12 MAC; no PKCS12KDF support.\nUse -nomacver if MAC verification is not required.\n')
Comment 2 Alexander Bokovoy 2022-02-24 11:40:09 UTC 
Created attachment 1863149 [details]
ipaserver-install.log from successful installation in FIPS mode

With openssl 3.0.1-11.el9 I was able to get past RA certificate issuance step and produced working server.

Log of installation attached.

Additional change I had to do to make it working in install/share/kdc.conf.template:

  master_key_type = aes256-sha2
  supported_enctypes = aes256-cts-hmac-sha1-96:normal aes256-cts-hmac-sha1-96:special aes128-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:special aes256-cts-hmac-sha384-192:normal aes256-cts-hmac-sha384-192:special aes128-cts-hmac-sha256-128:normal aes128-cts-hmac-sha256-128:special

This results in using aes256-cts-hmac-sha384 as a master key and issuing keys for all the supported enctypes. This makes it possible to interoperate with RHEL 8 and Active Directory:

[root@master ~]# kadmin.local 
Authenticating as principal admin/admin with password.
kadmin.local:  getprinc krbtgt/IPA.TEST
Principal: krbtgt/IPA.TEST
Expiration date: [never]
Last password change: [never]
Password expiration date: [never]
Maximum ticket life: 7 days 00:00:00
Maximum renewable life: 14 days 00:00:00
Last modified: Thu Feb 24 06:19:52 EST 2022 (db_creation)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 4
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
Key: vno 1, aes256-cts-hmac-sha384-192
Key: vno 1, aes128-cts-hmac-sha256-128
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH LOCKDOWN_KEYS
Policy: [none]

However, since SHA-1 HMAC-based encryption types aren't enabled by default, they'll be unusable in FIPS mode:

[root@master ~]# ipa-getkeytab --permitted-enctypes
Supported encryption types:
AES-256 CTS mode with 192-bit SHA-384 HMAC
AES-128 CTS mode with 128-bit SHA-256 HMAC
Comment 8 Florence Blanc-Renaud 2022-03-08 11:56:38 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/d38dd2680fb828da4b36e8eb4ce8dc8b056491ce
https://pagure.io/freeipa/c/2eee5931d714ca237290be7dc2fb7233ce747eca
https://pagure.io/freeipa/c/985dffe147501e1b9cba3ab0be378115a23c3564
https://pagure.io/freeipa/c/7d25eead994715b98f5dea5679c8fee0db4c4494
Comment 9 Florence Blanc-Renaud 2022-03-08 16:17:19 UTC 
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/a51900819bd5332bc05ec9d513f062844b3a7763
https://pagure.io/freeipa/c/b016683552a58f9cc2a05cf628cc467234eaf599
https://pagure.io/freeipa/c/49d9147e38c5b50c52a1ebc7283753c779c2f81f
https://pagure.io/freeipa/c/ee39de46a1c1ea96bbe524f159ae435319b2d072
Comment 10 Florence Blanc-Renaud 2022-03-09 13:15:23 UTC 
Moving to POST as the fix is available upstream
Comment 11 Florence Blanc-Renaud 2022-03-14 12:49:51 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/9119
Comment 14 Alexander Bokovoy 2022-03-16 09:15:43 UTC 
Additional fixes.

Fixed upstream
master:
https://pagure.io/freeipa/c/a6030f5f53e077a0443605fba23ef104c797f168
https://pagure.io/freeipa/c/621af275c3564f1d5f1a97c46290b5d166fe8c8a
https://pagure.io/freeipa/c/517ae594e1ad80598a154f1dcacf7b303f420fc8
Comment 15 Alexander Bokovoy 2022-03-16 10:12:12 UTC 
Additional fixes for use of AES in KRA operations

Fixed upstream
master:
https://pagure.io/freeipa/c/40c362e1eeb000867d0e6244ce03b66b6a35e913
https://pagure.io/freeipa/c/b8f45fc68901ae77f250887037b78686c67024b9
=== Tickets fixed ===
https://pagure.io/freeipa/issue/6524
Comment 16 Alexander Bokovoy 2022-03-16 14:23:22 UTC 
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/3e54c4362490b4da1b6cb3e141bb6e08fecc58c0
https://pagure.io/freeipa/c/3baae8d1bd0a0c4c707314524289e86e6ecbc0df
https://pagure.io/freeipa/c/2e70535f74e7d9dd76e728eca1119ce522fd138a
=== Tickets fixed ===
https://pagure.io/freeipa/issue/9119
Comment 17 Alexander Bokovoy 2022-03-16 14:25:10 UTC 
Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/895e99b6843c2fa2274acab824607c33c1a560a4
https://pagure.io/freeipa/c/984190eea01ac42cd1f97567a67dd9446e5b0bf9
=== Tickets fixed ===
https://pagure.io/freeipa/issue/6524
Comment 22 Florence Blanc-Renaud 2022-03-25 09:25:15 UTC 
An additional test fix is required:
master:
https://pagure.io/freeipa/c/5a42ab115e85698866219e3edc98ceaf439bab55
Comment 23 Florence Blanc-Renaud 2022-03-25 13:36:04 UTC 
Additional test fix:
ipa-4-9:
https://pagure.io/freeipa/c/09481117b58f1a237bb1048d3fe8d44caf9e167f
Comment 24 Mohammad Rizwan 2022-03-25 13:50:42 UTC 
version:
ipa-server-4.9.8-7.el9_0.x86_64
krb5-server-1.19.1-15.el9_0.x86_64
openssl-3.0.1-20.el9_0.x86_64

Automated tests in FIPS mode look promising. Based on the results marking the bug verified.
Comment 26 Florence Blanc-Renaud 2022-03-29 06:14:40 UTC 
Additional test fix:
master:
    27ab216 ipatests: fix check for AD topology being present

ipa-4-9:
    b6b5f60 ipatests: fix check for AD topology being present
Comment 29 errata-xmlrpc 2022-05-17 12:44:26 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 (new packages: ipa), 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/RHBA-2022:2387