Skip Menu |
 

Subject: Regression in rule-based matching of PKINIT client certs with UPN SANs
Download (untitled) / with headers
text/plain 1.3KiB
Standard PKINIT client certificates use Subject Alternative Name
(SAN) values of type id-pkinit-san containing an ASN.1 DER
representation of the principal name and realm. Client certificates
issued for use with Windows KDCs may instead contain SAN values of
type id-ms-san-sc-logon-upn containing a UTF-8 string giving the
UserPrincipalName (UPN) of the client account object.

Ticket 8528 improved matching of UPN SAN certificates against the
client principal. As part of that improvement, UPN SANs values are
correctly parsed as enterprise principal names (one data component
usually containing an "@" character, no realm). Unfortunately this
change breaks matching of UPN SANs against pkinit_cert_match rules.
The matching code concatenates PKINIT SAN and UPN SAN principals
together without remembering which is which, and unparses each
principal normally (yielding a string like "a\@b@DEFAULT.REALM" for
an enterprise principal name) before matching them against the
regular expression in the rule. If the rule is written naturally as
"<SAN>^a@b$", it will not match.

The best fix is to record the original UPN SAN string in the matching
data and match that against the rule regexp. An acceptable fix would
be to unparse UPN SANs with the KRB5_PRINCIPAL_UNPARSE_NO_REALM flag,
which would usually yield the original UPN string.
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.1KiB

Fix PKINIT rule matching against UPN SANs

Commit 46ff765e1fb8cbec2bb602b43311269e695dbedc (for ticket 8528)
broke rule-based matching of UPN SANs using the <SAN> rule type. To
fix this regression, make crypto_retrieve_cert_sans() return UPN SANs
in their original string form, and only parse them into principal
names in pkinit_srv.c:verify_client_san(). In
pkinit_cert_matching_data, store UPN SANs as strings separately from
PKINIT SANs instead of concatenating them together, and match original
UPN strings against <SAN> rule regexps. Add a test case.

https://github.com/krb5/krb5/commit/0f26c1c7504777d6e7bfa1d3dee575c504ab6c05
Author: Greg Hudson <ghudson@mit.edu>
Commit: 0f26c1c7504777d6e7bfa1d3dee575c504ab6c05
Branch: master
src/plugins/preauth/pkinit/pkinit_crypto.h | 6 +-
src/plugins/preauth/pkinit/pkinit_crypto_openssl.c | 63 ++++----------------
src/plugins/preauth/pkinit/pkinit_matching.c | 20 ++++---
src/plugins/preauth/pkinit/pkinit_srv.c | 21 ++++--
src/plugins/preauth/pkinit/pkinit_trace.h | 3 +
src/tests/t_pkinit.py | 7 ++
6 files changed, 52 insertions(+), 68 deletions(-)
From: ghudson@mit.edu
Subject: git commit
Download (untitled) / with headers
text/plain 1.2KiB

Fix PKINIT rule matching against UPN SANs

Commit 46ff765e1fb8cbec2bb602b43311269e695dbedc (for ticket 8528)
broke rule-based matching of UPN SANs using the <SAN> rule type. To
fix this regression, make crypto_retrieve_cert_sans() return UPN SANs
in their original string form, and only parse them into principal
names in pkinit_srv.c:verify_client_san(). In
pkinit_cert_matching_data, store UPN SANs as strings separately from
PKINIT SANs instead of concatenating them together, and match original
UPN strings against <SAN> rule regexps. Add a test case.

(cherry picked from commit 0f26c1c7504777d6e7bfa1d3dee575c504ab6c05)

https://github.com/krb5/krb5/commit/67632329dbacf7b1964df01a88f061d2f16063ef
Author: Greg Hudson <ghudson@mit.edu>
Commit: 67632329dbacf7b1964df01a88f061d2f16063ef
Branch: krb5-1.16
src/plugins/preauth/pkinit/pkinit_crypto.h | 6 +-
src/plugins/preauth/pkinit/pkinit_crypto_openssl.c | 63 ++++----------------
src/plugins/preauth/pkinit/pkinit_matching.c | 20 ++++---
src/plugins/preauth/pkinit/pkinit_srv.c | 21 ++++--
src/plugins/preauth/pkinit/pkinit_trace.h | 3 +
src/tests/t_pkinit.py | 7 ++
6 files changed, 52 insertions(+), 68 deletions(-)