Description of problem:
constrained delegation fails with
Cryptosystem internal error while getting credentials for
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Install ipa-server in FIPS mode.
1: Create the service
ipa service-add test/ipa.example.com --force
ipa service-mod test/ipa.example.com --setattr krbticketflags=2097280
ipa service-add test2/ipa.example.com --force
2: Get keytabs for these services:
ipa-getkeytab -s ipa.example.com -k /tmp/test.keytab -p test/ipa.example.com
ipa-getkeytab -s ipa.example.com -k /tmp/test2.keytab -p test2/ipa.example.c
3: Show that we can't do delegation yet:
kinit -kt /tmp/test.keytab test/ipa.example.com
kvno -k /tmp/test.keytab -U admin -P test/ipa.example.com test2/ipa.example.com
kvno: Cryptosystem internal error while getting credentials for test1/ipa.example.com@EXAMPLE.COM
kvno: KDC returned error string: NOT_ALLOWED_TO_DELEGATE test2/ipa.example.com@EXAMPLE.COM: constrained delegation failed
In non-FIPS mode its passing.
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 184.108.40.206.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]
(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