[15512] in Kerberos_V5_Development
Re: pkinit prompting behavior issue
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Tue Feb 23 12:20:36 2010
Message-ID: <4B840E5E.4090500@anl.gov>
Date: Tue, 23 Feb 2010 11:20:30 -0600
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@sun.com>
In-Reply-To: <20100223162150.GV1061@Sun.COM>
Cc: Sam Hartman <hartmans@mit.edu>, MIT Kerberos Dev List <krbdev@mit.edu>,
Jeffrey Hutzelman <jhutz@cmu.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
