pkinit prompting behavior issue

Nicolas Williams Nicolas.Williams at
Tue Feb 23 11:21:50 EST 2010

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

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

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.


More information about the krbdev mailing list