On Fri, Dec 11, 2009 at 09:18:24AM +0000, Darren Moffat wrote: > 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. > > I've attached the updated: > > - fasttrack > > > The pam_krb5 authentication module will support being stacked two times > > in the auth stack to support a "fall back to password based Kerberos > > preauth" scenario. The second instance of the pam_krb5 auth module in a > > auth stack would check if the previous instance of the pam_krb5 auth > > module returned PAM_SUCCESS and if so would immediately return > > PAM_IGNORE. > > I assume a private to pam_krb5 PAM data item is being used for this, right ?
Yes, there is a krb module data struct that is private to pam_krb5 and is being used for this purpose (among others). > > Use of smartcards is > > + supported by PKINIT authentication > > I'd rather this was more generic (and true) by saying any PKCS#11 accessible > keystore capable of storing the required credentials, eg a smartcard. > Particularly since at this time there is no support for Smartcard in > OpenSolaris (OpenSC is available from the /crontrib repository but it hasn't > been signed so can't plugin to libpkcs11). > > I won't hold up the case for that though, since that is really just a man > page clarification. Okay, I'll modify the man page update to state the above. > For the fallback case I'm not sure I see why we need two instances of the > module in the stack, couldn't this be done by adding another module option > (eg password_fallback) in that case PAM_AUTHTOK would be set to what the > user entered (assuming it was available) and password based preauth would be > attempted. If that complicates things too much or there are other reasons > to allow for two instances of pam_krb5 in the stack then I'm happy with the > case as specified. The problem is that the current design states that if PAM_AUTHTOK is set, that is what pam_krb5 will use regardless of whether it is doing password based krb preauth or PKINIT. This means that if the admin wants pam_krb5 pkinit to prompt for a PIN it must come before pam_authtok_get. If the admin also wants password fall-back then pam_krb5 must come after pam_authtok_get. That is why two instances of pam_krb5 in the auth stack is supported. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
