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 ? > 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. 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. -- Darren J Moffat
