Will Fiveash wrote:
> 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
OK, sorry, but someone said above:
"* If the KDC and krb5.conf(5) are configured for PKINIT and there's no
present user (PAM_USER)"
Maybe that was not you.
> 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?
I would expect that if pam_krb5 found one of the above, it would
set PAM_AUTHTOK to null, and let a lower level pam module prompt for its
own 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.
The way it works on Solaris 10, the user has to hit a blank for the password.
This is also a hack,but thats the best one can do with pam_authtok_get.
This works today: (MIT krb5-1.7, OpenSC-0.11.11 and pam_krb5-1.3.15):
dtlogin auth requisite pam_authtok_get.so.1
dtlogin auth required pam_dhkeys.so.1
dtlogin auth required pam_unix_cred.so.1
dtlogin auth optional /krb5m/lib/security/pam_krb5.so debug
try_pkinit try_first_pass minimum_uid=100
dtlogin auth required /krb5m/lib/security/pam_afs_session.so debug
# allows password login (for root)
dtlogin auth optional pam_unix_auth.so.1
#
# For testing with /krb5m need account and session too:
dtlogin account requisite pam_roles.so.1
dtlogin account required pam_unix_account.so.1
dtlogin account optional /krb5m/lib/security/pam_krb5.so debug minimum_uid=100
dtlogin session required pam_unix_session.so.1
dtlogin session optional /krb5m/lib/security/pam_krb5.so debug minimum_uid=100
xscreensaver auth requisite pam_authtok_get.so.1 debug
xscreensaver auth optional /krb5m/lib/security/pam_krb5.so
try_first_pass try_pkinit minimum_uid=100 debug
xscreensaver auth required /krb5m/lib/security/pam_afs_session.so
# allows unlock with local password
xscreensaver auth optional pam_unix_auth.so.1
(There is a memory problem with xscreensaver that I have a circumvention
for, buts thats another problem.)
>
> 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.
The is a timing issue here with screen unlock and inserting the
smartcard. A user would normally walk up to a blank screen or one with
a screen saver running and move the mouse, or hit a key to see what
to do next. As soon as this happens, pam_start is called, and
and if pam_krb5 is first and tries to see if a token is present,
the card may not be there.
The user would expect to see what the screen saver wanted, before
inserting a card. Today it tells him who is logged in and to enter a password.
The user would then insert the card, and respond to the screen prompt.
The trick is to let the user see what to do next, give him a chance
to insert the card, then proceed with the test for the presence of a card.
>
> 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);
That looks good.
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
