#9373 Make sign_authdata() generate extended KDC signature
Closed: fixed a year ago by rcritten. Opened a year ago by jrische.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 2176406

Support for the PAC extended KDC signature (or "full PAC checksum") has recently been implemented upstream[1] for MIT Kerberos. The fix for bug 2169477 backports the krb5_kdc_sign_ticket() function[2] to krb5 1.18.2. This function is a replacement for krb5_pac_sign() and krb5_pac_sign_ext() functions[3], which are currently used in IPA 4.9.11[4]. These two functions do not generate the extended KDC signature, only krb5_kdc_sign_ticket() does. This is the reason why we are backporting it.

The krb5_kdc_sign_ticket() function was initially introduced[5] to support the new "ticket signature" which was introduced by Microsoft[6] to mitigate CVE-2020-17049 (bronze bit attack). This is the reason why this function expects a krb5_enc_tkt_part[7] parameter representing the encrypted part of the ticket out of which the "ticket signature" is generated.

So, the krb5_kdc_sign_ticket() function generates both the "ticket signature" and the "extended KDC signature", and needs the encrypted part of the ticket.

However, on IPA 4.9.11 the PAC is generated by setting the sign_authdata() callback[8][9]. This callback does not provide the ticket's encrypted part as parameter, making krb5_kdc_sign_ticket() not usable in practice.

To be mentioned that, according to the document[10] that made CVE-2022-37967 public, the ticket signature does not have to be present for the PAC to be accepted.


[1]  https://github.com/krb5/krb5/commit/4602a10dbe380d75d1ec00f7d34479ac9d503735
[2]  https://github.com/krb5/krb5/blob/e35b32f81f9defbcce4f2398d93a975ffb807ee7/src/include/krb5/krb5.hin#L8365-L8393 
[3]  https://github.com/krb5/krb5/blob/e35b32f81f9defbcce4f2398d93a975ffb807ee7/src/include/krb5/krb5.hin#L8351-L8363
[4]  https://pagure.io/freeipa/blob/ipa-4-9/f/daemons/ipa-kdb/ipa_kdb_mspac_v6.c#_179
[5]  https://github.com/krb5/krb5/commit/ee4e3c5c9eee061048d5b7393b8f3820d1a563a8
[6]  https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PAC/%5bMS-PAC%5d-201123-diff.pdf
     Page 26, section 2.8.3
[7]  https://github.com/krb5/krb5/blob/krb5-1.20.1-final/src/include/krb5/krb5.hin#L1927-L1938
[8]  https://github.com/krb5/krb5/blob/4c3063afb4a4b141b70d56aa381784f7efd637c9/src/include/kdb.h#L1277-L1360
[9]  https://pagure.io/freeipa/blob/ipa-4-9/f/daemons/ipa-kdb/ipa_kdb.c#_725
[10] https://i.blackhat.com/EU-22/Thursday-Briefings/EU-22-Tervoort-Breaking-Kerberos-RC4-Cipher-and-Spoofing-Windows-PACs-wp.pdf
     Page 6, 1st paragraph

Metadata Update from @jrische:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2176406

a year ago

Metadata Update from @jrische:
- Issue assigned to jrische

a year ago

ipa-4-9:

  • 922d13a kdb: Use krb5_pac_full_sign_compat() when available

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

a year ago

Does BZ https://bugzilla.redhat.com/show_bug.cgi?id=2178298 need to be updated with this change? It's both a RHEL-9 (so not ipa-4-9) and a krb5 change.

Does BZ https://bugzilla.redhat.com/show_bug.cgi?id=2178298 need to be updated with this change? It's both a RHEL-9 (so not ipa-4-9) and a krb5 change.

No need to mention this commit in BZ2178298 (opened against RHEL 9.3). The fix for ipa-4-10 branch is slightly different, currently in review at https://github.com/freeipa/freeipa/pull/6785.

master:

  • 9cd5f49 kdb: Use krb5_pac_full_sign_compat() when available
  • 3f1b373 Tolerate absence of PAC ticket signature depending of server capabilities
  • 545a363 Filter out constrained delegation ACL from KDB entry

ipa-4-10:

  • 630cda5 kdb: Use krb5_pac_full_sign_compat() when available
  • bbe545f Tolerate absence of PAC ticket signature depending of server capabilities
  • 7ea3b86 Filter out constrained delegation ACL from KDB entry

Metadata Update from @abbra:
- Custom field changelog adjusted to FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7.

a year ago

Metadata Update from @abbra:
- Custom field changelog adjusted to FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20 or later. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7. (was: FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7.)

a year ago

Metadata Update from @abbra:
- Custom field changelog adjusted to FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20 or later. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7. In addition, another 'full PAC' signature type was added to MIT Kerberos 1.21 or later. FreeIPA will support the new signature when running against newer MIT Kerberos version. For older versions, please see https://pagure.io/freeipa/c/9cd5f49c74f28dbe070b072b394747a039cef463. This new PAC signature will be required by default by Active Directory in July 2023 for S4U requests, and opt-out will no longer be possible after October 2023. (was: FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20 or later. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7.)

a year ago

Metadata Update from @abbra:
- Custom field changelog adjusted to FreeIPA KDCs will automatically start requiring two new Kebreros ticket signatures when the whole realm is running on MIT Kerberos 1.21 or later. On older MIT Kerberos versions, the lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7. In addition, a 'full PAC' signature type was added to MIT Kerberos 1.21. FreeIPA will support the new signature when running against newer MIT Kerberos version. For older versions, please see https://pagure.io/freeipa/c/9cd5f49c74f28dbe070b072b394747a039cef463. This new PAC signature will be required by default by Active Directory in July 2023 for S4U requests, and opt-out will no longer be possible after October 2023. We recommend upgrading to newer versions of FreeIPA-based distributions to avoid interoperability break. (was: FreeIPA KDCs will automatically start requiring new Kebreros ticket signature when the whole realm is running on MIT Kerberos 1.20 or later. For previous MIT Kerberos versions lack of the new ticket signature will be tolerated to allow gradual upgrades. More details are available at https://pagure.io/freeipa/c/3f1b373cb2028416e40a26e3dd99b0f4c82525c7. In addition, another 'full PAC' signature type was added to MIT Kerberos 1.21 or later. FreeIPA will support the new signature when running against newer MIT Kerberos version. For older versions, please see https://pagure.io/freeipa/c/9cd5f49c74f28dbe070b072b394747a039cef463. This new PAC signature will be required by default by Active Directory in July 2023 for S4U requests, and opt-out will no longer be possible after October 2023.)

a year ago

Log in to comment on this ticket.

Metadata