On Tue, Nov 10, 2009 at 08:54:52AM -0600, Douglas E. Engert wrote:
>
>
> Will Fiveash wrote:
> > 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).
>
> That sounds a lot like pam_krb5 pkinit i.e. the same module with a
> parameter?
I agree.
> >>
> >> * 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," ...
>
> add in "smart card" as Public Key might not involve a smart card.
Understood. Note that my current implementation of pam_krb5 PKINIT
support does the following in regards to prompting:
- If the token does not set CKF_LOGIN_REQUIRED and no suitable cert is
found pam_krb5 does not prompt for anything and returns either failure
or ignore depending on the presence of the passwd_fallback argument.
- If the token does not set CKF_LOGIN_REQUIRED and a suitable cert is
found then the pam_krb5 will prompt for the user's PIN when trying to
access their private key. Again the return will depend on PKINIT
succeeding or failing and the presence of the passwd_fallback
argument.
- If the token sets CKF_LOGIN_REQUIRED then the pam_krb5 will prompt for
the user's PIN immediately before searching for a suitable cert.
Currently there is no prompt reminder to alert the user to insert their
token/smartcard. If there is consensus that this is needed I can add
what Gary has proposed (keeping in mind what you wrote above). Note
that the result of such prompting will only affect the behavior of the
instance of pam_krb5 that is issuing that prompt.
> >> If it is "Public Key", do the pkinit thing
> >> If it is "Password", return PAM_IGNORE.
>
> The above sounds more like a replacement for pam_authtok_get which
> prompts for the type authentication the user would like to request. I
> like the idea of a new pam_authtok_get that is more generic and
> prompts for the type of authentication the user wishes to try. Maybe
> it presents a menu of choices and the sets some PAM_AUTH_TYPE
> variable usable by other pam modules or pass back to pam to alter the
> path through the stack to select only some modules. Think more then
> just Kerberos... (This could also get around the issue of APM a
> trying a password against multiple authentication data bases, like
> Kerberos/AD, then local. If the local password is used,AD will
> consider this a strike against the user, and my lock the account.)
>
> You guys are just focusing on login, you need to also focus on screen
> lock/unlock. With xscreensaver, The application puts up a window,
> and passes in PAM_USER and pam_conv to pam_start. It then times out
> the window if no input. So you can not rely on PAM_USER being present
> or not, as it will be present.
My implementation does not rely on the presence of PAM_USER as an
indication of whether to do PKINIT or password based preauth. It relies
on whether PAM_AUTHTOK (i.e. the password) is set to make this
determination. It should work properly with a xscreensaver.
> I will make another pitch at this, put pam_authtok_get first, and if
> the password entered is "PKI", "PKINIT", "smart card" or some other
> key phrase (blank?), then pam_krb5 will try PKINIT. You only need one
> pam_krb5 on the stack too, and if the pam_authtok_get changes, you
> don't have to change pam_krb5.
What if there is another required module below pam_krb5 that requires a
password?
> This is what Russ's open source pam_krb5 does, if PAM_AUTHTOK is a blank,
> and the try_pkinit parameter is set, it will try pkinit.
How would his implementation work with the current behavior of Solaris
pam_authtok_get given that is the module that is responsible for
prompting for a user's password? From what I can tell there are
auth stack configuration that it would not be suitable for since it
prompts for the user's password in some cases.
I think the bottom line here is that a number of people are
uncomfortable with > 1 instance of pam_krb5 in an auth stack. However
in order to avoid this and also avoid an unnecessary prompt for password
from pam_authtok_get means that pam_authtok_get must also be modified
which I believe isn't necessary since my implementation of pam_krb5
PKINIT supports all reasonable auth configurations without any
modification to pam_authtok_get.
I would also point out that pam_krb5 is already position dependent in
regards to pam_authtok_get. If you stack the current pam_krb5 above
pam_authtok_get it will always return failure. My point being that
someone configuring PAM auth stacks must know what they are doing in
regards to the ordering of the PAM modules.
> > 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?
>
> I would not try and change the PIN. It could also be the PIN needs
> to be entered on a PIN PAD reader, so the PIN never enters the computer.
>
> PINs don't expire, but can be turned off if to many incorrect guesses in a
> row,
> In that case the smart card administrator needs to reset the PIN.
That makes sense. Note that there are warning prompts issued if the
token returns errors when C_login is tried with incorrect PINs :
if (tip->flags & CKF_USER_PIN_LOCKED)
(void) strlcat(prompt, gettext(" (Warning: PIN locked)"), prompt_len);
else if (tip->flags & CKF_USER_PIN_FINAL_TRY)
(void) strlcat(prompt, gettext(" (Warning: PIN final try)"),
prompt_len);
else if (tip->flags & CKF_USER_PIN_COUNT_LOW)
(void) strlcat(prompt, gettext(" (Warning: PIN count low)"),
prompt_len);
--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA
