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
That is above authtok_get. > 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. I can see a use case for either case. Wither it is a bad idea or not depends on wither or not it would cause the PKCS#11 token to record a failed login attempt or if it would cause a Kerberos failed login attempt. So I'd say be on the safe side and if pkinit is specified don't use PAM_AUTHTOK at all for authenticating to the PKCS#11 token. -- Darren J Moffat
