a suggestion for improving pkinit preauth plugin token choosing

[Will Fiveash]

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
skipped.

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:

    PKCS11:[slotid=slot-id][:token=token-label][:certid=cert-
         id][:certlabel=cert-label]

         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
         for pkinit.

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]component-rule `...'

         where

         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:

                                `<SUBJECT>'regular-expression

                                `<ISSUER>'regular-expression

                                `<SAN>'regular-expression

                                `<EKU>'extended-key-usage-list
                                               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.
                                                    `pkinit'
                                                    `msScLogin'
                                                    `clientAuth'
                                                    `emailProtection'
                                `<KU>'key-usage-list
                                               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.
                                                    `digitalSignature'

         Examples:
           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?

-- 
Will Fiveash
Oracle
Note my new work e-mail address: will.fiveash at oracle.com
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/