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.
The problem with trying to use an auth token that could be potentially be a password is that it could rapidly increase a smart card's lock out count. Ergo I would be conservative here and only attempt a PIN if PKINIT has been specified. -- Shawn. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/kerberos-discuss/attachments/20091208/e6845722/attachment.html>
