a suggestion for improving pkinit preauth plugin token choosing
will.fiveash at oracle.com
Fri May 7 18:30:59 EDT 2010
Since I've been working on the pkinit preauth plugin lately I've noticed
that the algorithm for choosing a PKCS11 token to login to needs work.
What it is currently doing is (in pkinit_open_session) finding the first
token that matches the PKCS11: URI slotID and or token_label parameters
if set in krb5.conf or if those parameters are not set then the first
token found is chosen and if the token sets the CKF_LOGIN_REQUIRED flag
then the user is prompted for their PIN. If the user is able to login
then the token is examined to find the appropriate cert that matches
whatever cert criteria is set in krb5.conf. If an appropriate cert is
not found pkinit returns failure.
I would like to change this behavior such that for each token found
(matching slotID and token_label if specified), the appropriate cert
would be searched for and if the cert in the token matches the cert
matching rule in krb5.conf then that token object would be recorded in
an array of token possibilities. Every token that matches all criteria
would be placed in this array. Once this is done the logic would be:
- If there are no tokens found, prompt the user to insert their
smartcard and rescan the tokens.
- If one matching token is found, prompt the user for the token's PIN
and proceed to use that token/cert for preauth.
- If there is more than one token found, present the matching tokens
label in a menu and prompt the user to choose one then prompt the user
for that token's PIN, etc...
Note that I'm assuming a smartcard will allow access to a cert without
login. If no certs are found (without login) then that token is
Of course it would be best if krb5.conf contained enough token/cert
matching criteria to eliminate ambiguity when choosing a token.
Here are the token and cert selection criteria parameters in krb5.conf:
This is the PKCS11: URI:
All keyword/values are optional. PKCS11 modules (for
example, opensc-pkcs11.so) must be installed as a crypto
provider under libpkcs11(3LIB). slotid= and/or token=
can be specified to force the use of a particular smart
card reader or token if there is more than one avail-
able. certid= and/or certlabel= can be specified to
force the selection of a particular certificate on the
device. See the pkinit_cert_match configuration option
for more ways to select a particular certificate to use
In addition to these optional parameters, there is:
pkinit_cert_match = rule
Specifies matching rules that the client certificate
must match before it is used to attempt pkinit authen-
tication. If a user has multiple certificates available
(on a smart card, or by way of another media), there
must be exactly one certificate chosen before attempting
pkinit authentication. This option can be specified
multiple times. All the available certificates are
checked against each rule in order until there is a
match of exactly one certificate.
The Subject and Issuer comparison strings are the
RFC2253 string representations from the certificate Sub-
ject DN and Issuer DN values.
The syntax of the matching rules is:
relation-operator Specify relation-operator as &&,
meaning all component rules must
match, or ||, meaning only one
component rule must match. If
relation-operator is not specified,
the default is &&.
component-rule There is no punctuation or white
space between component
rules.Specify component-rule as one
of the following:
where extended-key-usage-list is a comma-separated list
of required Extended Key Usage values. All values in
the list must be present in the certificate.
where key-usage-list is a comma-separated list of
required Key Usage values. All values in the list must
be present in the certificate.
pkinit_cert_match = ||<SUBJECT>.*DoE.*<SAN>.*@EXAMPLE.COM
pkinit_cert_match = &&<EKU>msScLogin,clientAuth<ISSUER>.*DoE.*
pkinit_cert_match = <EKU>msScLogin,clientAuth<KU>digitalSignature
I am assuming there are enough criteria to eliminate ambiguity.
Thoughts on my idea for refining the token selection and prompting?
Note my new work e-mail address: will.fiveash at oracle.com
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/
More information about the krbdev