[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 ?


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>