pkinit prompting behavior issue

[Douglas E. Engert]

Nicolas Williams wrote:
> On Tue, Feb 23, 2010 at 11:20:30AM -0600, Douglas E. Engert wrote:
>> 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.
> 
> Indeed, that's a messagem not a prompt.  But I think GUIs typically
> implement PAM messages as dialogs with an Ok button.  Perhaps that's
> mistake and informative messages should be displayed until the next
> conversation, with the conversation function returning immediately.
> (Yes, that would really help.)
> 
>> (Its not clear how a user cancels the operation, could be user pull out the 
>> card?)
> 
> Probably.
> 
>>> 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.
> 
> Why have a password prompt if you're doing PKINIT?


Without major modifications to the pam stack, a password prompt is all you
really have to work with. The next step would be prompt "enter password or insert
card and enter a blank".
Based on the discussions about the Sun pam_krb5 being in the stack in more
then one place, you are trying to get around this problem by getting a prompt
up before the pam_authtok_get would prompt for a password.
pam in general still only likes a user and password.

The real solution would be pam presenting the user with options, of
what type of login would the user like to try. i.e. re write your pam_authtok_get.

So Russ's pam_krb5 does what it has to, to live in the middle of a
traditional pam stack.

> 
>>> As for PKCS#11 softtokens on USB drives...  I believe that a softtoken
>>> ...
>> 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.
> 
> Yes, but a softtoken implementation can pretend that there are N slots
> at that point.
> 
> Nico

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444