I'm having trouble with my virtualization at the moment, so unfortunately I can't gather these answers myself.  Things I would look at:

"ipa-getkeytab -s ipa.example.com -k /tmp/test2.keytab -p test2/ipa.example.c" - this is a typo, right?  Should be test2/ipa.example.com

Output of the following:
kadmin.local getprinc admin
kadmin.local getprinc test/ipa.example.com
kadmin.local getprinc test2/ipa.example.com

Is there anything in the KDC logs?

What's the KRB5_TRACE output (of the failing kvno)?

What I'd really like to do at this point is point gdb at the KDC.  However, I don't seem to be able to get IPA to install in FIPS mode (see https://bugzilla.redhat.com/show_bug.cgi?id=1841925 ).

So I'm probably stuck until I can get a machine with IPA installed in FIPS mode to test this, unfortunately.

Per [MS-SFU], PA-FOR-USER uses HMAC-MD5 as the checksum, regardless of key type (page 15).  Of course, we honor this in krb5: https://github.com/frozencemetery/krb5/blob/rhel-8.2.0/src/lib/krb5/krb/s4u_creds.c#L175-L178 which leads to a FIPS error.

Simo, can you comment on whether this should be permitted in FIPS mode?

What's this checksum used for in practice?

I guess it is used to verify that the data in PA-FOR-USER buffer is indeed provided by the KDC because the calculating checksum requires presence of the session key of the TGT of the service requesting S4U2Self. There is another checksum in PA-S4U-X509-USER structure which is must be checked:

--------------------

The client when receiving this padata type in the encrypted-pa-data field MUST verify the checksum values match with the corresponding checksum values in the request and the reply.

--------------------

The difference between PA-FOR-USER and PA-S4U-X509-USER is that the latter has the checksum operation corresponding to the encryption type of the TGT session key. For RC4-HMAC key it is explicitly defined to use RSA-MD5 for checksum. 

If we aren't allowing RC4-HMAC session key, we would have RSA-MD5 not allowed too. But this is PA-S4U-X509-USER, not PA-FOR-USER. For that one there is no explicit 'must' or 'should' statement regarding whether the checksum is validated by the client receiving the response.

Simo, it's used for the TGS exchange to get the s4u2self service ticket.  The client generates the checksum - it's part of packet 15 in the pcap (I'll attach this in a moment).  Kerberos -> tgs_req -> padata -> PA-DATA PA-FOR-USER.  Importantly, the HMAC is over the user the ticket is from (i.e., in a s4u2self request for a service ticket from C->S, this is C - which in the test case here is admin.)

As Alexander points out, the PA-S4U-X509-USER field in that same packet is using a checksum type of 16 (AES).  (Note here that due to 3.1.5.1.1.1 there are some cases where both "should" be sent, as they are in this pcap.  I put quotes around that because I do not know the behavior of various KDCs when they're not present, but suspect it's "must" for interop purposes.)

Created attachment 1695272 [details]
non-fips pcap

(In reply to Alexander Bokovoy from comment #8)
> 
> If we aren't allowing RC4-HMAC session key, we would have RSA-MD5 not
> allowed too. But this is PA-S4U-X509-USER, not PA-FOR-USER. For that one
> there is no explicit 'must' or 'should' statement regarding whether the
> checksum is validated by the client receiving the response.

The PA-FOR-USER is never returned by the KDC, only the PA-S4U-X509-USER is.

This should be fixed upstream with: https://github.com/krb5/krb5/pull/1080

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 (krb5 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-2020:4541