Indeed, RHEL-8 crypto-policies doesn't have
https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/eb57e0082b280346e13f08f52a98f97ff07a6ce6
and thus it doesn't respect the policy MAC order.
Instead, the order you observe comes from being hardcoded here:
https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/ae470d6c5ee633d77c3ae9bcebf748fb3dad9507/python/policygenerators/krb5.py#L24

Would it be enough to do the minimally invasive change and just flip the hardcoded order to prefer SHA-2?

yes, I think that would be enough.

By "just flip the hardcoded order to prefer SHA-2", do you mean inside the "AES-256-CBC" and "AES-128-CBC" parameters? So AFAIU, in DEFAULT mode it would result in:

permitted_enctypes = aes256-cts-hmac-sha384-192 aes256-cts-hmac-sha1-96 camellia256-cts-cmac aes128-cts-hmac-sha256-128 aes128-cts-hmac-sha1-96 camellia128-cts-cmac

This won't work, we need both "aes256-cts-hmac-sha384-192" and "aes128-cts-hmac-sha256-128" before all the other encryption types.

> we need both "aes256-cts-hmac-sha384-192" and "aes128-cts-hmac-sha256-128" before all the other encryption types.

That'd be one much, much less trivial request, contradicting many of the established things we currently do.

1. crypto-policies doesn't have a notion of an "order of combinations" or anything like this, just the order of ciphers and order of macs
2. newer (RHEL-9/Fedora) crypto-policies iterates over ciphers in order of preferences first, and then the inner loop is macs.
   even if I flip that over, we'll still have the problem that
3. HMAC-SHA2-256 > HMAC-SHA1 > HMAC-SHA2-384, so SHA-1 still takes precedence

So, to really hoist both "aes256-cts-hmac-sha384-192" and "aes128-cts-hmac-sha256-128" before all the other encryption types, it'll be needed to

1. backport https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/commit/eb57e0082b280346e13f08f52a98f97ff07a6ce6,
   which is a rather invasive change and can only be done in 8 y-stream with loud warnings
2. define the krb5 mac preference order differently from the mac order of all the other back-ends in all the policies we ship
   to deprioritize SHA-1 wrt SHA2-384, which also might require customers to revise their custom policies/subpolicies
3. flip the iteration to be MAC-outer, cipher-inner

and only then the DEFAULT can become something like
permitted_enctypes = aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha384-192 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac camellia128-cts-cmac
and FIPS will be
permitted_enctypes = aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha384-192 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

There will be ripple effects across all other policies of ours: enctype reordering basically everywhere, FUTURE losing SHA-1 enctypes, etc.

Is this what we really want?

We definitely want the FIPS 140-3-compliant encryption types to be prioritized, yes. The later we do this switch, the worse the consequences will be. AES HMAC-SHA1 encryption types will eventually be deprecated because of their use of SHA-1 and especially the suspected weakness of their key derivation function.

This switch does not enable new encryption types in itself. The encryption types available for a certain principal are controlled by the administrator in case of a "vanilla" MIT krb5 realm (using the "supported_enctypes" parameter in kdc.conf, which is not controlled by the crypto-policy), and in FreeIPA's case, the "supported" encryption types are inherited from the crypto-policy (but ordering does not matter for this purpose).

For "vanilla" MIT realms, the template KDC configuration we provide does not yet enable generation on of AES HMAC-SHA2 keys by default[1] on CentOS Stream/RHEL 8. So in the majority of cases, prioritizing AES HMAC-SHA2 in the crypto-policy will have no effect. But some administrators may have enabled it already. For the ones who did so, here are the two unwanted consequences I can think of:

  * Services which are configured with multiple key types, including the RFC8009 ones, in the KDB, but does not include the AES HMAC-SHA2-enctyped keys in their keytab, would no longer be able to verify the tickets sent to them by clients. This is very unlikely to happen in FreeIPA realms though, because ipa-getkeytab exports all the available keys types.
  * A "vanilla" MIT krb5 realm having a trust with Active Directory with some of its cross-realm keys using RFC8009 encryption types would fail to complete any cross-realm ticket request after this change. This is because the MIT KDC would send an AES HMAC-SHA2 cross-realm TGT that AD won't be able to decrypt. But this can be easily fixed, just by removing the AES HMAC-SHA2 cross-realm keys. This issue is already documented for RHEL9[2] and is managed automatically by FreeIPA.

System administrators are usually well aware of these things, because they already went through the deprecation of 3DES and RC4 in the past.

[1] https://gitlab.com/redhat/centos-stream/rpms/krb5/-/blob/c8s/kdc.conf#L12
[2] "New realm configuration template for KDC enabling FIPS 140-3-compliant key encryption"
    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.2_release_notes/index#known-issues-identity-management

Thank you for providing some very in-depth context.

I'm gonna interpret that as a
"yes, do whatever it takes to
 * reorder both aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192
   to the top of the permitted_enctypes list, in that particular order,
 * in RHEL-8.9+ and RHEL-9.3+,
 * even if that means explicitly introducing out a separate macs ordering for krb5 in all the policies
   that doesn't matches the macs ordering used for the other crypto-policies back-ends, and
 * even if that means RHEL-8 krb5 will suddenly start respecting macs option, which they previously haven't"
unless somebody objects to that interpretation. =)

Well, I would treat this as a bug in crypto-policies that prevents FIPS mode networking interoperability between RHEL 8 and RHEL 9.

The order for HMAC-SHA2 types should be 'aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128', this is the default order since krb5 1.15:
https://github.com/krb5/krb5/commit/d1ec317288278d10ae34fde9b2414e4fca5c52dd

Implementation-wise, I'd leave it to you. ;)

Julien or somebody else from the Kerberos side, could you, please, review the attached pull-request and doc text?

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 (crypto-policies 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/RHBA-2023:7170