New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KRB instance: make provision to work with crypto policy without SHA-1… #6197
Conversation
|
@f-trivino and I tested this patchset on the current internal RHEL 9 compose and in general it works for base installation and use. We are collecting failure cases to classify them and see what we can fix. So far, most of problems are within test infra setup but we also depend on very new versions of OpenSSL 3.0.0 build, crypto-policies, and krb5 fixes which aren't yet merged to CentOS 9 Stream. So this PR will need to be updated when we'll have all proper package requirements available. Some of the tests need additional setup to work in FIPS mode (like AD-related tests). |
|
I think it would be nice to rename I am not sure if it could cause conflicts with older versions though. |
|
Sure, I can do that. Since all of the shorter ones are aliases, they all will be accepted, so There will be no conflicts with old versions because we only generate this file once at the install file and never change it again. The master key itself is in LDAP and these references only used to choose correct cipher to decode the mkey. |
a9a4e06
to
0e4cf9b
Compare
… HMAC types RHEL 9 system-wide crypto policies aim at eventual removal of SHA-1 use. Due to bootstrapping process, force explicitly supported encryption types in kdc.conf or we may end up with AES128-SHA1 and AES256-SHA2 only in FIPS mode at bootstrap time which then fails to initialize kadmin principals requiring use of AES256-SHA2 and AES128-SHA2. Camellia ciphers must be filtered out in FIPS mode, we do that already in the kerberos.ldif. At this point we are not changing the master key encryption type to AES256-SHA2 because upgrading existing deployments is complicated and at the time when a replica configuration is deployed, we don't know what is the encryption type of the master key of the original server as well. Fixes: https://pagure.io/freeipa/issue/9119 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Use AD-SUPPORT subpolicy when testing trust to Active Directory in FIPS mode. This is required in FIPS mode due to AD not supporting Kerberos AES-bases encryption types using FIPS-compliant PBKDF2 and KDF, as defined in RFC 8009. Fixes: https://pagure.io/freeipa/issue/9119 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
0e4cf9b
to
3f410ca
Compare
|
We did a test on RHEL 9 internal CI run and with some arrangement of openssl, crypto-policies, and krb5 versions we've got successful run for trust to Active Directory environment when FIPS mode is relaxed with AES encryption types using SHA-1 HMAC. @f-trivino is going to run a full test suite before giving a final ack here. Since this only affects RHEL 9, we'll add specific version pinning downstream. I will do a follow-up patch for upstream once openssl and crypto-policies updates will be in Fedora (they focus on RHEL 9 / CentOS 9 Stream changes now). |
Fixes: https://pagure.io/freeipa/issue/9119 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Fixes: https://pagure.io/freeipa/issue/9119 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, extensively tested in rhel and works for me.
… HMAC types
RHEL 9 system-wide crypto policies aim at eventual removal of SHA-1 use.
Due to bootstrapping process, force explicitly supported encryption
types in kdc.conf or we may end up with AES128-CTS and AES256-CTS only
in FIPS mode at bootstrap time which then fails to initialize kadmin
principals requiring use of AES256-SHA2 and AES128-SHA2.
Camellia ciphers must be filtered out in FIPS mode, we do that already
in the kerberos.ldif.
Fixes: https://pagure.io/freeipa/issue/9119
Signed-off-by: Alexander Bokovoy abokovoy@redhat.com