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? 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.) > > > 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. > >> 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" > > 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. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
