a suggestion for improving pkinit preauth plugin token choosing

Nicolas Williams Nicolas.Williams at oracle.com
Tue May 11 15:34:31 EDT 2010

On Tue, May 11, 2010 at 11:40:46AM -0700, Henry B. Hotz wrote:
> Not quite sure we're communicating here.  I stated basic requirements

Indeed, we're not.

> to start, so I assume it's the pre-unlock read access that you
> disagree with.  I see that as an implementation simplification (not a
> complication).  It makes it a lot easier to identify the credentials
> you want if you can look at them.

Let me restate my view:

 - It must not be the PAM application that decides what PKCS#11
   slot/token to use.  That's not the application's job.  (The
   application might be aware of what slots belong to the seat being
   used, but so should PAM modules, from contextual information.)

 - Non-PAM callers of krb5_get_init_creds*() shouldn't have to replicate
   code in PAM modules for selecting a slot/token -- that kind of code
   duplication is bad.

 - I don't mind PAM modules sharing a token's PIN and/or logged in
   sessions if that makes sense.  But I think in general it won't,
   because different modules will need different credentials, and it's
   likely (given what Doug has told us) that each credential will use a
   different authid and therefore present as a separate PKCS#11 token.

    - In order for such sharing to work with the PKINIT pre-auth plugin
      we may need additional gic options for passing: the name of the
      PKCS#11 provider and/or function vector for that provider, the
      slot ID of the logged in token, possibly the PIN or a session.
      I'm not opposed to this either.

We need much more experience here.  IMO Will should proceed with his
proposal and, if we learn we do need to have multiple PAM modules
sharing a single token, then I think we'll want to make it so a single
set of prompts is sufficient, in which case we might write a library
function not unlike pam_get_user(), make the relevant modules use
it, and add the gic options I mentioned.  We will not gain the
experience we need by trying for perfection first because we'll never


More information about the krbdev mailing list