[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Enforce EKU requirements for client tokens during PKINIT
Hello Tim,
I commited the libhx509 parts, since it was a no brainer (just added
test cases). Thanks!
For the krb5_pk_create_sign(), how about the code searches for IETF
EKU, the mssmartcard-login eku and then w/o an eku instead. Would that
no allow no change to the API ?
Love
25 jan 2008 kl. 20.03 skrev Timothy J. Miller:
> Attached is a patch against the 1.0.1 tree. Sorry about that, but
> it took several weeks to figure out my company's policy re: open
> source contributions. In short, I'm free to contribute so long as
> I'm not writing a substantial portion of the total package. I don't
> think that will be a problem. :)
>
> This patch adds a capability to filter certificates on a token based
> on EKU.
>
> Windows PKINIT *requires* id-pkinit-ms-eku to be asserted in the
> client's cert. This is documented in the manual (section 4.26.2,
> "The client certificates need to have the extended keyusage
> “Microsoft Smartcardlogin” (openssl have the oid shortname
> msSmartcardLogin).") but wasn't enforced in the library. This shows
> up when using tokens like the DoD Common Access Card, which have *2*
> certs with digitalSignature asserted--one with msSmartcardLogin and
> one without. The library was consistently selecting the first
> certificate on the token, which 99% of the time is the one without
> msSmartcardLogin, resulting in failed logons.
>
> Also, the requirement for the IETF EKU, id-pkekuoid, was not
> enforced. This patch enforces it, but I've not been able to test it.
>
> I didn't add any config options, choosing instead to leverage
> pkinit_require_eku and pkinit_win2k.
>
> I'm most uncomfortable with altering the interface for
> _krb_pk_create_sign() (see below) but I couldn't find a way around
> it. Since it's and internal function and only invoked from one
> place, I think it's OK.
>
> Without this patch (or something like it), using the DoD CAC or
> upcoming PIV will be impossible. I'll note that MIT Kerb 1.6.3 has
> similar (but more flexible) capabilities via pkinit_cert_match <EKU>.
>
> Summary of changes:
>
> - Defined a new match type, HX509_QUERY_MATCH_EKU
> - Added eku field to the hx509_query_data struct.
> - Added new public function, hx509_query_match_on_eku(hx509_query *,
> const heim_oid *) which sets the query flag and loads the requested
> EKU into the query.
> - Added EKU query support to _hx509_query_match_cert()
> - Added args to _krb5_pk_create_sign() to pass the wink2_compat and
> require_eku flags since the context isn't available.
> - Changed invocation of _krb5_pk_create_sign() in pk_mk_padata() to
> pass the win2k_compat and require_eku flags.
> - Changed _krb5_pk_create_sign() to call hx509_query_match_eku() if
> win2k_compat or require_eku are set. If win2k_compat is set or both
> are set, msSmartcardLogin is used for the query. If win2k_compat is
> not set but require_eku is set, id-pkekuoid is used instead.
>
> I suspect this patch will apply to the new tree as well.
>
> -- Tim
>
>
> <heimdal-1.0.1-eku-filter.patch>