pkinit prompting behavior issue

Nicolas Williams Nicolas.Williams at sun.com
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.

Nico
-- 



More information about the krbdev mailing list