pkinit prompting behavior issue

Douglas E. Engert deengert at
Tue Feb 23 12:20:30 EST 2010

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
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>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the krbdev mailing list