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