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
finish.
Nico
--
More information about the krbdev
mailing list