pkinit prompting behavior issue

[Douglas E. Engert]

Nicolas Williams wrote:
> On Tue, Feb 23, 2010 at 10:05:37AM -0500, Jeffrey Hutzelman wrote:
>> I think at the Kerberos/PKINIT layer, the correct default behavior is as 
>> Will proposes - if no card/token is found, prompt for one.  PAM modules 
>> should probably be configurable in this respect; depending on the 
> 
> For screen saver type PAM apps you really need at least one prompt,
> otherwise they loop (since pam_authentication() should fail).  (This was
> the case that prompted Will to ask about this.)
> 
> (There's another problem, BTW: C_Login() for tokens with PIN pads is,
> IIRC, blocking, and PAM conversations too are blocking, so that if we
> need a PAM prompt to tell the user to enter their PIN then we'll need
> the C_Login() call to happen on a different thread.)

It may be blocking, but before the C_Login is called, one should have called
C_GetTokenInfo and test the CK_TOKEN_INFO for CKF_PROTECTED_AUTHENTICATION_PATH
in which case the C_Login pin parameter should be NULL.
So a "enter pin on pad" message (not a prompt) could be displayed before the
call to C_Login it will then block waiting for the user to enter the pin.
(Its not clear how a user cancels the operation, could be user pull out the card?)

> 
>> environment, one might wish to prompt for a token if none is present or 
>> assume that if there is no token, the user does not intend to use PKINIT.
> 
> I'm not sure when you'd ever want to assume that "no token present ->
> don't use PKINIT" in a PAM app.  I guess if you're prompting for a
> username and the user enters one without having inserted a token then
> you might want to assume that no token will be available.  Screen saver
> apps don't prompt for a username because they set PAM_USER ahead of
> calling pam_authenticate().  (Ah, in screen saver context we might want
> pam_krb5 to know whether PKINIT had been needed on the original login
> and to skip PKINIT if not.)

Russ's pam_krb5 took care of this, as PKINIT was not called until a blank
was entered for the password. So the user could insert the card before
typeing the blank. About the best one could do with current PAM stacks.


> 
> As for PKCS#11 softtokens on USB drives...  I believe that a softtoken
> implementation should present N virtual slots, all empty, and when
> removable media becomes available (mounted) it should search the
> top-level for softtoken files, then pick the first available virtual
> slot and pretend that there is now a token in that slot (and
> C_Wait4Slot() should allow you to wait on a virtual slot).  Of course,
> having virtual softtoken slots means that one could not skip an "insert
> token" prompt on the basis of there being no slots.
> 
> Nico

PKCS#11 says the list of slots is fixed at the time C_Initialize is called.
OpenSC pkcs#11 in the svn has a "Virtual hotplug slot" designed to use with
USB tokens, to get around this issue.

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444