a suggestion for improving pkinit preauth plugin token choosing

[Nicolas Williams]

On Mon, May 10, 2010 at 04:55:39PM -0700, Henry B. Hotz wrote:
> In both cases, I have to ask if they should be handled by a PKINIT
> plugin at all.

Yes, they have to be.

> In order to do PKINIT, there are some prerequisites:  You need to have
> the PKI credentials available (and selected/identified), and unlocked.
> I'm personally OK with requiring pre-unlock access to the information
> needed to identify the credentials you want to use, but if I'm being
> PIV-card provincial feel free to speak up.

That would complicate things and violate architecture.  Don't get me
wrong, I think it'd be nice to have a PAM item or PAM data naming
convention for sharing PINS or PKCS#11 sessions (respectively) between
modules so that PAM modules that could share a single token need not
prompt for a PIN for that token more than once.  (Not that it's likely
that you'll have more than one module on a stack that can make use of
tokens.)  The problem is that the application would have to know a
priori that the stack is going to need a logged in token session.

> I think prompting (via supplied prompter function) to unlock use of
> the secret key is in scope for a pre-auth plugin.  It had better be
> possible for that function to bridge between a PAM conversation and
> supplying a PIN to pkcs11.

So what's not in scope?  Prompting for which token to login to?  What if
there's more than one?  How will the pre-auth plugin decide which to
prompt for the PIN to?  What if that's wrong?  Slot IDs might not be
stable.  Token labels might not follow a preset naming convention.  The
tokens might require a login in order to view public objects.  Will has
looked at this problem long and hard, and I don't see how to avoid what
he's proposing.  Moreover, you're not explaining why what he's proposing
is wrong or bad, nor are you proposing workable alternatives.

> I also think that things like "pretty please insert your card" are
> outside the scope of what a pre-auth plugin ought to be responsible
> for.  A pre-auth plugin should just return an error indicating "no
> cred's", or "multiple (ambiguous) creds".

But why do you think so?  (I believe the argument would be to reduce
code duplication.  See below.)

> I think user context-setup interactions (like "pretty please insert
> your card") are a higher-level issue, and the responsibility of
> pam_krb5, or maybe even the application calling PAM.  If it's a
> command line, then it prints the appropriate error, and the user can
> insert the card and do it over.  (Actually, I think I've argued for
> do-over in the PAM case as well, haven't I?)

It most definitely cannot be the PAM _application_'s job, as explained
above.  It certainly could be a PAM _module_, like pam_authtok_get(5),
only for tokens, and using either a PAM data naming convention to share
logged-in sessions with other modules or PAM items to share PINS with
other modules.  That would imply a gic option to pass the PINs/sessions
to the PKINIT pre-auth plugin.

However, PAM may not be the only context where prompting for which token
to use may be necessary, so now we're talking code duplication.   Sure,
a common PAM module would reduce code duplication in a PAM context, but
_only_ in a PAM context.  kinit(1) might want the same prompting
behavior, as might other krb5_get_init_creds*() non-PAM applications.

Nico
--