Kerberos PKINIT: what, why, and how (to break it) [Everything Open 2023]

The Kerberos PKINIT extension replaces password authentication with
X.509 certificates. This bring some advantages but also new risks.
In this presentation I explain and demonstrate how PKINIT works, and
present a novel attack against FreeIPA's PKINIT implementation.

Kerberos is an authentication and single sign-on protocol based on
symmetric cryptography. To avoid the drawbacks and risks of
passwords, the PKINIT protocol extension enables clients to
authenticate using public key cryptography and X.509 certificates.
To further improve security, private keys can reside and
signing/decrytion operations can be performed on hardware
cryptographic tokens (smart card, PIV, TPM, etc).

I will start the talk with a brief overview of the core Kerberos
protocol. Next I will explain how the PKINIT extension works, and
demonstrate how to set up PKINIT and use it in a FreeIPA
environment.

Finally I will discuss some of the risks that arise when using
PKINIT, and security considerations for implementations and
administrators. I will present and demonstrate a recently
discovered PKINIT security flaw in some older (but still supported)
versions of FreeIPA.

Transcript

1. Kerberos PKINIT what, why and how (to break it) Fraser Tweedale @hackuador@functional.cafe March 15, 2023
2. Agenda Kerberos overview Kerberos PKINIT: overview and demo PKINIT security considerations Attack demo: CVE-2022-4254
3. Kerberos - overview Authentication protocol based on symmetric cryptography Single sign-on: authenticate once, access many services Started at MIT (1988), v5 (1993), RFC 41201 (2005) Major implementations: MIT Kerberos2, Microsoft Active Directory, Heimdal3, FreeIPA4 / Identity Management in RHEL 1https://www.rfc-editor.org/rfc/rfc4120 2https://web.mit.edu/kerberos/ 3https://github.com/heimdal/heimdal 4https://www.freeipa.org
4. Kerberos - protocol Parties: client, Key Distribution Centre (KDC), service KDC = Authentication Service (AS) + Ticket Granting Service (TGS) Users, services, KDC are represented as principals in a realm Each principle has a long-term secret key, shared with the KDC users derive it from a password hosts/services store it in a file ("keytab") Authentication tokens are called tickets
5. Kerberos - protocol - parties
6. Kerberos - protocol - Authentication Service request
7. Kerberos - protocol - Authentication Service response
8. Kerberos - protocol - after AS exchange
9. Kerberos - protocol - Ticket-Granting Service request
10. Kerberos - Ticket-Granting Service response
11. Kerberos - after TGS exchange
12. Kerberos - application request
13. Kerberos - application session
14. Kerberos - extensions and integrations Pre-authentication framework5 integrate additional authentication mechanisms e.g. OTP6 GSSAPI mechanism7 SASL mechanism8 HTTP authentication (SPNEGO)9 Authentication Indicator10 Cross-realm authentication (trusts) 5RFC 6113 - https://www.rfc-editor.org/rfc/rfc6113 6https://web.mit.edu/kerberos/krb5-devel/doc/admin/otp.html 7RFC 4121 - https://www.rfc-editor.org/rfc/rfc4121 8RFC 4752 - https://www.rfc-editor.org/rfc/rfc4752 9RFC 4178 - https://www.rfc-editor.org/rfc/rfc4178 10RFC 8129 - https://www.rfc-editor.org/rfc/rfc8129
15. Kerberos - advantages Single sign-on: improve efficiency, reduce password fatigue Client exposes long-term secret only once (until TGT expires) Resistant to replay attacks Works well for HTTP and "bare" network protocols
16. Kerberos - problems Passwords are not great Password / keytab rotation is burdensome
17. PKINIT - overview Public Key Cryptography for Initial Authentication in Kerberos11 Client uses asymmetric cryptography to authenticate to KDC Client presents X.50912 certificate and signs message KDC verifies certificate, signature and client binding KDC encrypts response using either: Diffie-Hellman (DH) or analogous key agreement algorithm other public-key encryption algorithm 11RFC 4556 - https://www.rfc-editor.org/rfc/rfc4556 12RFC 5280 - https://www.rfc-editor.org/rfc/rfc5280
18. PKINIT - protocol - Authenticate Service request
19. PKINIT - protocol - Authentication Service response
20. PKINIT - protocol - after AS exchange
21. PKINIT - user experience CLI: kinit -X X509_user_identity=FILE:cert.pem,key.pem Smart Card workstation login SSSD13 can integrate with Linux login managers (e.g. GDM) Prompt for PIN, if required TGT acquired during login Lock screen when Smart Card detached (optional) Windows offers a similiar experience 13https://sssd.io/
22. Smart Card login with SSSD (Fedora / RHEL) Enable via authselect(8): % a u t h s e l e c t enable −f e a t u r e \ with−smartcard [− r e q u i r e d ] with−smartcard −lock −on−removal Update /etc/sssd/sssd.conf: [ pam ] pam_cert_auth = True pam_cert_db_path = <path−to−pem−bundle>
23. SSSD PKINIT login with FreeIPA provider Default: exact certificate match only match the LDAP userCertificate attribute Optional: certificate mapping rules use attributes in certificate to look up principal ipa certmaprule-add certmap \ --maprule "(fqdn={subject_dns_name})" caveat: only one active mapping rule will be used Client certs can be signed by internal or third-party CA
24. Demo
25. PKINIT - advantages No more passwords / client shared secret Key can reside on Smart Card (e.g. Yubikey) / TPM / HSM The rest of the protocol (after AS Exchange) is unchanged
26. PKINIT - complexities X.509 PKI required Renewal considerations Revocation checking is hard (or time consuming) Hardware (e.g. Smart Cards) → additional cost Binding the public key to the principal - how?
27. PKINIT - key binding In addition to validating the client’s signature, the KDC MUST also check that the client’s public key used to verify the client’s signature is bound to the client principal name specified in the AS- REQ as follows: 1. If the KDC has its own binding between either the client’s signature-verification public key or the client’s certificate and the client’s Kerberos principal name, it uses that binding. 2. Otherwise, if the client’s X.509 certificate contains a Subject Alternative Name (SAN) extension carrying a KRB5PrincipalName (defined below) in the otherName field of the type GeneralName [RFC3280], it binds the client’s X.509 certificate to that name.
28. PKINIT - key binding Encode principal name in certificate (KRB5PrincipalName SAN) Associate certificate/key with principal in database administrative overhead due to renewal/rekey Other heuristics; for example: if certificate has dNSName SAN, look for that host principal if certificate has rfc822Name (email address) SAN, look for the corresonding user principal Better not mess this up!
29. CVE-2022-4254
30. CVE-2022-4254 - what happened? LDAP filter injection14 FreeIPA not vulnerable in default configuration only exact certificate match is enabled by default Bug introduced in SSSD v1.15.3 and resolved in v2.3.1 Will also be fixed in of v1.16.6, if/when released 14CWE-90 - https://cwe.mitre.org/data/definitions/90.html
31. CVE-2022-4254 - LDAP filter (& (| (objectClass= krbprincipalaux ) (objectClass=krbprincipal) (objectClass= ipakrbprincipal ) ) (| ( ipaKrbPrincipalAlias = host/rhel78-0.ipa.test@IPA.TEST ) ( krbPrincipalName : caseIgnoreIA5Match := host/rhel78 -0. ipa.test@IPA ) ( fqdn=*.ipa.test ) )
32. What if your email address is "bogus)(uid=admin)(cn="@ipa.test
33. . . . and your certmap rule looks like (|(mail={subject_rfc822_name})(entryDN={subject_dn})
34. CVE-2022-4254 - domain takeover (& (| (objectClass= krbprincipalaux ) (objectClass=krbprincipal) (objectClass= ipakrbprincipal ) ) (| ( ipaKrbPrincipalAlias = admin@IPA.TEST ) ( krbPrincipalName : caseIgnoreIA5Match := admin@IPA.TEST) ) (| (mail =" bogus) ( uid=admin ) (cn=" @ipa.test) (entrydn=CN=alice ,O=IPA.TEST 202211171708) )
35. CVE-2022-4254 - mitigations Upgrade to fixed/patched releases of SSSD and-list rules are harder to exploit than or-list Audit what data get included in certs, and how Use exact certificate matching
36. PKINIT - security considerations Properly escape/sanitise all inputs, always. Review CA trust, profiles, and validation behaviour Which CAs do you trust? Who can issue certificates? How do you validate the data that go into a certificate? Can attributes be influenced by users or other parties? Just because a value is valid does not mean it’s benign Key/principal binding is a critical aspect of PKINIT security
37. Links / resources certmap vulnerability: Writeup: https://is.gd/CVE_2022_4254 Red Hat CVE database: https://access.redhat.com/security/cve/CVE-2022-4254 Related effort: FreeIPA FIDO2/Webauthn support FOSDEM 2023 talk: Enabling FIDO2/WebAuthn support for remotely managed users15 15https://fosdem.org/2023/schedule/event/security_remote_fido/
38. © 2023 Red Hat, Inc. Except where otherwise noted this work is licensed under http://creativecommons.org/licenses/by/4.0/ Slides speakerdeck.com/frasertweedale Blog frasertweedale.github.io/blog-redhat Email ftweedal@redhat.com Fediverse @hackuador@functional.cafe