Will Fiveash wrote: > On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: >> On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: >>> I believe we are still waiting on a final spec for this case. >>> >>> Specifically is the intent to add a 'pkinit' module option to the existing >>> pam_krb5 module or add a pam_krb5_pkinit module. >> Right, sorry for the delay (was on vacation). I'll update the spec >> taking the "pkinit" module option approach which is preferable over the >> pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for >> the reasons mentioned earlier in this discussion. > > One question; should pam_krb5 doing PKINIT ever try using the password > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > pam_authtok_get like so: > > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 pkinit > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_auth.so.1 > ? > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > user's password and if that failed would try PKINIT preauth again, this > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > doing PKINIT would ignore the user's password and always prompt for the > PIN regardless of where it was in the auth stack.
It may be a bad idea. Each attempt to use the PIN against the smart card counts as a failure. If the user really gets confused, and types in password then wrong PIN, its two strikes rather then one. If the user does this 3 times, its 6 strikes, and this may be enough to turn off the card. I suggest don't try and use a password for a PIN. When PIN pad readers are in wide use, you could not use the password anyway, as the PIN reader is designed to send the PIN directly to the card, bypassing the keyboard and computer. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
