pkinit slotid=N ?

[Douglas E. Engert]

Nicolas Williams wrote:
> On Wed, Jan 09, 2008 at 09:16:46AM -0600, Douglas E. Engert wrote:
>> Nicolas Williams wrote:
>>> IIRC we discussed this in the past.
>> Yes we have but there has never been a good solution.
>>
>>> One possibility is to search the token for a suitable cert and use the
>>> first one found that can be used successfully. 
>> So how is successful determined? If you mean try and authenticate with
>> it, to the KDC, then you may introduce a lot of extra overhead.
> 
> You can always try in parallel (or, better yet, the krb5 APIs should
> have an async option :)
> 
>> To use the private key, you will have to enter the pin. There are
>> cards that have multiple pins, so you may have to ask the user to
>> enter all of them? Don't rely on using the pin till you are sure you
>> have the right cert.
> 
> At the limit you'll have to ask the user.  That particular situation
> calls for asking the user.
> 
>>> There's a pam_pkcs11 module that does just that sort of thing.  It looks
>>> at each cert it can find in the token until it finds one that a) maps to
>>> the given PAM_USER,
>> Where is this mapping done? We expect to use certs from the HSPD-12
>> PIV cards that do not require a subject alt name for a local principal
>> in the cart. In fact the card should be usable at many different
>> locations, against different realms.
> 
> http://www.opensc-project.org/pam_pkcs11/
> 
> It has number of configurable mapping schemes, from algorithmic (e.g.,
> try to map the cert's DN's CN to a username, similarly with e-mail addr
> and krb5 SANs, ...) to lookup based (in local files, in
> ~/.ssh/authorized_keys, in LDAP).
> 

But this map is local to a machine. We are talking pkinit, and want to
have the KDC do the mapping. But this requires at least finding a cert
that could be usable with pkinit.


>>> b) corresponds to the associated private key, 
>> Cards can have multiple keys, one for each cert, so what does this mean?
> 
> That a signature with a given private key can be verified with the
> associated cert.
> 
>> Another issue is selecting which PKCS#11 module to use. If more then
>> one type of card can be used at the same workstation, and each has its
>> own PKCS#11 module the Kerberos code can not handle this that today.
>
> PKCS#11 is designed so that could be handled.  So this would be a bug in
> the "Kerberos code" (are we talking MIT or Heimdal, or both?).

No not a bug, but code not implemented. is there a "gss mech_glue" equivelent
for pkcs11? Maybe the Solaris pkcs11 has this, if so great. But I don't know
of any other.

> 
>> You could also look at the Heimdal version as it does some of these
>> tests you suggest to locate a sutable cert.
> 
> Good!
> 
> Nico

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444