a suggestion for improving pkinit preauth plugin token choosing

[Henry B. Hotz]

To borrow a phrase "I think I'm in the rough here."  I don't think I'm being irrational though, and I can at least say that I'm being reasonable for what I understand about our own PIV card deployment.

On May 11, 2010, at 8:46 AM, Nicolas Williams wrote:

> 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.  

Not quite sure we're communicating here.  I stated basic requirements 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.

There are clearly conflicting world views here, partly due to differing card deployment scenarios.  In my view it doesn't seem reasonable to pre-configure the selection criteria for credentials to the point that you don't have to inspect them prior to use.  It also doesn't seem reasonable to get a PIN to unlock some creds that you *don't* use.

Rather than deal with the double additions to system complexity, just say up front that you need enough access to identify the creds you're using before you prompt for a PIN or do anything else.  Discussions on this thread suggest this isn't unreasonable.

> 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.)  

Actually, it makes a lot of sense to have both pam_pkcs11 and pam_krb5 (with PKINIT) as both "sufficient" on a laptop that may, or may not, have network connectivity.  I don't think I'm arguing for that kind of change to PAM, since I assume it would work to just re-open the PKCS#11 module.

> 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 don't see why.  See below.

>> 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?  

Everything else.  ;-)

> Prompting for which token to login to?  

I can applaud your desire, as an OS vender, to support the possibility of multiple, possible PKI credentials to use for login, and to provide a sane UI in that scenario.  However. . .

Speaking as someone responsible for a specific deployment, it isn't necessary, and the problems I see are the opposite.  

<rant!!>
By definition a person can only have one PIV card.  Therefore if you have a person with a user account and 2-3 admin accounts, you should be able to use the PIV card for any of those.  (The UI model of having the card plug-in select the login account is just broken, and I've spoken to people at NASA and some DOE labs who agree with me.)  

Furthermore the card is usually issued by a different organization from the one using/deploying the card, so *any* use of the issuer-defined UPN value in the card's certificate is almost certainly wrong!

Linux with the Debian pam_krb5 is way, way easier to set up than Apple or Microsoft, because they don't do a bunch of inappropriate things based on the UPN.  Every time I think about all the time I've wasted dealing with the problems caused by all the time Apple and MS wasted creating those problems in the first place I just want to. . . 
</rant!!>

OK, I'm better now, I think.  More below.

> 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.)

Perhaps this is the same thing, but it seems like an abstraction layer violation to have a Kerberos plugin designed to deal with the supposedly-low-level PKCS#11 API do the kinds of cred-selection operations you're talking about.  That seems like a configuration/setup operation.

>> 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.

I'm having trouble imagining plausible scenarios where there would be multiple PKI credentials available to support a login.  I don't think it makes sense to design a card with multiple authentication identities.  (OK, maybe if one of them were a card admin identity, but you wouldn't want to use that one for workstation login, and it had better be easy to filter out.)

If you have multiple ways for a user to present PKI creds, and the user presents multiple PKI creds, then that's probably a user error similar to not presenting any.  I think it's perfectly OK to fail the operation (with an appropriate error displayed to the user) in this case.  That's way simpler than building an infrastructure to disambiguate which one is wanted (especially if it really is a user error).

I was going to write some stuff about a hypothetical multiple-credential scenario.  The trouble is, it's just hypothetical.  I think I need some real use cases in order to justify the overhead of any fancy cred-selection infrastructure.

> 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.

I would hope and expect that you can usually configure your cred-selection criteria once at workstation setup to match your card/PKI provider.  There seem to be a bunch of workable examples out there, which I object to mainly because their documentation seems unclear.  

If you have enough variety that you need to change criteria on a per-session basis, then you probably need a "switch" utility to reconfigure the PKCS#11 infrastructure on-the-fly.  Then, yes, you would need a pam_pkcs11_get to exercise that utility, that's comparable to pam_authtok_get.  All the angst (that leads to threads like this one) leads me to believe that the problem needs to be solved underneath the PKCS#11 layer.

*IF* you actually need to deal with this degree of complexity.  Perhaps we'll get there in time, if old, crufty card deployments become more common.

> Nico
> -- 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu