a suggestion for improving pkinit preauth plugin token choosing
Nicolas.Williams at oracle.com
Tue May 11 11:46:27 EDT 2010
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.
More information about the krbdev