|Summary:||In FIPS mode constrained delegation fails with Cryptosystem internal error|
|Product:||Red Hat Enterprise Linux 8||Reporter:||anuja <amore>|
|Component:||krb5||Assignee:||Robbie Harwood <rharwood>|
|Status:||VERIFIED ---||QA Contact:||ipa-qe <ipa-qe>|
|Version:||8.3||CC:||abokovoy, cheimes, dpal, fdvorak, iboukris, ksiddiqu, pvoborni, rcritten, rharwood, ssorce, tscherf|
|Fixed In Version:||krb5-1.18.2-4.el8||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description anuja 2020-05-21 13:17:04 UTC
Description of problem: constrained delegation fails with Cryptosystem internal error while getting credentials for Version-Release number of selected component (if applicable): ipa-server release: 1.module+el8.3.0+6429+acaee14b version: 4.8.6 How reproducible: Always 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: kdestroy -A 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 Actual results: kvno: Cryptosystem internal error while getting credentials for test1/ipa.example.com@EXAMPLE.COM Expected results: kvno: KDC returned error string: NOT_ALLOWED_TO_DELEGATE test2/ipa.example.com@EXAMPLE.COM: constrained delegation failed Additional info: In non-FIPS mode its passing.
Comment 2 Robbie Harwood 2020-05-22 00:27:40 UTC
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)?
Comment 5 Robbie Harwood 2020-05-29 20:25:10 UTC
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.
Comment 6 Robbie Harwood 2020-06-03 21:38:14 UTC
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?
Comment 7 Simo Sorce 2020-06-03 22:21:48 UTC
What's this checksum used for in practice?
Comment 8 Alexander Bokovoy 2020-06-04 06:47:26 UTC
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.
Comment 9 Robbie Harwood 2020-06-04 18:54:39 UTC
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 126.96.36.199.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.)
Comment 10 Robbie Harwood 2020-06-04 18:55:04 UTC
Created attachment 1695272 [details] non-fips pcap
Comment 12 Isaac Boukris 2020-06-08 09:01:35 UTC
(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.