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.
--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA
