Bug 1838628

Summary: In FIPS mode constrained delegation fails with Cryptosystem internal error
Product: Red Hat Enterprise Linux 8 Reporter: anuja <amore>
Component: krb5Assignee: Robbie Harwood <rharwood>
Status: VERIFIED --- QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: abokovoy, cheimes, dpal, fdvorak, iboukris, ksiddiqu, pvoborni, rcritten, rharwood, ssorce, tscherf
Target Milestone: rcKeywords: TestCaseProvided
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: krb5-1.18.2-4.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1793411    
Description Flags
non-fips pcap none

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):
release: 1.module+el8.3.0+6429+acaee14b
version: 4.8.6

How reproducible:

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 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.

Comment 13 Isaac Boukris 2020-06-08 17:11:36 UTC
This should be fixed upstream with: https://github.com/krb5/krb5/pull/1080