On Mon, Nov 09, 2009 at 02:20:45PM -0800, Gary Winiger wrote: > > > > I want to see an updated pam_krb5(5) man page explaining how to use > > > > PKINIT > > > > and including the example PAM stacks for use of PKINIT. >
> I'd like to propose a different tact. This seem to be to suggest a > separate PAM service module. Has that been considered? I considered it but there would be a lot of redundant code (well depending on how the code is organized) and not much gain. > I'd suggest something like pam_pkinit(5) that interacts with the current > way the PAM stack is configured for pam_krb5(5). > > * pam_pkinit would sit on the PAM stacks above pam_authtok_get(5) > > * If the KDC and krb5.conf(5) are configured for PKINIT and there's > no present user (PAM_USER), pam_pkinit:pam_sm_authenticate() > prompts for the type of login desired: > "Public Key," "Password," ... > If it is "Public Key", do the pkinit thing > If it is "Password", return PAM_IGNORE. I can easily modify my implementation to do that prompting if people are okay with it doing that regardless of whether the user has a token or not. > * If the KDC and krb5.conf(5) are configured for PKINIT and there > is a present user (PAM_USER), pam_pkinit:pam_sm_authenticate() > determines if the user had done the pkinit thing. > If yes, do the pkinit thing for reauthentication. > If not, return PAM_IGNORE. > > * If the KDC and krb5.conf(5) are not configured for PKINIT, > return PAM_SYSTEM_ERR (or possibly PAM_IGNORE). > > * for pam_pkinit:pam_sm_setcred(), return PAM_IGNORE. > > * pass sufficient information in PAM_USER, PAM_AUTHTOK and > SUNW-KRB5-AUTH-DATA pam_data for pam_krb5(5) to know what > to do. Or add another pam_krb pam_data_item ala > KRB5_AUTOMIGRATE_DATA. Note the definition of pam_authtok_get(5) > is to only prompt for the user name if PAM_USER is not set an > only prompt for an authtok (using PAM_PROMPT) if PAM_AUTHTOK > is not set. > > Why should it be that account management and password change are disallowed? They are not disallowed. It's just that pam_krb5 doing PKINIT does not have support for changing the token PIN at this point. Is that a common issue for smartcard users? > It seems to me that PKINIT would act similarly to password in pam_krb5 > that account management could be done. It seems to me that the public > key certificate may have expired and the KDC would say so and return > PAM_NEW_AUTHTOK_REQD. If a cert has expired the KDC sends back a KDC_ERR_INVALID_CERTIFICATE which is used for several cert issues but that has no bearing on a token indicating that the PIN has expired and needs to be changed. This is not currently handled by the code that does PKINIT. Also note that this is also an issue for someone issuing the kinit command to acquire an initial krb cred via PKINIT. If the PIN requires changing, kinit will not prompt for the PIN change. > Similarly it seems to me that even if the user had done a public key login > that they may which to update their Kerberos password. If so then pam_krb5 needs to be stacked under pam_authtok_get since pam_krb5 above pam_authtok_get is only prompting for their PIN and does not prompt for their krb password and thus does not set PAM_AUTHTOK. > To me, a separate module as described seem cleaner and easier to understand > and configure than how I understand the current proposal. > What have I missed in my understanding (or have I missed so much that > it can't even be explained ;-)? I think my proposal is very similar functionally and requires less code change. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
