pkinit prompting behavior issue

[Douglas E. Engert]

Nicolas Williams wrote:
> On Tue, Feb 23, 2010 at 01:27:10PM -0600, Douglas E. Engert wrote:
>> Nicolas Williams wrote:
>>> On Tue, Feb 23, 2010 at 11:20:30AM -0600, Douglas E. Engert wrote:
>>>> 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.
> 
> Huh?  PAM is absolutely not bound to have only password prompts.  All
> prompts should come from modules.  Applications that put up a dialog
> with a username and password prompt are broken (GDM on OpenSolaris, for
> example, gets this right).  A pam_krb5 module is perfectly capable of
> prompting for the user to insert their smartcard.

I don't think we are going to get anywhere here. I would argue that
Sun having to put the pam_krb5 before the pam_authtok_get is a kluge.

What happens when the next developers of pam modulers look at the pam_krb5
and say, we can't let pam_krb5  be first in the stack. We need to be first.
(What ever happened to the Solaris 10 "pam_smartcard.so" module that used
to be before pam_authtok_get?)

pam_authtok_get was a good idea and should be first BUT needs to do
more then ask for username and password. It should be asking the user why
type of authentication should be tried based on what the system supports,
(smartcard, OTP, fingerprint, retina scan? ...) and then passing on the
selection to other modules.

And I am not saying that open source pam modules have solved this either.
Pam in general needs an overhaul.

> 
> Nico

-- 

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