On Thu, Oct 22, 2009 at 03:38:29PM -0500, Douglas E. Engert wrote: > > > Darren J Moffat wrote: > > Wyllys Ingersoll wrote: > >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > >> This information is Copyright 2009 Sun Microsystems > >> 1. Introduction > >> 1.1. Project/Component Working Name: > >> pam_krb5 PKINIT support > >> 1.2. Name of Document Author/Supplier: > >> Author: Will Fiveash > >> 1.3 Date of This Document: > >> 22 October, 2009 > >> 4. Technical Description > >> > >> pam_krb5 PKINIT support > >> -------------------------------------- > >> > >> Recently support for public key based initial Kerberos credential > >> acquisition or PKINIT was added to Solaris Kerberos (see PSARC 2008/631). > >> What I propose now is modifying pam_krb5 in the following way to take > >> advantage of this PKINIT support and essentially allow a user to use a > >> smartcard or other form of pubic/private key to acquire their Kerberos > >> credential without using their long term Kerberos password. > >> > >> In order to avoid misleading prompting by pam_authtok_get (which assumes > >> a password must be prompted for) pam_krb5 would be modified to do its > >> own prompting when it determines that the PAM_USER and PAM_AUTHTOK are > >> not available which indicates it is above pam_authtok_get in the auth > >> stack. pam_krb5 would assume at this point that PKINIT is to be used to > >> acquire the user's Kerberos credential. If PKINIT fails to acquire a > >> Kerberos credential an error would be returned. > > > > The concept seems reasonable but what will the prompts look like ? > > So you are going to control if PKINIT is to be used based on the > order of the PAM stack?
Yes. If it is above the pam_authtok_get module pam_krb5 will try PKINIT. If it is below it will try a password based preauth. > I could see situations where some users use PKINIT and some use users > like root use a password. (Or maybe root requires the card, but not > the users.) Unfortunately root at this point in OpenSolaris is not handled differently in the PAM login auth stack. This is an separate issue from this enhancement to pam_krb5. > > What if PAM_USER is setup but PAM_AUTHTOK is not (which is very likely > > since PAM_USER is often set by the application before pam_authenticate() is > > called) ? > > What will be in PAM_AUTHTOK when pam_sm_authenticate() from pam_krb5 > > returns ? It should probably not be the PIN passed to a C_Login() for > > PKCS#11. > > Keep in mind: card readers with pin pads may be used. In that case > there is no password to passed into C_Login! You have to let the lower level > PKCS#11 routines produce the prompt, using callbacks via pam conv. That is the plan. This is also why pam_krb5 when doing PKINIT should be stacked above pam_authtok_get to avoid pam_authtok_get's prompting for a password inappropriately. > >> Note that if pam_krb is stacked below pam_authtok_get it would function > >> as it currently does which is to get the user's Kerberos credential > >> using their long term Kerberos password. > > > That seems reasonable. > > No! With Russ's pam_krb5 if a null password is passed to pam_krb5, and > try_pkinit if a card is present then it will try pkinit. In that case the > prompt for a password is pased back via the pam_conv routines and callbacks. > With OpenSC for example the prompt will have something like Enter PIN for > (card label). > (I don't have a pin-pad reader, to test with, but this method should work > with it too.) The user just has to have the card in th reader before > hitting enter for the user prompt. Russ's pam_krb5 also works with > the xscreensaver and dtlogin. > > So an pam_authtok prompt could be something like: > "Insert smartcard then enter user and enter null password" Be aware that the current OpenSolaris PAM framework typically relies on the pam_authtok_get module to prompt for the password. OpenSolaris pam_krb5 must follow this module currently as it relies on it for the password. This is the reason I'm suggesting that if pam_krb5 is stacked above pam_authtok_get it would assume it should try PKINT only. Given this I don't seen the need for another config parameter like try_pkinit. > > 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. > > See Russ's pam_krb5.5 man page. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
