From wyllys@borg.sfbay.sun.com Thu Oct 22 06:04:14 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MD4ExC010770 for ; Thu, 22 Oct 2009 06:04:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9MD4B4U051194 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.Com>; Thu, 22 Oct 2009 07:04:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRX00M0X2Z0BF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 22 Oct 2009 06:04:12 -0700 (PDT) Received: from borg.sfbay ([10.5.240.20]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRX00L1W2YZAY50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Thu, 22 Oct 2009 06:04:11 -0700 (PDT) Received: from borg.sfbay (localhost [127.0.0.1]) by borg.sfbay (8.14.3+Sun/8.14.3) with ESMTP id n9MCu8Av017627; Thu, 22 Oct 2009 05:56:08 -0700 (PDT) Received: (from wyllys@localhost) by borg.sfbay (8.14.3+Sun/8.14.3/Submit) id n9MCu8fQ017623; Thu, 22 Oct 2009 05:56:08 -0700 (PDT) Date: Thu, 22 Oct 2009 05:56:08 -0700 (PDT) From: Wyllys Ingersoll Subject: pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: PSARC-ext@sun.com Cc: kerberos-discuss@opensolaris.org Message-id: <200910221256.n9MCu8fQ017623@borg.sfbay> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1648 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. 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. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Thu Oct 22 09:41:07 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MGf7Ij014895 for ; Thu, 22 Oct 2009 09:41:07 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9MGf3eb004010 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Oct 2009 09:41:07 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRX00A2HD0H6V00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Oct 2009 09:41:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRX004L0D0GFP30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Oct 2009 09:41:05 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9MGf3Oa022939 for ; Thu, 22 Oct 2009 16:41:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRX00900CPQLV00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 22 Oct 2009 17:40:48 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRX0032YCZZQ8D0@fe-emea-09.sun.com>; Thu, 22 Oct 2009 17:40:47 +0100 (BST) Date: Thu, 22 Oct 2009 17:40:47 +0100 From: Darren J Moffat Subject: Re: pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200910221256.n9MCu8fQ017623@borg.sfbay> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AE08B0F.5090508@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2109 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 ? 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. > 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. 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. -- Darren J Moffat From deengert@anl.gov Thu Oct 22 13:38:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MKcaeN022124 for ; Thu, 22 Oct 2009 13:38:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9MKcZZb012358; Thu, 22 Oct 2009 14:38:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRX00H0FO092X00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Oct 2009 13:38:33 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRX00B7QO08CI50@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Oct 2009 13:38:32 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9MKaBYa026268; Thu, 22 Oct 2009 20:38:32 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-1608441; Thu, 22 Oct 2009 20:38:30 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-16324655; Thu, 22 Oct 2009 20:38:29 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay4i.sun.com with ESMTP id BT-MMP-6205899; Thu, 22 Oct 2009 20:38:29 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 528CE3F; Thu, 22 Oct 2009 15:38:29 -0500 (CDT) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 363F44C; Thu, 22 Oct 2009 15:38:29 -0500 (CDT) Date: Thu, 22 Oct 2009 15:38:29 -0500 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE08B0F.5090508@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Russ Allbery Message-id: <4AE0C2C5.9080703@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.096sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 3485 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 Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From William.Fiveash@sun.com Thu Oct 22 15:17:54 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MMHsDp024451 for ; Thu, 22 Oct 2009 15:17:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9MM2rZQ000254; Thu, 22 Oct 2009 16:02:55 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRX00907RWTTB00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Oct 2009 15:02:53 -0700 (PDT) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRX00MNCRWT85C0@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Oct 2009 15:02:53 -0700 (PDT) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9MLtIa6006044; Thu, 22 Oct 2009 16:55:18 -0500 (CDT) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9MLtHU8006043; Thu, 22 Oct 2009 16:55:17 -0500 (CDT) Date: Thu, 22 Oct 2009 16:55:17 -0500 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE08B0F.5090508@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091022215517.GA4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 3283 On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren 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 ? The prompts will come from either the pkinit preauth plugin or openssl/libcrypto which pkinit calls. The specific prompt string will depend on what kind of pubkey auth is being done. See the PKINIT-specific Options section in krb5.conf man for the specifics of the types of pubkey supported by the pkinit plugin. > 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) ? In that case pam_krb5 would only do PKINIT since the assumption is if PAM_AUTHTOK is not set then pam_krb5 is stacked above pam_authtok_get. > 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. If the prompt type set by pkinit is KRB5_PROMPT_TYPE_PREAUTH which it typically is then PAM_AUTHTOK will not be set. Note that there is logic in the prompter bridge function like: if (prompt_type[i] == KRB5_PROMPT_TYPE_PASSWORD) { (void)pam_set_item(pamh, PAM_AUTHTOK, (void *)ret_respp[i].resp); } in case the underlying libkrb actually prompts for the user's password. The pkinit plugin will never do this however. > > 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. > > 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'll work on that and send it as a reply. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@Sun.COM Thu Oct 22 15:53:59 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9MMrwUP025357 for ; Thu, 22 Oct 2009 15:53:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9MMcu18024599; Thu, 22 Oct 2009 16:38:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRX00905TKQVV00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Oct 2009 15:38:50 -0700 (PDT) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRX002TBTKQZZ60@nwk-avmta-1.sfbay.Sun.COM>; Thu, 22 Oct 2009 15:38:50 -0700 (PDT) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9MMGHLo006167; Thu, 22 Oct 2009 17:16:17 -0500 (CDT) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9MMGHRL006166; Thu, 22 Oct 2009 17:16:17 -0500 (CDT) Date: Thu, 22 Oct 2009 17:16:17 -0500 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE0C2C5.9080703@anl.gov> To: "Douglas E. Engert" Cc: Darren J Moffat , PSARC-ext@Sun.COM, Russ Allbery , kerberos-discuss@opensolaris.org Mail-followup-to: "Douglas E. Engert" , Darren J Moffat , PSARC-ext@Sun.COM, Russ Allbery , kerberos-discuss@opensolaris.org Message-id: <20091022221617.GB4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 4570 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 From hotz@jpl.nasa.gov Thu Oct 22 20:37:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9N3b1V6029933 for ; Thu, 22 Oct 2009 20:37:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9N3atxj021084; Fri, 23 Oct 2009 04:36:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRY00B0H7DLGY00@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Oct 2009 20:36:57 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRY00AAG7DKAQ20@nwk-avmta-2.sfbay.sun.com>; Thu, 22 Oct 2009 20:36:56 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9N3TbdC005246; Fri, 23 Oct 2009 03:36:56 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay13i.sun.com with ESMTP id BT-MMP-4798727; Fri, 23 Oct 2009 03:36:56 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-22564226; Fri, 23 Oct 2009 03:36:55 +0000 (Z) Received: from mail.jpl.nasa.gov ([128.149.139.105] [128.149.139.105]) by relay1i.sun.com with ESMTP id BT-MMP-17146614; Fri, 23 Oct 2009 03:36:55 +0000 (Z) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9N3aB4o026811 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Thu, 22 Oct 2009 20:36:11 -0700 Received: from [192.168.2.2] (128.149.137.114) by ums-smtp.jpl.nasa.gov (128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 22 Oct 2009 20:36:11 -0700 Date: Thu, 22 Oct 2009 23:36:03 -0400 From: "Henry B. Hotz" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091022221617.GB4337@sun.com> To: Will Fiveash Cc: "Douglas E. Engert" , "PSARC-ext@Sun.COM" , Russ Allbery , "kerberos-discuss@opensolaris.org" , Darren J Moffat Message-id: <73EC40CF-2FDA-4FC4-AB3F-3084C53E2B5E@jpl.nasa.gov> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> Status: RO Content-Length: 870 So if some users use K5 password and others use PKINIT you would put pam_krb5 in twice? How would you e.g. require PKINIT for root but not users in general? On Oct 22, 2009, at 6:16 PM, Will Fiveash wrote: > 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. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From deengert@anl.gov Fri Oct 23 08:22:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9NFMgEk021917 for ; Fri, 23 Oct 2009 08:22:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9NFMf6h027852; Fri, 23 Oct 2009 08:22:41 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRZ00D1T41TY800@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Oct 2009 08:22:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRZ002UV41QZIA0@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Oct 2009 08:22:39 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9NFAPsp017226; Fri, 23 Oct 2009 15:22:38 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay42i.sun.com with ESMTP id BT-MMP-1921649; Fri, 23 Oct 2009 15:22:03 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-17623217; Fri, 23 Oct 2009 15:22:02 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay4i.sun.com with ESMTP id BT-MMP-45083541; Fri, 23 Oct 2009 15:22:02 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 6F6E668; Fri, 23 Oct 2009 10:22:02 -0500 (CDT) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 5070473; Fri, 23 Oct 2009 10:22:02 -0500 (CDT) Date: Fri, 23 Oct 2009 10:22:02 -0500 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091022221617.GB4337@sun.com> To: "Douglas E. Engert" , Darren J Moffat , PSARC-ext@sun.com, Russ Allbery , kerberos-discuss@opensolaris.org Message-id: <4AE1CA1A.9040509@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.169sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 5036 Will Fiveash wrote: > 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. Login is easy. Screen unlock is much harder. Make sure you plan will work with the actions the user must preform and in what order they are preformed and what is happening internally. User walks up to a screen saver on screen and moves the mouse or hit a key to see if its locked or not. screen saver calls PAM with logined in username. In current configurations, the first thing the user see is enter password. The user may or may have not inserted a smartcard yet. If you skip pam_authtok_get and use pam_krb5 first you may have started the process to see if a card is present. > >>>> 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. Yea, and pam_authtok_get can accept a blank. (Solaris 10 can at least.) This blank is then passed along to other pam modules, The pam_krb5 can use it to indicate if it should try a password or attempt PKINIT. For testing on Solaris 10, I have used pam.conf sections like (The pam_smartcard.so.1 never worked so I commented it out): #dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 debug dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_cred.so.1 debug #dtlogin auth optional pam_krb5.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 dtlogin auth optional pam_unix_auth.so.1 debug # # xscreensaver used by gnome or CDE # xscreensaver auth requisite pam_authtok_get.so.1 #xscreensaver auth required pam_dhkeys.so.1 #xscreensaver auth optional pam_krb5.so.1 # use next with /krb5m. Above 1 with native xscreensaver auth optional /krb5m/lib/security/pam_krb5.so try_pkinit try_first_pass minimum_uid=100 #xscreensaver auth optional /krb5m/lib/security/pam_krb5.so try_pkinit minimum_uid=100 # xscreensaver auth required /krb5m/lib/security/pam_afs_session.so nopag # allows unlock with local password xscreensaver auth optional pam_unix_auth.so.1 # Thus is a password is null, pam_krb5 tries pkinit. If its not it tries norlam Kerberos password, and if root was trying to login, Russ's minimum_uid=100 does nothing with root, and pam_unix_auth will. The really problem is with the PAM framework. It does not give the user any choice as to how the user would like to try authenticaiton. It should be asking as the first prompt (a list or menu) like to use a smartcard for local or PKINIT login, local password Kerberos password, OTP password, (or whatever else is available maybe fingerprint of face recognition?) Pam would then route to the appropriate modules, rather then starting a sequence of optional/required modules that may treat this as a failed login attempt,which can lead to locked accounts. At least pam_authtok_get should have a prompt option to tell the user what to do next. > 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. You might be able able to drop the try_pkinit but only if the some other method is available to tell the differenrce between a smartcard and some other crypto device supported below pkcs#11. > >>> 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 Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Nicolas.Williams@sun.com Fri Oct 23 09:14:24 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9NGEOja023254 for ; Fri, 23 Oct 2009 09:14:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9NGEMSC012271; Fri, 23 Oct 2009 17:14:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRZ00G016FYWW00@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Oct 2009 09:14:22 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRZ00FOX6FXL710@nwk-avmta-2.sfbay.sun.com>; Fri, 23 Oct 2009 09:14:21 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9NFlr0a006799; Fri, 23 Oct 2009 10:47:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9NFlqbd006798; Fri, 23 Oct 2009 10:47:52 -0500 (CDT) Date: Fri, 23 Oct 2009 10:47:52 -0500 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE1CA1A.9040509@anl.gov> To: "Douglas E. Engert" Cc: Darren J Moffat , PSARC-ext@sun.com, Russ Allbery , kerberos-discuss@opensolaris.org Message-id: <20091023154752.GM892@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> <4AE1CA1A.9040509@anl.gov> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 4951 On Fri, Oct 23, 2009 at 10:22:02AM -0500, Douglas E. Engert wrote: > Will Fiveash wrote: > >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. > > Login is easy. Screen unlock is much harder. Make sure you plan will > work with the actions the user must preform and in what order they are > preformed and what is happening internally. > > User walks up to a screen saver on screen and moves the mouse or hit a key > to see if its locked or not. > > screen saver calls PAM with logined in username. In current > configurations, the first thing the user see is enter password. > > The user may or may have not inserted a smartcard yet. If you skip > pam_authtok_get and use pam_krb5 first you may have started the process to > see if a card is present. If you wanted the PAM_USER to be derived from the smartcard, then the smae sort of issue applies to login as to screen unlock. There are thorny issues[*] here, but I think Will's approach is a reasonable one for now. [*] If you think of PAM as being a system for negotiating how to authenticate a user, and you also think of Kerberos pre-auth in the same way, then what we have here is a two layer negotiation, which, like all two-layer negotiations, tends to have unsatisfactory results and/or odd corner cases. > >Be aware that the current OpenSolaris PAM framework typically relies on > >the pam_authtok_get module to prompt for the password. > > Yea, and pam_authtok_get can accept a blank. (Solaris 10 can at least.) > This blank is then passed along to other pam modules, The pam_krb5 > can use it to indicate if it should try a password or attempt PKINIT. How will the user know this? If the password prompt came from pam_krb5(5) itself (but it doesn't) then the prompt could say " (or plugin your smartcard and enter an empty password)"; pam_authtok_get(5) cannot possibly know to use such a prompt unless you tell it to, via a module option, say. The pam_authtok_get(5) concept was part of a project to: a) remove redundant code from modules, b) get rid of the try/use_first_pass options, c) harmonize prompting behavior. IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we have a [consolidation-private] pam_get_user() function, which IMO should also be Public. (b) was a good thing, and so was (c), but (c) is getting upset by modules that can prompt for PINs, or which can derive PAM_USER from smartcards and/or biometrics. Solving the multi-layer "negotiation" and other framework-level issues is out of scope for this case though. I think Will's proposal will work well enough for now. > The really problem is with the PAM framework. It does not give the user any > choice as to how the user would like to try authenticaiton. It should be > asking as the first prompt (a list or menu) like to use a smartcard for > local or PKINIT login, local password Kerberos password, OTP password, > (or whatever else is available maybe fingerprint of face recognition?) > Pam would then route to the appropriate modules, rather then starting > a sequence of optional/required modules that may treat this as a failed > login attempt,which can lead to locked accounts. > > At least pam_authtok_get should have a prompt option to tell the user what > to do next. I agree with your comment about the framework being the problem. The framework doesn't deal well with the two-layer negotiation problem, and it doesn't deal at all with asynchrony (e.g., plugin a smartcard and have the current user/password prompt go away or change into a PIN prompt). I'm waiting for a code review from Gary to complete PSARC/2005/275. One possible way to solve the multi-layer negotiation issue would be to have pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth sheme being tried. > >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. > > You might be able able to drop the try_pkinit but only if the some other > method is available to tell the differenrce between a smartcard and some > other crypto device supported below pkcs#11. We've talked about this as well, and I think that too is out of scope here. But briefly, IMO there should be a way to select tokens for C_Login() in a way that takes PAM context (e.g., PAM_TTY) into consideration, so that only tokens that could be associated with a seat are used. But we don't need that urgently because for SunRay the seat is already taken into account via other methods, and for VTs we don't care very much about this. Nico -- From deengert@anl.gov Fri Oct 23 12:24:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9NJOs4B027926 for ; Fri, 23 Oct 2009 12:24:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9NJOqsV012036; Fri, 23 Oct 2009 12:24:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRZ00G01F9EAX00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Oct 2009 12:24:50 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRZ00AVTF9EDB40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 23 Oct 2009 12:24:50 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9NJGo2o015903; Fri, 23 Oct 2009 19:24:49 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay13i.sun.com with ESMTP id BT-MMP-4859447; Fri, 23 Oct 2009 19:24:49 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-409202; Fri, 23 Oct 2009 19:24:49 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay1i.sun.com with ESMTP id BT-MMP-12819798; Fri, 23 Oct 2009 19:24:49 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 23A214E; Fri, 23 Oct 2009 14:24:49 -0500 (CDT) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 1556D4B; Fri, 23 Oct 2009 14:24:49 -0500 (CDT) Date: Fri, 23 Oct 2009 14:24:48 -0500 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091023154752.GM892@Sun.COM> To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com, Russ Allbery , kerberos-discuss@opensolaris.org Message-id: <4AE20300.6030107@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> <4AE1CA1A.9040509@anl.gov> <20091023154752.GM892@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 3599 Nicolas Williams wrote: > > > IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we > have a [consolidation-private] pam_get_user() function, which IMO should > also be Public. (b) was a good thing, and so was (c), but (c) is > getting upset by modules that can prompt for PINs, or which can derive > PAM_USER from smartcards and/or biometrics. PLEASE keep in mind that a PIN may be entered via a smartcard reader, and will never be seen via the host. So a prompt for a PIN may not have any input, just instructions. So one has to stop thinking about PAM prompting. See in the PKINIT code and PKCS#11 CKF_PROTECTED_AUTHENTICATION_PATH in pkinit_crypto_openssl.c But even here it looks like it does not write the prompt as instructions, but if it is requesting the PIN via the prompter. (But I need to get a reader with a pin pad to test this out.) > > Solving the multi-layer "negotiation" and other framework-level issues > is out of scope for this case though. I think Will's proposal will work > well enough for now. > >> The really problem is with the PAM framework. It does not give the user any >> choice as to how the user would like to try authenticaiton. It should be >> asking as the first prompt (a list or menu) like to use a smartcard for >> local or PKINIT login, local password Kerberos password, OTP password, >> (or whatever else is available maybe fingerprint of face recognition?) >> Pam would then route to the appropriate modules, rather then starting >> a sequence of optional/required modules that may treat this as a failed >> login attempt,which can lead to locked accounts. >> >> At least pam_authtok_get should have a prompt option to tell the user what >> to do next. > > I agree with your comment about the framework being the problem. The > framework doesn't deal well with the two-layer negotiation problem, and > it doesn't deal at all with asynchrony (e.g., plugin a smartcard and > have the current user/password prompt go away or change into a PIN > prompt). > > I'm waiting for a code review from Gary to complete PSARC/2005/275. One > possible way to solve the multi-layer negotiation issue would be to have > pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from > PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth > sheme being tried. Another way might be to have prompt= parameter to pam_authtok_get, set by the sysadmin. > >>> 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. >> You might be able able to drop the try_pkinit but only if the some other >> method is available to tell the differenrce between a smartcard and some >> other crypto device supported below pkcs#11. > > We've talked about this as well, and I think that too is out of scope > here. But briefly, IMO there should be a way to select tokens for > C_Login() in a way that takes PAM context (e.g., PAM_TTY) into > consideration, so that only tokens that could be associated with a seat > are used. Yes that is an issue on other OSes too. > But we don't need that urgently because for SunRay the seat > is already taken into account via other methods, and for VTs we don't > care very much about this. > > Nico -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Nicolas.Williams@Sun.COM Fri Oct 23 12:52:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9NJqew8028297 for ; Fri, 23 Oct 2009 12:52:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9NJqb2u003927; Fri, 23 Oct 2009 20:52:39 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRZ00F09GJQSS00@brm-avmta-1.central.sun.com>; Fri, 23 Oct 2009 13:52:38 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRZ0056TGJPJP70@brm-avmta-1.central.sun.com>; Fri, 23 Oct 2009 13:52:37 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9NJQD9T007042; Fri, 23 Oct 2009 14:26:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9NJQCLK007041; Fri, 23 Oct 2009 14:26:12 -0500 (CDT) Date: Fri, 23 Oct 2009 14:26:12 -0500 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE20300.6030107@anl.gov> To: "Douglas E. Engert" Cc: Darren J Moffat , PSARC-ext@Sun.COM, Russ Allbery , kerberos-discuss@opensolaris.org Message-id: <20091023192612.GA892@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> <4AE1CA1A.9040509@anl.gov> <20091023154752.GM892@Sun.COM> <4AE20300.6030107@anl.gov> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1940 On Fri, Oct 23, 2009 at 02:24:48PM -0500, Douglas E. Engert wrote: > Nicolas Williams wrote: > >IMO pam_authtok_get(5) should be pam_authtok_get(3PAM), kinda like we > >have a [consolidation-private] pam_get_user() function, which IMO should > >also be Public. (b) was a good thing, and so was (c), but (c) is > >getting upset by modules that can prompt for PINs, or which can derive > >PAM_USER from smartcards and/or biometrics. > > PLEASE keep in mind that a PIN may be entered via a smartcard reader, > and will never be seen via the host. So a prompt for a PIN may not > have any input, just instructions. So one has to stop thinking about > PAM prompting. Will's code does not issue prompts for PIN independently of the Kerberos code. If the PKINIT pre-auth plugin prompts for a PIN, then pam_krb5 will also, else it won't. Basically pam_krb5 will let krb5_get_init_creds*() to the work. That's not quite how it is today in S10 and OpenSolaris, because of the need to use PAM_AUTHTOK and because password aging prompting needs to not happen in pam_authenticate(3PAM). The password-based pre-auth will continue to work that way. > >I'm waiting for a code review from Gary to complete PSARC/2005/275. One > >possible way to solve the multi-layer negotiation issue would be to have > >pam_krb5(5) to be stacked high and call pam_eval(3PAM) (from > >PSARC/2005/275) to evaluate a policy that corresponds to a pre-auth > >sheme being tried. > > Another way might be to have prompt= parameter to pam_authtok_get, > set by the sysadmin. That's not really satisfactory. > >We've talked about this as well, and I think that too is out of scope > >here. But briefly, IMO there should be a way to select tokens for > >C_Login() in a way that takes PAM context (e.g., PAM_TTY) into > >consideration, so that only tokens that could be associated with a seat > >are used. > > Yes that is an issue on other OSes too. I'm sure it is. From William.Fiveash@sun.com Mon Oct 26 18:01:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9R11kgT013502 for ; Mon, 26 Oct 2009 18:01:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9R11iTw007851; Mon, 26 Oct 2009 19:01:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS500901EUVN200@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Oct 2009 18:01:43 -0700 (PDT) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS500MIIEUVST90@nwk-avmta-2.sfbay.sun.com>; Mon, 26 Oct 2009 18:01:43 -0700 (PDT) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9R0Vfoh016761; Mon, 26 Oct 2009 19:31:41 -0500 (CDT) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9R0Vevi016760; Mon, 26 Oct 2009 19:31:40 -0500 (CDT) Date: Mon, 26 Oct 2009 19:31:40 -0500 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <73EC40CF-2FDA-4FC4-AB3F-3084C53E2B5E@jpl.nasa.gov> To: "Henry B. Hotz" Cc: Will Fiveash , "Douglas E. Engert" , "PSARC-ext@Sun.COM" , Russ Allbery , "kerberos-discuss@opensolaris.org" , Darren J Moffat Mail-followup-to: "Henry B. Hotz" , "Douglas E. Engert" , "PSARC-ext@Sun.COM" , Russ Allbery , "kerberos-discuss@opensolaris.org" , Darren J Moffat Message-id: <20091027003140.GC4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <4AE0C2C5.9080703@anl.gov> <20091022221617.GB4337@sun.com> <73EC40CF-2FDA-4FC4-AB3F-3084C53E2B5E@jpl.nasa.gov> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 984 On Thu, Oct 22, 2009 at 11:36:03PM -0400, Henry B. Hotz wrote: > So if some users use K5 password and others use PKINIT you would put > pam_krb5 in twice? Yes. > How would you e.g. require PKINIT for root but not users in general? That can not be done with the current Solaris PAM implementation and will not be addressed by this pam_krb5 enhancement. > On Oct 22, 2009, at 6:16 PM, Will Fiveash wrote: > > > 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. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Tue Oct 27 14:54:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9RLscEg017533 for ; Tue, 27 Oct 2009 14:54:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9RLsNWa005396; Wed, 28 Oct 2009 05:54:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS700G010UYSX00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 14:54:34 -0700 (PDT) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS700LQK0UXOF80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 14:54:34 -0700 (PDT) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9RLl0Mh022969; Tue, 27 Oct 2009 16:47:00 -0500 (CDT) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9RLl0lA022968; Tue, 27 Oct 2009 16:47:00 -0500 (CDT) Date: Tue, 27 Oct 2009 16:47:00 -0500 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE08B0F.5090508@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091027214700.GD4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 813 On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat wrote: > > The concept seems reasonable but what will the prompts look like ? I've been doing some testing and I have a question in regards to the pkinit preauth plugin, libpkcs11 and the resulting prompting behavior. What I'm seeing is if the system is configured to try PKINIT in addition to password timestamp, a user will be prompted for a PIN like so: Sun Metaslot PIN: regardless of whether the user has a cert/key token in their PKCS11 objectstore or not. This happens with both kinit and pam_krb5. This doesn't seem reasonable to prompt a user for a PIN in the case a token containing a cert/key does not exist. Thoughts? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Tue Oct 27 15:44:55 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9RMisK7019057 for ; Tue, 27 Oct 2009 15:44:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9RMimE2001239; Wed, 28 Oct 2009 06:44:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS70040336P6R00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Oct 2009 15:44:49 -0700 (PDT) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS7002FN36P5V40@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Oct 2009 15:44:49 -0700 (PDT) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9RMbF6e023568; Tue, 27 Oct 2009 17:37:15 -0500 (CDT) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9RMbFMq023567; Tue, 27 Oct 2009 17:37:15 -0500 (CDT) Date: Tue, 27 Oct 2009 17:37:15 -0500 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091027214700.GD4337@sun.com> To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20091027223715.GE4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091027214700.GD4337@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1770 On Tue, Oct 27, 2009 at 04:47:00PM -0500, Will Fiveash wrote: > On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat wrote: > > > > The concept seems reasonable but what will the prompts look like ? > > I've been doing some testing and I have a question in regards to the > pkinit preauth plugin, libpkcs11 and the resulting prompting behavior. > What I'm seeing is if the system is configured to try PKINIT in addition > to password timestamp, a user will be prompted for a PIN like so: > > Sun Metaslot PIN: > > regardless of whether the user has a cert/key token in their PKCS11 > objectstore or not. This happens with both kinit and pam_krb5. This > doesn't seem reasonable to prompt a user for a PIN in the case a token > containing a cert/key does not exist. Thoughts? More info: it appears that in pkinit_open_session() there is code calling C_Initialize, C_GetSlotList, C_OpenSession, C_GetTokenInfo. C_GetTokenInfo appears to set CKF_LOGIN_REQUIRED in the output object's flags. This in turn causes the PIN prompt for a user that does not have any cert token object in their softtoken objstore. I also see this code in lib/pkcs11/pkcs11_softtoken/common/softSlotToken.c:C_GetTokenInfo() pInfo->flags = SOFT_TOKEN_FLAGS | token_flag; where SOFT_TOKEN_FLAGS is: #define SOFT_TOKEN_FLAGS CKF_RNG|\ CKF_USER_PIN_INITIALIZED|\ CKF_LOGIN_REQUIRED|\ ^^^^^^^^^^^^^^^^^^ CKF_RESTORE_KEY_NOT_NEEDED|\ CKF_DUAL_CRYPTO_OPERATIONS|\ CKF_TOKEN_INITIALIZED Is this a Solaris PKCS11 bug? Note, the user did a pktool setpin earlier. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Darren.Moffat@sun.com Wed Oct 28 02:46:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9S9ks7g010721 for ; Wed, 28 Oct 2009 02:46:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9S9krQT021112 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Oct 2009 02:46:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS700009XU5ZB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 02:46:53 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS700L3YXU48OD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 02:46:53 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9S9kpIU006301 for ; Wed, 28 Oct 2009 09:46:51 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS700B00VM9W800@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 09:46:44 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS7009N2XTOJOB0@fe-emea-10.sun.com>; Wed, 28 Oct 2009 09:46:36 +0000 (GMT) Date: Wed, 28 Oct 2009 09:46:35 +0000 From: Darren J Moffat Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091027214700.GD4337@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AE812FB.3010501@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091027214700.GD4337@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1182 Will Fiveash wrote: > On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat wrote: >> The concept seems reasonable but what will the prompts look like ? > > I've been doing some testing and I have a question in regards to the > pkinit preauth plugin, libpkcs11 and the resulting prompting behavior. > What I'm seeing is if the system is configured to try PKINIT in addition > to password timestamp, a user will be prompted for a PIN like so: > > Sun Metaslot PIN: > > regardless of whether the user has a cert/key token in their PKCS11 > objectstore or not. This happens with both kinit and pam_krb5. This > doesn't seem reasonable to prompt a user for a PIN in the case a token > containing a cert/key does not exist. Thoughts? Sounds like an issue but not one that this cases introduced, especially since it happens with kinit already. So while I agree it isn't nice I don't think this case should be tasked with fixing it given that is already the behaviour we have and that pam_krb5 isn't in the default stack for the initial login programs (ie gdm and /bin/login). So lets take this offline from this case and see what we can do about it. -- Darren J Moffat From Darren.Moffat@sun.com Wed Oct 28 02:52:59 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9S9qv4A010756 for ; Wed, 28 Oct 2009 02:52:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9S9qoU1020659 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Oct 2009 17:52:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS70010JY46S000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 02:52:54 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS700LSRY4491C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 02:52:53 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9S9qpOR020556 for ; Wed, 28 Oct 2009 09:52:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS700000XG5ZD00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Oct 2009 09:52:32 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS70091VY39JOC0@fe-emea-10.sun.com>; Wed, 28 Oct 2009 09:52:22 +0000 (GMT) Date: Wed, 28 Oct 2009 09:52:21 +0000 From: Darren J Moffat Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091027223715.GE4337@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AE81455.9090707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091027214700.GD4337@sun.com> <20091027223715.GE4337@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2171 Will Fiveash wrote: > On Tue, Oct 27, 2009 at 04:47:00PM -0500, Will Fiveash wrote: >> On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat wrote: >>> The concept seems reasonable but what will the prompts look like ? >> I've been doing some testing and I have a question in regards to the >> pkinit preauth plugin, libpkcs11 and the resulting prompting behavior. >> What I'm seeing is if the system is configured to try PKINIT in addition >> to password timestamp, a user will be prompted for a PIN like so: >> >> Sun Metaslot PIN: >> >> regardless of whether the user has a cert/key token in their PKCS11 >> objectstore or not. This happens with both kinit and pam_krb5. This >> doesn't seem reasonable to prompt a user for a PIN in the case a token >> containing a cert/key does not exist. Thoughts? > > More info: it appears that in pkinit_open_session() there is code > calling C_Initialize, C_GetSlotList, C_OpenSession, C_GetTokenInfo. > C_GetTokenInfo appears to set CKF_LOGIN_REQUIRED in the output object's > flags. This in turn causes the PIN prompt for a user that does not have > any cert token object in their softtoken objstore. I also see this code > in lib/pkcs11/pkcs11_softtoken/common/softSlotToken.c:C_GetTokenInfo() > > pInfo->flags = SOFT_TOKEN_FLAGS | token_flag; > > where SOFT_TOKEN_FLAGS is: > > #define SOFT_TOKEN_FLAGS CKF_RNG|\ > CKF_USER_PIN_INITIALIZED|\ > CKF_LOGIN_REQUIRED|\ > ^^^^^^^^^^^^^^^^^^ > CKF_RESTORE_KEY_NOT_NEEDED|\ > CKF_DUAL_CRYPTO_OPERATIONS|\ > CKF_TOKEN_INITIALIZED > > Is this a Solaris PKCS11 bug? Note, the user did a pktool setpin > earlier. It could be a bug, it sounds similar to 6721247 which I logged. What that flag means is you need to login to do some operations. Which is in fact true, you can't operate on private token objects unless you are logged in. This isn't something this case should try and fix though because there could be a big knock on impact from changing that. I'm going to discuss this with some others, including on the cryptoki alias. -- Darren J Moffat From William.Fiveash@Sun.com Thu Nov 5 12:16:33 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA5KGXNR022611 for ; Thu, 5 Nov 2009 12:16:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5KGUbj016037; Thu, 5 Nov 2009 12:16:32 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00J05KBJUS00@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 13:16:31 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00HX3KBIFY10@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 13:16:30 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA5K8uom022012; Thu, 05 Nov 2009 14:08:56 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA5K8u5J022011; Thu, 05 Nov 2009 14:08:56 -0600 (CST) Date: Thu, 05 Nov 2009 14:08:56 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091022215517.GA4337@sun.com> To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@Sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20091105200856.GF4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 6726 On Thu, Oct 22, 2009 at 04:55:17PM -0500, Will Fiveash wrote: > On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren 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 > > > 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. > > > > 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'll work on that and send it as a reply. While working out the various permutations of PAM auth stacks I've discovered that my fasttrack was not complete in regards to new interfaces. In order for the fall back to work properly from PKINIT to password based preauth, pam_krb5 will need a user configurable option to tell the first instance of pam_krb5 (doing PKINIT preauth) whether there will be a second instance of pam_krb5 stacked below pam_authtok_get that will try password preauth if PKINIT preauth fails. The idea is that if the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE if the fall back option is set to true (it would be false by default). Otherwise the first instance of pam_krb5 (PKINIT) would return failure. I believe there are two options in regards to the implementation of this "fall back" config parameter. One is a new pam_krb5 argument set in pam.conf like: dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_krb5.so.1 passwd_fallback dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_auth.so.1 The other implementation option is to add support for a pam_krb5 stanza in the krb5.conf [appdefaults] section which would be a bit more work. Also note that currently there are no support pam_krb5 config parameters in krb5.conf. Thoughts as to which implementation of password fall back is preferable? Here are the example auth stacks involving pam_krb5 doing PKINIT (these examples assume use of a passwd_fallback argument to pam_krb5): Example 1: Authenticate Users Through Kerberos PKINIT as First Choice The following is an excerpt of a sample pam.conf configuration file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication (using PKINIT) fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. Note, the user is prompted once for the PIN by pam_krb5. dtlogin auth required pam_unix_cred.so.1 dtlogin auth sufficient pam_krb5.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_auth.so.1 Example 2: Authenticate Users Through Kerberos PKINIT Only The following example allows authentication only to users that have Kerberos-based accounts requiring PKINIT preauth. dtlogin auth required pam_unix_cred.so.1 dtlogin auth binding pam_krb5.so.1 Example 3: Authenticate Users Through Kerberos PKINIT Optionally The following example allows users to acquire a Kerberos credential using PKINIT preauth if they have a Kerberos account. Whether pam_krb5 succeeds or fails the user must provide their Unix password in order to login. dtlogin auth required pam_unix_cred.so.1 dtlogin auth optional pam_krb5.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_unix_auth.so.1 Example 4: Authenticate Users Through Kerberos PKINIT as a requirement. The following example allows users to login if pam_krb5 is able to acquire a Kerberos credential via PKINT preauth and in addition must provide their Unix password to pam_unix_auth. dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_unix_auth.so.1 Example 5: Authenticate Users Through Kerberos PKINIT, fall back to password based krb auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT preauth or using password based preauth if PKINIT fails. If PKINIT succeeds the user will not be prompted for their password. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password preauth and will return success. If PKINIT fails the user will be prompted for their Kerberos password. dtlogin auth required pam_unix_cred.so.1 dtlogin auth sufficient pam_krb5.so.1 passwd_fallback dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_krb5.so.1 Example 6: Require users to authenticate either through Kerberos PKINIT or fall back to password based krb auth if PKINIT fails and authenticate with other required PAM modules. The following example allows users to acquire a Kerberos credential using PKINIT preauth or using password based preauth if PKINIT fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password preauth and will just return success. If pam_krb5 PKINIT fails the second instance of pam_krb5 will try password based preauth and return success or failure. dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_krb5.so.1 passwd_fallback dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_auth.so.1 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From deengert@anl.gov Thu Nov 5 13:37:07 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA5Lb6MW024612 for ; Thu, 5 Nov 2009 13:37:07 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5Lb4c9029737; Thu, 5 Nov 2009 13:37:05 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN0041NO1RUS00@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 14:37:03 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00HPSO1QG360@brm-avmta-1.central.sun.com>; Thu, 05 Nov 2009 14:37:02 -0700 (MST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA5LYbBo020734; Thu, 05 Nov 2009 21:37:02 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1677929; Thu, 05 Nov 2009 21:37:02 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-42921; Thu, 05 Nov 2009 21:37:01 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay1i.sun.com with ESMTP id BT-MMP-22600026; Thu, 05 Nov 2009 21:37:01 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 182A118; Thu, 05 Nov 2009 15:37:01 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 0B35A62; Thu, 05 Nov 2009 15:37:01 -0600 (CST) Date: Thu, 05 Nov 2009 15:37:00 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091105200856.GF4337@sun.com> To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss , Wyllys Ingersoll , Will Fiveash Message-id: <4AF3457C.4090306@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 8253 Will Fiveash wrote: > On Thu, Oct 22, 2009 at 04:55:17PM -0500, Will Fiveash wrote: >> On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren 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 > >>>> 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. >>> >>> 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'll work on that and send it as a reply. > > While working out the various permutations of PAM auth stacks I've > discovered that my fasttrack was not complete in regards to new > interfaces. In order for the fall back to work properly from PKINIT to > password based preauth, pam_krb5 will need a user configurable option to > tell the first instance of pam_krb5 (doing PKINIT preauth) whether there > will be a second instance of pam_krb5 stacked below pam_authtok_get that > will try password preauth if PKINIT preauth fails. The idea is that if > the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE > if the fall back option is set to true (it would be false by default). > Otherwise the first instance of pam_krb5 (PKINIT) would return failure. > > I believe there are two options in regards to the implementation of this > "fall back" config parameter. One is a new pam_krb5 argument set in > pam.conf like: > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth required pam_krb5.so.1 passwd_fallback > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_krb5.so.1 > dtlogin auth required pam_dhkeys.so.1 > dtlogin auth required pam_unix_auth.so.1 > > The other implementation option is to add support for a pam_krb5 stanza > in the krb5.conf [appdefaults] section which would be a bit more work. > Also note that currently there are no support pam_krb5 config parameters > in krb5.conf. Thoughts as to which implementation of password fall back > is preferable? > > Here are the example auth stacks involving pam_krb5 doing PKINIT (these > examples assume use of a passwd_fallback argument to pam_krb5): > You also need an example of a system that does not not have PKINIT at all and the user uses a password. Is your pam_krb5 using the fact that the PAM_AUTHTOK is null, because pam_authtok_get has not been called to make a decision about PKINIT? This will be confusing for admins, as this is the first time I can recall of a module being used twice in the same stack. Your example 3 to an admin who does not have pkinit looks like a mistake with two likes out of order. If you still want to have it in the stack twice, you may want to use an explicit try_pkinit parameter on the first entry to indicate it is for pkinit. This is less ambiguous for the admin, and would mean to add pkinit to an existing stack would be to drop in a pam_krb5 try_pkinit before the pam_authtok_get. Your example 3 to an admin who does not have pkinit looks like a mistake with two lines out of order. Example 4 and 6 look like they will do the same thing too. > Example 1: Authenticate Users Through Kerberos PKINIT as First Choice > > The following is an excerpt of a sample pam.conf configuration file > that authenticates users through the Kerberos authentication > service and authenticates through the Unix login only if the > Kerberos authentication (using PKINIT) fails. This arrangement is > helpful when a majority of the users are networked by means of > Kerberos and when there are only a few non-Kerberos type user > accounts, such as root. The service illustrated below is for > dtlogin. Note, the user is prompted once for the PIN by pam_krb5. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth sufficient pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_dhkeys.so.1 > dtlogin auth required pam_unix_auth.so.1 > > Example 2: > > Authenticate Users Through Kerberos PKINIT Only > > The following example allows authentication only to users that have > Kerberos-based accounts requiring PKINIT preauth. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth binding pam_krb5.so.1 > > Example 3: > > Authenticate Users Through Kerberos PKINIT Optionally > > The following example allows users to acquire a Kerberos credential > using PKINIT preauth if they have a Kerberos account. Whether > pam_krb5 succeeds or fails the user must provide their Unix password > in order to login. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth optional pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_unix_auth.so.1 > > Example 4: > > Authenticate Users Through Kerberos PKINIT as a requirement. > > The following example allows users to login if pam_krb5 is able to > acquire a Kerberos credential via PKINT preauth and in addition must > provide their Unix password to pam_unix_auth. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth required pam_krb5.so.1 > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_unix_auth.so.1 > > Example 5: > > Authenticate Users Through Kerberos PKINIT, fall back to > password based krb auth if PKINIT fails. > > The following example allows users to acquire a Kerberos credential > using PKINIT preauth or using password based preauth if PKINIT > fails. If PKINIT succeeds the user will not be prompted for their > password. Note, if pam_krb5 PKINIT succeeds, the second instance of > pam_krb5 will not try password preauth and will return success. > If PKINIT fails the user will be prompted for their Kerberos > password. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth sufficient pam_krb5.so.1 passwd_fallback > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_krb5.so.1 > > Example 6: > > Require users to authenticate either through Kerberos PKINIT or fall > back to password based krb auth if PKINIT fails and authenticate > with other required PAM modules. > > The following example allows users to acquire a Kerberos credential > using PKINIT preauth or using password based preauth if PKINIT > fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 > will not try password preauth and will just return success. Or should it return ignore? Sounds safer, as if the admin forgets to add the second pam_krb5 or pam_unix_auth, you just let him login. > If > pam_krb5 PKINIT fails the second instance of pam_krb5 will try > password based preauth and return success or failure. But won't pam_authtok_get still prompt the user for a password? If the pkinit works, this looks a lot like example 4. > > dtlogin auth required pam_unix_cred.so.1 > dtlogin auth required pam_krb5.so.1 passwd_fallback > dtlogin auth requisite pam_authtok_get.so.1 > dtlogin auth required pam_krb5.so.1 Should the above be sufficient? > dtlogin auth required pam_dhkeys.so.1 > dtlogin auth required pam_unix_auth.so.1 > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hotz@jpl.nasa.gov Thu Nov 5 14:19:22 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA5MJLZQ025371 for ; Thu, 5 Nov 2009 14:19:22 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA5MJEl3025878; Fri, 6 Nov 2009 06:19:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00A03Q03YZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Nov 2009 14:19:15 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN002ETQ028P40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 05 Nov 2009 14:19:15 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5MJE29012920; Thu, 05 Nov 2009 22:19:14 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1681014; Thu, 05 Nov 2009 22:19:14 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-107384; Thu, 05 Nov 2009 22:19:14 +0000 (Z) Received: from mail.jpl.nasa.gov ([128.149.139.106] [128.149.139.106]) by relay1i.sun.com with ESMTP id BT-MMP-14953986; Thu, 05 Nov 2009 22:19:13 +0000 (Z) Received: from mprox1.jpl.nasa.gov (mprox1.jpl.nasa.gov [137.78.160.140]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA5MIZpW017484; Thu, 05 Nov 2009 14:18:36 -0800 Received: from dhcp-79-120-129.jpl.nasa.gov (dhcp-79-120-129.jpl.nasa.gov [137.79.120.129]) by mprox1.jpl.nasa.gov (Switch-3.2.6/Switch-3.2.6) with ESMTP id nA5MIXrC005204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 05 Nov 2009 14:18:34 -0800 Date: Thu, 05 Nov 2009 14:18:33 -0800 From: "Henry B. Hotz" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091105200856.GF4337@sun.com> To: Will Fiveash Cc: Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Source-IP: dhcp-79-120-129.jpl.nasa.gov [137.79.120.129] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> Status: RO Content-Length: 596 Couple of points: While I don't specifically advocate it, I note that Russ' pam_krb5 and the RedHat pam_krb5 both use configuration info in krb5.conf. I personally would think that's simpler, but probably less "pam-like". I think you need an example of a smart-card-required configuration with pkinit-only pam_krb5 and fall-back to pam_pkcs11 if the network connection is down. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From gww@eng.sun.com Thu Nov 5 14:33:43 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA5MXgho025630 for ; Thu, 5 Nov 2009 14:33:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5MXgl6017389 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 5 Nov 2009 14:33:42 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00C07QO4W600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Nov 2009 14:33:40 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00293QO38O40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 05 Nov 2009 14:33:39 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5MXbLD026580; Thu, 05 Nov 2009 14:33:37 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id nA5MXWKX001329; Thu, 05 Nov 2009 14:33:32 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id nA5MXWBb001328; Thu, 05 Nov 2009 14:33:32 -0800 (PST) Date: Thu, 05 Nov 2009 14:33:32 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: Darren.Moffat@sun.com, PSARC-ext@sun.com, William.Fiveash@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <200911052233.nA5MXWBb001328@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1239 > While working out the various permutations of PAM auth stacks I've > discovered that my fasttrack was not complete in regards to new > interfaces. At yesterday's meeting, I asked for more time through today. Unfortuntely, I'm not going to be able to get through this case today. So, I'd like to ask the case be extended to next meeting. A few brief comments that may have already been covered, if so, I apologize. 1st, I think pam_eval() that Nico mentioned could well be a positive alternative -- I know I'm the bottle neck in code review. 2nd, applications can set PAM_AUTHTOK just the same way they can set PAM_USER. So keying off unset PAM_USER/PAM_AUTHTOK may not be as robust as it might have been thought. 3rd, a module could be written and stacked above pam_authtok_get(5) that prompted for what type of authentication was desired and set PAM_PROMPT before returning PAM_IGNORE and falling into pam_authtok_get(5). I'm working to get caught up on this case. I unfortunately missed the pre-review and when I asked where it stood, was told the issues had been resolved. More later, Gary.. P.S. I, too, would really like to see a man page update for pam_krb5(5) as a separate part of the case materials. From William.Fiveash@sun.com Fri Nov 6 13:34:55 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6LYsUp005503 for ; Fri, 6 Nov 2009 13:34:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA6LYqUs008838; Fri, 6 Nov 2009 21:34:53 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00A01IM55M00@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 14:34:53 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP000EFIM4MD60@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 14:34:52 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6LRJ9l027875; Fri, 06 Nov 2009 15:27:19 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6LRJ8p027874; Fri, 06 Nov 2009 15:27:19 -0600 (CST) Date: Fri, 06 Nov 2009 15:27:19 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AE08B0F.5090508@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091106212719.GG4337@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 34646 On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat 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. Here is the updated pam_krb5(5) man page with diffs following: Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. Note that if pam_sm_authenticate() is called and the PAM_AUTHTOK password item has not been set, which is typically the case when pam_krb5 is stacked before pam_authtok_get, the Kerberos V5 authentication module will try to do PKINIT preauthentication if both the system and the KDC are configured to support this type of preauthentication. This form of preauthentication uses a user's certificate and private key to acquire the user's initial Kerberos credential (TGT). Use of smartcards is supported by PKINIT preauthentication. See krb5.conf(4) for more details on PKINIT configuration. Also note that this form of preauthentication is typically useful for services where the system on which the auth stack is being processed has access to the user's certificate and private key. If the PAM_AUTHTOK password item has been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 authentication module will only try password based preauthentication. If it is desirable to initially have the Kerberos V5 authentication module try PKINIT preauthentication and fall back to password based preauthentication then the passwd_fallback must be provided on the instance of pam_krb5 stacked above pam_authtok_get and another instance of pam_krb5 must be stacked below pam_authtok_get without this option. Note that the option only affects the behavior of the first instance of pam_krb5 when the PAM_AUTHTOK password item has not been set. Also note that only two instances of pam_krb5 are supported in a auth stack. pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. passwd_fallback Causes pam_krb5 to return PAM_IGNORE if it is doing PKINIT preauthentication and it is desired to try password based preauthentication if PKINIT fails. A second instance of pam_krb5 must follow pam_authtok_get if this option is used. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. This does not apply if the module is using PKINIT preauthentication. The following options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. This does not apply if the module is using PKINIT preauthentication. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. Example 2 Authenticate Users Through Kerberos Only using password based preauthentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 Example 3 Authenticate Through Kerberos Optionally using password based preauthentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. Example 4: Authenticate Users Through Kerberos PKINIT as First Choice The following is an excerpt of a sample pam.conf configuration file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication (using PKINIT) fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. Note, the user is prompted once for the PIN by pam_krb5. login auth sufficient pam_krb5.so.1 login auth requisite pam_authtok_get.so.1 login auth required pam_unix_cred.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 5: Authenticate Users Through Kerberos PKINIT Only The following example allows authentication only to users that have Kerberos-based accounts requiring PKINIT preauth. dtlogin auth binding pam_krb5.so.1 dtlogin auth required pam_unix_cred.so.1 Example 6: Authenticate Users Through Kerberos PKINIT Optionally The following example allows users to acquire a Kerberos credential using PKINIT preauth if they have a Kerberos account. Whether pam_krb5 succeeds or fails the user must provide their Unix password in order to login. dtlogin auth optional pam_krb5.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 Example 7: Authenticate Users Through Kerberos PKINIT as a requirement. The following example allows users to login if pam_krb5 is able to acquire a Kerberos credential via PKINT preauth and in addition must provide their Unix password to pam_unix_auth. dtlogin auth required pam_krb5.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 Example 8: Authenticate Users Through Kerberos PKINIT, fall back to password based krb auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT preauth or using password based preauth if PKINIT fails. If PKINIT succeeds the user will not be prompted for their password. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password preauth and will return success. If PKINIT fails the user will be prompted for their Kerberos password. dtlogin auth sufficient pam_krb5.so.1 passwd_fallback dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth required pam_unix_cred.so.1 Example 9: Require users to authenticate either through Kerberos PKINIT or fall back to password based krb auth if PKINIT fails and authenticate with other required PAM modules. The following example allows users to acquire a Kerberos credential using PKINIT preauth or using password based preauth if PKINIT fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password preauth and will just return success. If pam_krb5 PKINIT fails the second instance of pam_krb5 will try password based preauth and return success or failure. dtlogin auth required pam_krb5.so.1 passwd_fallback dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth required pam_dhkeys.so.1 dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 Example 10: Require users to authenticate either through Kerberos PKINIT or fall back to pam_pkcs11 auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT preauth or if that fails use pam_pkcs11 to validate the user's PIN using their certificate and private key. dtlogin auth sufficient pam_krb5.so.1 dtlogin auth sufficient pam_pkcs11.so.1 dtlogin auth required pam_unix_cred.so.1 ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 Here are the diffs between the original pam_krb5(5) man page and the updated version: --- pam_krb5_man_orig Fri Nov 6 14:47:20 2009 +++ pam_krb5_man_pkinit Fri Nov 6 15:21:52 2009 @@ -46,7 +46,38 @@ this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + PAM_AUTHTOK password item has not been set, which is + typically the case when pam_krb5 is stacked before + pam_authtok_get, the Kerberos V5 authentication module will + try to do PKINIT preauthentication if both the system and + the KDC are configured to support this type of + preauthentication. This form of preauthentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT preauthentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of preauthentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + + If the PAM_AUTHTOK password item has been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 + authentication module will only try password based + preauthentication. + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT preauthentication and fall + back to password based preauthentication then the + passwd_fallback must be provided on the instance of pam_krb5 + stacked above pam_authtok_get and another instance of + pam_krb5 must be stacked below pam_authtok_get without this + option. Note that the option only affects the behavior of + the first instance of pam_krb5 when the PAM_AUTHTOK password + item has not been set. Also note that only two instances of + pam_krb5 are supported in a auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK @@ -144,13 +175,22 @@ nowarn Turns off warning messages. + passwd_fallback Causes pam_krb5 to return PAM_IGNORE if + it is doing PKINIT preauthentication and + it is desired to try password based + preauthentication if PKINIT fails. A + second instance of pam_krb5 must follow + pam_authtok_get if this option is used. + + Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module - has noted that the user's password has not expired. The fol- - lowing options may be passed in to the Kerberos V5 account - management module: + has noted that the user's password has not expired. This + does not apply if the module is using PKINIT + preauthentication. The following options may be passed in to + the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level @@ -171,8 +211,9 @@ Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key - Distribution Center (KDC) database. The following flags may - be passed to pam_sm_chauthtok(3PAM): + Distribution Center (KDC) database. This does not apply if + the module is using PKINIT preauthentication. The following + flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK @@ -363,7 +404,7 @@ EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- @@ -437,7 +478,8 @@ the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based preauthentication The following example allows authentication only to users @@ -506,7 +548,8 @@ other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based preauthentication This configuration is helpful when the majority of users are @@ -559,6 +602,104 @@ with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf configuration file + that authenticates users through the Kerberos authentication + service and authenticates through the Unix login only if the + Kerberos authentication (using PKINIT) fails. This arrangement is + helpful when a majority of the users are networked by means of + Kerberos and when there are only a few non-Kerberos type user + accounts, such as root. The service illustrated below is for + dtlogin. Note, the user is prompted once for the PIN by pam_krb5. + + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_cred.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT preauth. + + dtlogin auth binding pam_krb5.so.1 + dtlogin auth required pam_unix_cred.so.1 + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth if they have a Kerberos account. Whether + pam_krb5 succeeds or fails the user must provide their Unix password + in order to login. + + dtlogin auth optional pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is able to + acquire a Kerberos credential via PKINT preauth and in addition must + provide their Unix password to pam_unix_auth. + + dtlogin auth required pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. If PKINIT succeeds the user will not be prompted for their + password. Note, if pam_krb5 PKINIT succeeds, the second instance of + pam_krb5 will not try password preauth and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + dtlogin auth sufficient pam_krb5.so.1 passwd_fallback + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + dtlogin auth required pam_unix_cred.so.1 + + Example 9: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password preauth and will just return success. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will try + password based preauth and return success or failure. + + dtlogin auth required pam_krb5.so.1 passwd_fallback + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + dtlogin auth required pam_dhkeys.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or if that fails use pam_pkcs11 to + validate the user's PIN using their certificate and private + key. + + dtlogin auth sufficient pam_krb5.so.1 + dtlogin auth sufficient pam_pkcs11.so.1 + dtlogin auth required pam_unix_cred.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Fri Nov 6 14:41:58 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6Mfvck007854 for ; Fri, 6 Nov 2009 14:41:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA6MfonG014938; Fri, 6 Nov 2009 22:41:57 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00H05LPV8C00@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 15:41:55 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP000J3LPVMFA0@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 15:41:55 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6MYMcw028152; Fri, 06 Nov 2009 16:34:22 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6MYMRa028151; Fri, 06 Nov 2009 16:34:22 -0600 (CST) Date: Fri, 06 Nov 2009 16:34:22 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091106212719.GG4337@sun.com> To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <20091106223422.GA27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091106212719.GG4337@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 24928 On Fri, Nov 06, 2009 at 03:27:19PM -0600, Will Fiveash wrote: > On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren Moffat 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. Nico request a different diff marked man page so here it is: --- pam_krb5_man_orig Fri Nov 6 14:47:20 2009 +++ pam_krb5_man_pkinit Fri Nov 6 15:21:52 2009 @@ -1,660 +1,801 @@ Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + PAM_AUTHTOK password item has not been set, which is + typically the case when pam_krb5 is stacked before + pam_authtok_get, the Kerberos V5 authentication module will + try to do PKINIT preauthentication if both the system and + the KDC are configured to support this type of + preauthentication. This form of preauthentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT preauthentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of preauthentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + + If the PAM_AUTHTOK password item has been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 + authentication module will only try password based + preauthentication. + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT preauthentication and fall + back to password based preauthentication then the + passwd_fallback must be provided on the instance of pam_krb5 + stacked above pam_authtok_get and another instance of + pam_krb5 must be stacked below pam_authtok_get without this + option. Note that the option only affects the behavior of + the first instance of pam_krb5 when the PAM_AUTHTOK password + item has not been set. Also note that only two instances of + pam_krb5 are supported in a auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. + passwd_fallback Causes pam_krb5 to return PAM_IGNORE if + it is doing PKINIT preauthentication and + it is desired to try password based + preauthentication if PKINIT fails. A + second instance of pam_krb5 must follow + pam_authtok_get if this option is used. + + Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module - has noted that the user's password has not expired. The fol- - lowing options may be passed in to the Kerberos V5 account - management module: + has noted that the user's password has not expired. This + does not apply if the module is using PKINIT + preauthentication. The following options may be passed in to + the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key - Distribution Center (KDC) database. The following flags may - be passed to pam_sm_chauthtok(3PAM): + Distribution Center (KDC) database. This does not apply if + the module is using PKINIT preauthentication. The following + flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based preauthentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based preauthentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 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 required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf configuration file + that authenticates users through the Kerberos authentication + service and authenticates through the Unix login only if the + Kerberos authentication (using PKINIT) fails. This arrangement is + helpful when a majority of the users are networked by means of + Kerberos and when there are only a few non-Kerberos type user + accounts, such as root. The service illustrated below is for + dtlogin. Note, the user is prompted once for the PIN by pam_krb5. + + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_cred.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT preauth. + + dtlogin auth binding pam_krb5.so.1 + dtlogin auth required pam_unix_cred.so.1 + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth if they have a Kerberos account. Whether + pam_krb5 succeeds or fails the user must provide their Unix password + in order to login. + + dtlogin auth optional pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is able to + acquire a Kerberos credential via PKINT preauth and in addition must + provide their Unix password to pam_unix_auth. + + dtlogin auth required pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. If PKINIT succeeds the user will not be prompted for their + password. Note, if pam_krb5 PKINIT succeeds, the second instance of + pam_krb5 will not try password preauth and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + dtlogin auth sufficient pam_krb5.so.1 passwd_fallback + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + dtlogin auth required pam_unix_cred.so.1 + + Example 9: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password preauth and will just return success. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will try + password based preauth and return success or failure. + + dtlogin auth required pam_krb5.so.1 passwd_fallback + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + dtlogin auth required pam_dhkeys.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or if that fails use pam_pkcs11 to + validate the user's PIN using their certificate and private + key. + + dtlogin auth sufficient pam_krb5.so.1 + dtlogin auth sufficient pam_pkcs11.so.1 + dtlogin auth required pam_unix_cred.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@Sun.COM Fri Nov 6 15:21:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6NLctF009111 for ; Fri, 6 Nov 2009 15:21:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA6NLXpa008968; Sat, 7 Nov 2009 07:21:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00L07NJVO900@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 16:21:31 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP000ESNJUMIC0@brm-avmta-1.central.sun.com>; Fri, 06 Nov 2009 16:21:30 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6N6RIB028375; Fri, 06 Nov 2009 17:06:27 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6N6RVV028374; Fri, 06 Nov 2009 17:06:27 -0600 (CST) Date: Fri, 06 Nov 2009 17:06:27 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: To: "Henry B. Hotz" Cc: Will Fiveash , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Mail-followup-to: "Henry B. Hotz" , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Message-id: <20091106230627.GB27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 968 On Thu, Nov 05, 2009 at 02:18:33PM -0800, Henry B. Hotz wrote: > Couple of points: > > While I don't specifically advocate it, I note that Russ' pam_krb5 and the > RedHat pam_krb5 both use configuration info in krb5.conf. I personally > would think that's simpler, but probably less "pam-like". Yes, I'm aware of that but Solaris pam_krb has not supported that up to this point while it has supported pam.conf stanza line arguments which is why I was leaning that direction for a password fallback option. > I think you need an example of a smart-card-required configuration with > pkinit-only pam_krb5 and fall-back to pam_pkcs11 if the network connection > is down. dtlogin auth sufficient pam_krb5.so.1 dtlogin auth sufficient pam_pkcs11.so.1 dtlogin auth required pam_unix_cred.so.1 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Nicolas.Williams@sun.com Fri Nov 6 15:56:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6NuNXX010863 for ; Fri, 6 Nov 2009 15:56:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA6NtCCc024896; Sat, 7 Nov 2009 07:56:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00J0RP5R8L00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Nov 2009 15:56:15 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00E5EP5Q6WC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Nov 2009 15:56:15 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6NbCVW010482; Fri, 06 Nov 2009 17:37:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6NbChE010481; Fri, 06 Nov 2009 17:37:12 -0600 (CST) Date: Fri, 06 Nov 2009 17:37:12 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091106230627.GB27416@sun.com> To: "Henry B. Hotz" , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Message-id: <20091106233712.GL1105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <20091106230627.GB27416@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1247 On Fri, Nov 06, 2009 at 05:06:27PM -0600, Will Fiveash wrote: > On Thu, Nov 05, 2009 at 02:18:33PM -0800, Henry B. Hotz wrote: > > Couple of points: > > > > While I don't specifically advocate it, I note that Russ' pam_krb5 and the > > RedHat pam_krb5 both use configuration info in krb5.conf. I personally > > would think that's simpler, but probably less "pam-like". > > Yes, I'm aware of that but Solaris pam_krb has not supported that up to > this point while it has supported pam.conf stanza line arguments which > is why I was leaning that direction for a password fallback option. I'm a fan of having module options for important behaviors because I like to know what I'm getting just by looking at pam.conf. Not all possible module options are of that kind. For example, options about what krb5 ccache type to use, etcetera, are irrelevant to how a PAM stack will be evaluated. Module options that can cause a module to return PAM_IGNORE are the kind of options that I'm talking about, but not *all* such options (for example, an "ignore_user_unknown" option would be OK in krb5.conf instead of as a module option). But even so, I think we should provide krb5.conf [pam] section equivalents for any module options. Nico -- From William.Fiveash@sun.com Fri Nov 6 16:04:41 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA704et6011697 for ; Fri, 6 Nov 2009 16:04:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA704c02004163; Fri, 6 Nov 2009 16:04:39 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP0040NPJQNC00@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Nov 2009 16:04:38 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00GJ7PJD24D0@nwk-avmta-2.sfbay.sun.com>; Fri, 06 Nov 2009 16:04:26 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA6NnNQr028628; Fri, 06 Nov 2009 17:49:23 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA6NnNvL028627; Fri, 06 Nov 2009 17:49:23 -0600 (CST) Date: Fri, 06 Nov 2009 17:49:23 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF3457C.4090306@anl.gov> To: "Douglas E. Engert" Cc: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss , Wyllys Ingersoll , Will Fiveash Mail-followup-to: "Douglas E. Engert" , Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss , Wyllys Ingersoll Message-id: <20091106234923.GC27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <4AF3457C.4090306@anl.gov> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 9978 On Thu, Nov 05, 2009 at 03:37:00PM -0600, Douglas E. Engert wrote: > > > Will Fiveash wrote: > > On Thu, Oct 22, 2009 at 04:55:17PM -0500, Will Fiveash wrote: > >> On Thu, Oct 22, 2009 at 05:40:47PM +0100, Darren 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 > >>>> 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. > >>> > >>> 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'll work on that and send it as a reply. > > While working out the various permutations of PAM auth stacks I've > > discovered that my fasttrack was not complete in regards to new > > interfaces. In order for the fall back to work properly from PKINIT to > > password based preauth, pam_krb5 will need a user configurable option to > > tell the first instance of pam_krb5 (doing PKINIT preauth) whether there > > will be a second instance of pam_krb5 stacked below pam_authtok_get that > > will try password preauth if PKINIT preauth fails. The idea is that if > > the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE > > if the fall back option is set to true (it would be false by default). > > Otherwise the first instance of pam_krb5 (PKINIT) would return failure. > > I believe there are two options in regards to the implementation of this > > "fall back" config parameter. One is a new pam_krb5 argument set in > > pam.conf like: > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth required pam_krb5.so.1 passwd_fallback > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_krb5.so.1 > > dtlogin auth required pam_dhkeys.so.1 > > dtlogin auth required pam_unix_auth.so.1 > > The other implementation option is to add support for a pam_krb5 stanza > > in the krb5.conf [appdefaults] section which would be a bit more work. > > Also note that currently there are no support pam_krb5 config parameters > > in krb5.conf. Thoughts as to which implementation of password fall back > > is preferable? > > Here are the example auth stacks involving pam_krb5 doing PKINIT (these > > examples assume use of a passwd_fallback argument to pam_krb5): > > > > You also need an example of a system that does not not have PKINIT at all > and the user uses a password. That is already in the current pam_krb5.5 man page but I'll provide it for convenience: dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 > Is your pam_krb5 using the fact that the PAM_AUTHTOK is null, because > pam_authtok_get has not been called to make a decision about PKINIT? Yes. > This will be confusing for admins, as this is the first time I can recall > of a module being used twice in the same stack. Let's see if any PSARC members have an issue with this. Remember that pam_krb5 is relying on pam_authtok_get to prompt for a password and unless that implementation is changed it means that pam_krb5 must be stacked before and after pam_authtok_get in order to try PKINIT and fall back to password based preauth if PKINIT fails. > If you still want to have it in the stack twice, you may want to use > an explicit try_pkinit parameter on the first entry to indicate it is > for pkinit. This is less ambiguous for the admin, and would mean to add > pkinit to an existing stack would be to drop in a pam_krb5 try_pkinit > before the pam_authtok_get. I am trying to avoid unnecessary arguments/options. If the PSARC reviewers feel your point above has merit I will add a do_pkinit argument (try_pkinit makes me think pam_krb5 will fall back to password preauth which isn't the case). > Your example 3 to an admin who does not have pkinit looks like a mistake > with two lines out of order. Hopefully they will read the docs. If that is not enough then maybe the do_pkinit arg is necessary. > Example 4 and 6 look like they will do the same thing too. No, example 4 will not fall back to trying password based krb preauth while example 6 does. > > Example 1: Authenticate Users Through Kerberos PKINIT as First Choice > > The following is an excerpt of a sample pam.conf configuration file > > that authenticates users through the Kerberos authentication > > service and authenticates through the Unix login only if the > > Kerberos authentication (using PKINIT) fails. This arrangement is > > helpful when a majority of the users are networked by means of > > Kerberos and when there are only a few non-Kerberos type user > > accounts, such as root. The service illustrated below is for > > dtlogin. Note, the user is prompted once for the PIN by pam_krb5. > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth sufficient pam_krb5.so.1 > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_dhkeys.so.1 > > dtlogin auth required pam_unix_auth.so.1 > > Example 2: > > Authenticate Users Through Kerberos PKINIT Only > > The following example allows authentication only to users that have > > Kerberos-based accounts requiring PKINIT preauth. > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth binding pam_krb5.so.1 > > Example 3: > > Authenticate Users Through Kerberos PKINIT Optionally > > The following example allows users to acquire a Kerberos credential > > using PKINIT preauth if they have a Kerberos account. Whether > > pam_krb5 succeeds or fails the user must provide their Unix password > > in order to login. dtlogin auth required > > pam_unix_cred.so.1 > > dtlogin auth optional pam_krb5.so.1 > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_unix_auth.so.1 > > Example 4: > > Authenticate Users Through Kerberos PKINIT as a requirement. > > The following example allows users to login if pam_krb5 is able to > > acquire a Kerberos credential via PKINT preauth and in addition must > > provide their Unix password to pam_unix_auth. > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth required pam_krb5.so.1 > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_unix_auth.so.1 > > Example 5: > > Authenticate Users Through Kerberos PKINIT, fall back to > > password based krb auth if PKINIT fails. > > The following example allows users to acquire a Kerberos credential > > using PKINIT preauth or using password based preauth if PKINIT > > fails. If PKINIT succeeds the user will not be prompted for their > > password. Note, if pam_krb5 PKINIT succeeds, the second instance of > > pam_krb5 will not try password preauth and will return success. > > If PKINIT fails the user will be prompted for their Kerberos > > password. > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth sufficient pam_krb5.so.1 passwd_fallback > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_krb5.so.1 > > Example 6: > > Require users to authenticate either through Kerberos PKINIT or fall > > back to password based krb auth if PKINIT fails and authenticate > > with other required PAM modules. > > The following example allows users to acquire a Kerberos credential > > using PKINIT preauth or using password based preauth if PKINIT > > fails. Note, if pam_krb5 PKINIT succeeds, the second instance of > > pam_krb5 > > will not try password preauth and will just return success. > > Or should it return ignore? Sounds safer, as if the admin forgets to add > the second pam_krb5 or pam_unix_auth, you just let him login. Good point and I've changed the code so the second instance of pam_krb5 will return PAM_IGNORE if the first instance of pam_krb5 returned PAM_SUCCESS. > > If > > pam_krb5 PKINIT fails the second instance of pam_krb5 will try > > password based preauth and return success or failure. > > But won't pam_authtok_get still prompt the user for a password? > If the pkinit works, this looks a lot like example 4. Example 6 may prompt for a PIN if the pkinit code finds a suitable token and will always prompt for a password since pam_authtok_get is in there and the first instance of pam_krb5 doing pkinti is required. If it were sufficient and PKINIT succeeded the rest of the would be skipped. > > dtlogin auth required pam_unix_cred.so.1 > > dtlogin auth required pam_krb5.so.1 passwd_fallback > > dtlogin auth requisite pam_authtok_get.so.1 > > dtlogin auth required pam_krb5.so.1 > > Should the above be sufficient? No because pam_unix_auth is also required. > > dtlogin auth required pam_dhkeys.so.1 > > dtlogin auth required pam_unix_auth.so.1 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Joerg.Barfurth@Sun.COM Mon Nov 9 03:12:27 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9BCPIX003410 for ; Mon, 9 Nov 2009 03:12:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA9BCOJA019444 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Nov 2009 19:12:25 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSU00M079SLNL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 04:12:21 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSU007SU9SIV5C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 04:12:20 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA9BCIwC025823 for ; Mon, 09 Nov 2009 11:12:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSU00F009LX9700@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 11:12:08 +0000 (GMT) Received: from [10.16.46.243] ([unknown] [10.16.46.243]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSU00FCN9RYOM20@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 11:11:58 +0000 (GMT) Date: Mon, 09 Nov 2009 12:11:58 +0100 From: Joerg Barfurth Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF3457C.4090306@anl.gov> Sender: Joerg.Barfurth@Sun.COM To: "Douglas E. Engert" Cc: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss , Wyllys Ingersoll , Will Fiveash Message-id: <4AF7F8FE.6030801@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <4AF3457C.4090306@anl.gov> User-Agent: Thunderbird 2.0.0.23 (X11/20090926) Status: RO Content-Length: 4481 Douglas E. Engert schrieb: >>>>> 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. >>>> FWIW I feel uncomfortable with the idea that presence or absence of a PAM_AUTHTOK will change the behavior of pam_krb5 substantially. So I'd prefer a 'preauth' or 'pkinit' option here. >>>> 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'll work on that and send it as a reply. >> >> While working out the various permutations of PAM auth stacks I've >> discovered that my fasttrack was not complete in regards to new >> interfaces. In order for the fall back to work properly from PKINIT to >> password based preauth, pam_krb5 will need a user configurable option to >> tell the first instance of pam_krb5 (doing PKINIT preauth) whether there >> will be a second instance of pam_krb5 stacked below pam_authtok_get that >> will try password preauth if PKINIT preauth fails. The idea is that if >> the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE >> if the fall back option is set to true (it would be false by default). >> Otherwise the first instance of pam_krb5 (PKINIT) would return failure. >> To me that sounds like something that should not require a module option. Stack flow is controlled by the control flag part of the pam.conf entry. So if preauth failure is not fatal, it should simply be configured as 'optional' or 'sufficient'. >> Example 5: >> >> Authenticate Users Through Kerberos PKINIT, fall back to >> password based krb auth if PKINIT fails. >> >> The following example allows users to acquire a Kerberos credential >> using PKINIT preauth or using password based preauth if PKINIT >> fails. If PKINIT succeeds the user will not be prompted for their >> password. Note, if pam_krb5 PKINIT succeeds, the second instance of >> pam_krb5 will not try password preauth and will return success. >> If PKINIT fails the user will be prompted for their Kerberos >> password. >> >> dtlogin auth required pam_unix_cred.so.1 >> dtlogin auth sufficient pam_krb5.so.1 passwd_fallback >> dtlogin auth requisite pam_authtok_get.so.1 >> dtlogin auth required pam_krb5.so.1 >> What does your flag change here? Whether the first instance returns PAM_IGNORE or failure makes no difference. >> Example 6: >> >> Require users to authenticate either through Kerberos PKINIT or fall >> back to password based krb auth if PKINIT fails and authenticate >> with other required PAM modules. >> >> The following example allows users to acquire a Kerberos credential >> using PKINIT preauth or using password based preauth if PKINIT >> fails. Note, if pam_krb5 PKINIT succeeds, the second instance of >> pam_krb5 will not try password preauth and will just return success. >> If pam_krb5 PKINIT fails the second instance of pam_krb5 will try >> password based preauth and return success or failure. >> >> dtlogin auth required pam_unix_cred.so.1 >> dtlogin auth required pam_krb5.so.1 passwd_fallback >> dtlogin auth requisite pam_authtok_get.so.1 >> dtlogin auth required pam_krb5.so.1 >> dtlogin auth required pam_dhkeys.so.1 >> dtlogin auth required pam_unix_auth.so.1 >> What do you gain here vs. making the first pam_krb5.so.1 instance optional? Do you need failure modes where the first instance fails so fatally that it prevents login (after letting the subsequent password login proceed) as opposed to lesser failures that allow the fallback? Even for this you don't really need that option. Or do you need to support cases where you first do PKINIT authentication and later password-based authention on top of that? In this case, I'd expect to see an option on the second instance of the module. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From William.Fiveash@sun.com Mon Nov 9 11:01:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9J1KoJ011461 for ; Mon, 9 Nov 2009 11:01:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA9J1E5Q014306; Tue, 10 Nov 2009 03:01:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSU00K01VI3YJ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 11:01:15 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSU00KI0VI23I00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 11:01:15 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9IkBtm007934; Mon, 09 Nov 2009 12:46:11 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9IkBQ4007933; Mon, 09 Nov 2009 12:46:11 -0600 (CST) Date: Mon, 09 Nov 2009 12:46:11 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091106233712.GL1105@Sun.COM> To: Nicolas Williams Cc: "Henry B. Hotz" , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Mail-followup-to: Nicolas Williams , "Henry B. Hotz" , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Message-id: <20091109184610.GD27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <20091106230627.GB27416@sun.com> <20091106233712.GL1105@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1946 On Fri, Nov 06, 2009 at 05:37:12PM -0600, Nicolas Williams wrote: > On Fri, Nov 06, 2009 at 05:06:27PM -0600, Will Fiveash wrote: > > On Thu, Nov 05, 2009 at 02:18:33PM -0800, Henry B. Hotz wrote: > > > Couple of points: > > > > > > While I don't specifically advocate it, I note that Russ' pam_krb5 and the > > > RedHat pam_krb5 both use configuration info in krb5.conf. I personally > > > would think that's simpler, but probably less "pam-like". > > > > Yes, I'm aware of that but Solaris pam_krb has not supported that up to > > this point while it has supported pam.conf stanza line arguments which > > is why I was leaning that direction for a password fallback option. > > I'm a fan of having module options for important behaviors because I > like to know what I'm getting just by looking at pam.conf. > > Not all possible module options are of that kind. For example, options > about what krb5 ccache type to use, etcetera, are irrelevant to how a > PAM stack will be evaluated. Module options that can cause a module to > return PAM_IGNORE are the kind of options that I'm talking about, but > not *all* such options (for example, an "ignore_user_unknown" option > would be OK in krb5.conf instead of as a module option). > > But even so, I think we should provide krb5.conf [pam] section > equivalents for any module options. My concern with this is that I'm proposing support of two instances of pam_krb5 in a auth stack and some of these module options may only apply to one instance or the other. For example, if we end up supporting a do_pkinit module option, what sort of logic would pam_krb5 need to understand whether that option, as set in a pam_krb5 stanza in krb5.conf, applies to the current instance? I think instance specific options should only be in pam.conf to avoid this ambiguity. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Nicolas.Williams@sun.com Mon Nov 9 11:55:05 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9Jt4wV012341 for ; Mon, 9 Nov 2009 11:55:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA9Jt2u8005193; Mon, 9 Nov 2009 19:55:03 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSU0060DXZQ0500@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 12:55:02 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSU00HQAXZPS970@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 12:55:02 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9JZwGr011803; Mon, 09 Nov 2009 13:35:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9JZv13011802; Mon, 09 Nov 2009 13:35:57 -0600 (CST) Date: Mon, 09 Nov 2009 13:35:57 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091109184610.GD27416@sun.com> To: "Henry B. Hotz" , Darren J Moffat , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" Message-id: <20091109193557.GF1105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <20091106230627.GB27416@sun.com> <20091106233712.GL1105@Sun.COM> <20091109184610.GD27416@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2018 On Mon, Nov 09, 2009 at 12:46:11PM -0600, Will Fiveash wrote: > > But even so, I think we should provide krb5.conf [pam] section > > equivalents for any module options. > > My concern with this is that I'm proposing support of two instances of > pam_krb5 in a auth stack and some of these module options may only apply > to one instance or the other. For example, if we end up supporting a > do_pkinit module option, what sort of logic would pam_krb5 need to > understand whether that option, as set in a pam_krb5 stanza in > krb5.conf, applies to the current instance? It's clear that a module option that can be on for some services, and off for some others (or where the module can be stacked twice for one service but with different choices for that option) has to be a module option that appears in pam.conf and which can override the same module option if it can be specified elsewhere (such as in krb5.conf). It's not clear that such a module option must only be the kind that appears in pam.conf and not elsewhere. > I think instance specific options should only be in pam.conf to avoid > this ambiguity. As I've said before, some options clearly are uninteresting for someone reading pam.conf, while some are very interesting. IMO that's the distinction that matters here. I don't think we need do_pkinit because position relative to pam_authtok_get is good enough [for me], but this is something w.r.t. reasonable people can disagree -- I don't feel strongly about that. IMO it'd be reasonable to: - have default module behavior as specified in the case materials so far (i.e., try PKINIT if PAM_AUTHTOK is not set, dual stacking, ...) - have a [pam] stanza in krb5.conf where the module's default can be set - have a module option to force the use of PKINIT regardless of whether PAM_AUTHTOK is set and regardless of what is specified in krb5.conf - have a module option to force the use of password-based pre-auth, regardless of what is specified in krb5.conf Nico -- From gww@sac.sfbay.sun.com Mon Nov 9 14:20:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9MKp16016197 for ; Mon, 9 Nov 2009 14:20:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA9MKgu7005176 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Nov 2009 22:20:50 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV00D074QOIT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 14:20:48 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV0072P4QNYA60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 14:20:48 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA9MKj4A022813; Mon, 09 Nov 2009 14:20:45 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9MKjEp016194; Mon, 09 Nov 2009 14:20:45 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nA9MKjIE016193; Mon, 09 Nov 2009 14:20:45 -0800 (PST) Date: Mon, 09 Nov 2009 14:20:45 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: Darren.Moffat@sun.com, PSARC-ext@sun.com, William.Fiveash@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2648 > > > 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. If I understand the project correctly: * The project wants to do different prompting than pam_authtok_get(5). * The project proposes to keying off of the contents of PAM_AUTHTOK * The project proposes adding new configuration options. * The project proposes to bypass account management and password change. * The project proposes changes the the PAM stack. I'd like to propose a different tact. This seem to be to suggest a separate PAM service module. Has that been considered? 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. * 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? 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. 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. 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 ;-)? Gary.. From gww@sac.sfbay.sun.com Mon Nov 9 14:28:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9MSdoY016266 for ; Mon, 9 Nov 2009 14:28:39 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA9MSZcU009895 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 9 Nov 2009 22:28:38 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV0000B53PZ300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 14:28:37 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV00IE253O0AC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 09 Nov 2009 14:28:36 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA9MSYVs027640; Mon, 09 Nov 2009 14:28:34 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9MSYXb016263; Mon, 09 Nov 2009 14:28:34 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nA9MSYpw016262; Mon, 09 Nov 2009 14:28:34 -0800 (PST) Date: Mon, 09 Nov 2009 14:28:34 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: Darren.Moffat@sun.com, PSARC-ext@sun.com, William.Fiveash@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <200911092228.nA9MSYpw016262@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 248 > > > 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 don't seem to find a Release Binding in the case materials. What is the Release Binding? Gary.. From William.Fiveash@Sun.COM Mon Nov 9 14:38:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9McRL7016351 for ; Mon, 9 Nov 2009 14:38:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA9McPki006351; Mon, 9 Nov 2009 15:38:25 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV00M015K1IM00@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 15:38:25 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV00JB95JYN710@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 15:38:22 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9MUh3w010121; Mon, 09 Nov 2009 16:30:43 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9MUh1G010120; Mon, 09 Nov 2009 16:30:43 -0600 (CST) Date: Mon, 09 Nov 2009 16:30:43 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911092228.nA9MSYpw016262@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, William.Fiveash@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091109223043.GE27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911092228.nA9MSYpw016262@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 443 On Mon, Nov 09, 2009 at 02:28:34PM -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 don't seem to find a Release Binding in the case materials. > What is the Release Binding? Minor/Patch -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Nicolas.Williams@sun.com Mon Nov 9 14:40:46 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9Mej8d016478 for ; Mon, 9 Nov 2009 14:40:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA9Mebq0002590; Tue, 10 Nov 2009 06:40:41 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV00M175NRRJ00@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 15:40:39 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV00J745NQNC20@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 15:40:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9MT6LD011897; Mon, 09 Nov 2009 16:29:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9MT6BV011896; Mon, 09 Nov 2009 16:29:06 -0600 (CST) Date: Mon, 09 Nov 2009 16:29:06 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, William.Fiveash@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091109222905.GJ1105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1604 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. > > If I understand the project correctly: I don't think that's quite correct. > * The project wants to do different prompting than pam_authtok_get(5). > > * The project proposes to keying off of the contents of PAM_AUTHTOK Yes. > * The project proposes adding new configuration options. Not really. Maybe. But only in response to requests from others. > * The project proposes to bypass account management and password > change. No. Only the auth stack is affected. Nothing about account management nore password changing changes. (If the top instance of pam_krb5 returns PAM_SUCCESS and it was binding or sufficient then password-based authentication will be skipped. This does not mean that password expiration will not be handled.) > * The project proposes changes the the PAM stack. Yes. > Why should it be that account management and password change are > disallowed? Will and I have talked plenty about this, and though I'll admit to not having read the case materials closely (probably because I felt I was familiar enough with it given our conversations), I don't recall ever, ever talking about changes to the account management nor password change side of PAM or even just pam_krb5. For auth and setcred, the second instance of the module will return PAM_IGNORE if the first instance returned PAM_SUCCESS (at least as of Friday, right Will?). Nico -- From William.Fiveash@Sun.COM Mon Nov 9 15:21:16 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA9NLFvH017119 for ; Mon, 9 Nov 2009 15:21:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA9NLB58021634; Tue, 10 Nov 2009 07:21:11 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV007077JAYD00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 15:21:10 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV002OJ7JAM330@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 15:21:10 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9NDZQ0010422; Mon, 09 Nov 2009 17:13:35 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9NDZce010421; Mon, 09 Nov 2009 17:13:35 -0600 (CST) Date: Mon, 09 Nov 2009 17:13:35 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091109222905.GJ1105@Sun.COM> To: Nicolas Williams Cc: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, William.Fiveash@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Nicolas Williams , Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091109231335.GF27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109222905.GJ1105@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2482 On Mon, Nov 09, 2009 at 04:29:06PM -0600, Nicolas Williams 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. > > > > If I understand the project correctly: > > I don't think that's quite correct. > > > * The project wants to do different prompting than pam_authtok_get(5). > > > > * The project proposes to keying off of the contents of PAM_AUTHTOK > > Yes. > > > * The project proposes adding new configuration options. > > Not really. Maybe. But only in response to requests from others. I'm proposing adding a passwd_fallback option to pam_krb5 to properly handle a auth stack where the admin wants to try PKINIT and if that fails, have it return pam_ignore and have the second instance of pam_krb5 following pam_authtok_get try password preauth but only if PKINIT failed. If passwd_fallback is not set on the first instance then pam_krb5 would return failure if PKINIT failed. > > * The project proposes to bypass account management and password > > change. > > No. Only the auth stack is affected. Nothing about account management > nore password changing changes. Correct. > (If the top instance of pam_krb5 returns PAM_SUCCESS and it was binding > or sufficient then password-based authentication will be skipped. This > does not mean that password expiration will not be handled.) If pam_krb5 is only doing PKINIT the KDC should not be indicating password expired thus that part of pam_krb5 should not come into play for PKINIT. For password based preauth nothing has changed here. > > * The project proposes changes the the PAM stack. > > Yes. > > > Why should it be that account management and password change are > > disallowed? > > Will and I have talked plenty about this, and though I'll admit to not > having read the case materials closely (probably because I felt I was > familiar enough with it given our conversations), I don't recall ever, > ever talking about changes to the account management nor password change > side of PAM or even just pam_krb5. > For auth and setcred, the second instance of the module will return > PAM_IGNORE if the first instance returned PAM_SUCCESS (at least as of > Friday, right Will?). That is correct. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Mon Nov 9 16:02:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAA02LM2018231 for ; Mon, 9 Nov 2009 16:02:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAA02HrB027138; Tue, 10 Nov 2009 00:02:19 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV0080D9FTF300@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 17:02:17 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV00JZT9FTN750@brm-avmta-1.central.sun.com>; Mon, 09 Nov 2009 17:02:17 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA9Nsf7Q010676; Mon, 09 Nov 2009 17:54:41 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA9Nsf9O010675; Mon, 09 Nov 2009 17:54:41 -0600 (CST) Date: Mon, 09 Nov 2009 17:54:41 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, William.Fiveash@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091109235441.GH27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 3739 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 From gww@sac.sfbay.sun.com Mon Nov 9 16:43:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAA0h2oQ019245 for ; Mon, 9 Nov 2009 16:43:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAA0h1AY018853 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Tue, 10 Nov 2009 00:43:01 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV00C05BBPRN00@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 09 Nov 2009 17:43:01 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV00JKKBBOMZ80@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 09 Nov 2009 17:43:00 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAA0gwhp022949; Mon, 09 Nov 2009 16:42:58 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAA0gwJJ019239; Mon, 09 Nov 2009 16:42:58 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nAA0gwRg019238; Mon, 09 Nov 2009 16:42:58 -0800 (PST) Date: Mon, 09 Nov 2009 16:42:58 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: William.Fiveash@sun.com Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <200911100042.nAA0gwRg019238@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 280 > > What is the Release Binding? > > Minor/Patch Which is it Minor or Patch -- they are different see http://sac.eng/BestPractices/release_taxonomy.html and http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Patch implies Minor, Minor does not imply Patch. Gary.. From William.Fiveash@sun.com Mon Nov 9 17:02:49 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAA12maI019842 for ; Mon, 9 Nov 2009 17:02:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAA12kPg002879; Mon, 9 Nov 2009 17:02:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSV00M0BC8L1E00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 17:02:45 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSV002JLC8KM690@nwk-avmta-1.sfbay.Sun.COM>; Mon, 09 Nov 2009 17:02:45 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAA0t9IE011170; Mon, 09 Nov 2009 18:55:09 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAA0t9cI011169; Mon, 09 Nov 2009 18:55:09 -0600 (CST) Date: Mon, 09 Nov 2009 18:55:09 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911100042.nAA0gwRg019238@sac.sfbay.sun.com> To: Gary Winiger Cc: William.Fiveash@sun.com, Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Mail-followup-to: Gary Winiger , Darren.Moffat@sun.com, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091110005509.GI27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911100042.nAA0gwRg019238@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 531 On Mon, Nov 09, 2009 at 04:42:58PM -0800, Gary Winiger wrote: > > > What is the Release Binding? > > > > Minor/Patch > > Which is it Minor or Patch -- they are different see > http://sac.eng/BestPractices/release_taxonomy.html > and > http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp > > Patch implies Minor, Minor does not imply Patch. Sorry I got that from a related fasttrack. I mean Minor. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From deengert@anl.gov Tue Nov 10 06:55:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAEt5M5013726 for ; Tue, 10 Nov 2009 06:55:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAAEt2AM036954; Tue, 10 Nov 2009 07:55:03 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00D07ERQFF00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Nov 2009 06:55:02 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW00KE6ERQ1LF0@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Nov 2009 06:55:02 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAEqZLo005168; Tue, 10 Nov 2009 14:55:01 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay44i.sun.com with ESMTP id BT-MMP-1253740; Tue, 10 Nov 2009 14:54:53 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-49029553; Tue, 10 Nov 2009 14:54:52 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay4i.sun.com with ESMTP id BT-MMP-14185809; Tue, 10 Nov 2009 14:54:52 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 8D7C91A; Tue, 10 Nov 2009 08:54:52 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 6E87B70; Tue, 10 Nov 2009 08:54:52 -0600 (CST) Date: Tue, 10 Nov 2009 08:54:52 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091109235441.GH27416@sun.com> To: Gary Winiger , Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <4AF97EBC.90406@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.325sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 5885 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? >> >> * 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. >> 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. 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. 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. > > 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. > >> 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. Well then they are logged in, and can use other tools to change the 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. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From William.Fiveash@sun.com Tue Nov 10 10:11:20 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAIBJZP018411 for ; Tue, 10 Nov 2009 10:11:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAAIBGXJ026649; Tue, 10 Nov 2009 18:11:17 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW0070RNUS6C00@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 11:11:16 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW003I4NURZ940@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 11:11:15 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAAHu8Ar014089; Tue, 10 Nov 2009 11:56:08 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAHu6px014088; Tue, 10 Nov 2009 11:56:06 -0600 (CST) Date: Tue, 10 Nov 2009 11:56:06 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF97EBC.90406@anl.gov> To: "Douglas E. Engert" Cc: Gary Winiger , Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: "Douglas E. Engert" , Gary Winiger , Darren.Moffat@sun.com, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091110175606.GJ27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 7663 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 From Wyllys.Ingersoll@Sun.COM Tue Nov 10 10:17:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAIHX2I018546 for ; Tue, 10 Nov 2009 10:17:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAAIHXwe010025 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Nov 2009 10:17:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00709O59T200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 11:17:33 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW003KQO58Z720@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 11:17:32 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAIHW29024734 for ; Tue, 10 Nov 2009 18:17:32 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSW00M00NAM5P00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 11:17:32 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSW00DUWO51G0D0@mail-amer.sun.com>; Tue, 10 Nov 2009 11:17:26 -0700 (MST) Date: Tue, 10 Nov 2009 13:17:25 -0500 From: Wyllys Ingersoll Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091110175606.GJ27416@sun.com> Sender: Wyllys.Ingersoll@Sun.COM To: "Douglas E. Engert" , Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <4AF9AE35.5060607@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> <20091110175606.GJ27416@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 574 > >> 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 really strongly dislike the idea of having a special password that causes it to behave differently. It just smells like a bad hack. -Wyllys From deengert@anl.gov Tue Nov 10 10:57:41 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAIvfQu019481 for ; Tue, 10 Nov 2009 10:57:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAAIvcFR055994; Tue, 10 Nov 2009 11:57:39 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00B0ZQ03SU00@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 11:57:39 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW003YXQ02ZD90@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 11:57:38 -0700 (MST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAIvccS026227; Tue, 10 Nov 2009 18:57:38 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-2046935; Tue, 10 Nov 2009 18:55:38 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-6614394; Tue, 10 Nov 2009 18:55:38 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay1i.sun.com with ESMTP id BT-MMP-12069164; Tue, 10 Nov 2009 18:55:38 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id C257671; Tue, 10 Nov 2009 12:55:37 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id B610270; Tue, 10 Nov 2009 12:55:37 -0600 (CST) Date: Tue, 10 Nov 2009 12:55:37 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF9AE35.5060607@sun.com> To: Wyllys Ingersoll Cc: Gary Winiger , darren.moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AF9B729.4090701@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> <20091110175606.GJ27416@sun.com> <4AF9AE35.5060607@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 1191 Wyllys Ingersoll wrote: >>> 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? Well with traditional pam if that password did not work the module would prompt again. 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 password. >> >> > > I really strongly dislike the idea of having a special password that causes > it to behave differently. It just smells like a bad hack. Yes, it is a hack, based on the current pam limitations of only prompting for user and password. A more flexible pam architecture could prompt for type of authentication the user wants to try. > > -Wyllys > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From William.Fiveash@sun.com Tue Nov 10 11:06:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAJ64ZY019592 for ; Tue, 10 Nov 2009 11:06:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nAAJ5ti0025080; Wed, 11 Nov 2009 03:06:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW0040DQDZTU00@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Nov 2009 11:05:59 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW00J2AQDX0Z90@nwk-avmta-2.sfbay.sun.com>; Tue, 10 Nov 2009 11:05:58 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAAIwNrU014511; Tue, 10 Nov 2009 12:58:23 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAIwNeH014510; Tue, 10 Nov 2009 12:58:23 -0600 (CST) Date: Tue, 10 Nov 2009 12:58:23 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091105200856.GF4337@sun.com> To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091110185823.GK27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 837 My fasttrack sponsor has requested I wrap up this discussion. Currently the only change to my original fasttrack proposal is the addition of the passwd_fallback option to pam_krb5 in pam.conf. In the pam_krb5(5) man page it is documented as: passwd_fallback Causes pam_krb5 to return PAM_IGNORE if it is doing PKINIT preauthentication and it is desired to try password based preauthentication if PKINIT fails. A second instance of pam_krb5 must follow pam_authtok_get if this option is used. I have submitted the diff marked man page containing that information earlier in this thread. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From deengert@anl.gov Tue Nov 10 11:25:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAJPXks020207 for ; Tue, 10 Nov 2009 11:25:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAAJPQaV018132; Tue, 10 Nov 2009 19:25:31 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00E0BRAHFP00@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 12:25:29 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW003P0RAGZDD0@brm-avmta-1.central.sun.com>; Tue, 10 Nov 2009 12:25:28 -0700 (MST) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAAJAuQl003271; Tue, 10 Nov 2009 19:25:28 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-117929; Tue, 10 Nov 2009 19:25:28 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-49426763; Tue, 10 Nov 2009 19:25:27 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay4i.sun.com with ESMTP id BT-MMP-3478214; Tue, 10 Nov 2009 19:25:27 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id D8E9F71; Tue, 10 Nov 2009 13:25:26 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id CA83812; Tue, 10 Nov 2009 13:25:26 -0600 (CST) Date: Tue, 10 Nov 2009 13:25:26 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091110175606.GJ27416@sun.com> To: "Douglas E. Engert" , Gary Winiger , Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <4AF9BE26.5060305@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.267sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> <20091110175606.GJ27416@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 10392 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 Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From William.Fiveash@Sun.COM Tue Nov 10 12:59:28 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAKxRRc022579 for ; Tue, 10 Nov 2009 12:59:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nAAKxLWn000943; Wed, 11 Nov 2009 04:59:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00F01VMXAZ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 12:59:21 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW0086GVMWVY40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 12:59:21 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAAKiGY0015165; Tue, 10 Nov 2009 14:44:16 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAKiG1T015163; Tue, 10 Nov 2009 14:44:16 -0600 (CST) Date: Tue, 10 Nov 2009 14:44:16 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF7F8FE.6030801@sun.com> To: Joerg Barfurth Cc: "Douglas E. Engert" , Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss , Wyllys Ingersoll , Will Fiveash Mail-followup-to: Joerg Barfurth , "Douglas E. Engert" , Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss , Wyllys Ingersoll Message-id: <20091110204416.GL27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <4AF3457C.4090306@anl.gov> <4AF7F8FE.6030801@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2497 On Mon, Nov 09, 2009 at 12:11:58PM +0100, Joerg Barfurth wrote: > Douglas E. Engert schrieb: > > >>>>> 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. > >>>> > > FWIW I feel uncomfortable with the idea that presence or absence of a > PAM_AUTHTOK will change the behavior of pam_krb5 substantially. So I'd > prefer a 'preauth' or 'pkinit' option here. That still doesn't change the fact that pam_krb5 would need to be stacked above pam_authtok_get to avoid a potentially unnecessary password prompt. See my other e-mail regarding pam_krb5 and auth stack ordering for my other points in regards to administration. > >>>> 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'll work on that and send it as a reply. > >> > >> While working out the various permutations of PAM auth stacks I've > >> discovered that my fasttrack was not complete in regards to new > >> interfaces. In order for the fall back to work properly from PKINIT to > >> password based preauth, pam_krb5 will need a user configurable option to > >> tell the first instance of pam_krb5 (doing PKINIT preauth) whether there > >> will be a second instance of pam_krb5 stacked below pam_authtok_get that > >> will try password preauth if PKINIT preauth fails. The idea is that if > >> the first instance of pam_krb5 (PKINIT) fails it will return PAM_IGNORE > >> if the fall back option is set to true (it would be false by default). > >> Otherwise the first instance of pam_krb5 (PKINIT) would return failure. > >> > > To me that sounds like something that should not require a module option. > Stack flow is controlled by the control flag part of the pam.conf entry. > > So if preauth failure is not fatal, it should simply be configured as > 'optional' or 'sufficient'. I discussed your point with my colleague Nico Williams and we agree that tha passwd_fallback option is unnecessary to implement fall back to password based krb preauth. Either sufficient or optional control flags can provide equivalent auth stack evaluations. I will amend my wrap up e-mail I sent earlier to withdraw the pam_fallback option. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Tue Nov 10 13:12:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAALCM4d022826 for ; Tue, 10 Nov 2009 13:12:23 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nAALCFog007094; Wed, 11 Nov 2009 05:12:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00H09W8F1300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 13:12:15 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW008E4W8EW240@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 13:12:14 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAAL4eZS015422; Tue, 10 Nov 2009 15:04:40 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAAL4ele015421; Tue, 10 Nov 2009 15:04:40 -0600 (CST) Date: Tue, 10 Nov 2009 15:04:40 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091110185823.GK27416@sun.com> To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091110210440.GM27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> <20091110185823.GK27416@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 26880 On Tue, Nov 10, 2009 at 12:58:23PM -0600, Will Fiveash wrote: > My fasttrack sponsor has requested I wrap up this discussion. Currently > the only change to my original fasttrack proposal is the addition of the > passwd_fallback option to pam_krb5 in pam.conf. In the pam_krb5(5) man > page it is documented as: > > passwd_fallback Causes pam_krb5 to return PAM_IGNORE if > it is doing PKINIT preauthentication and > it is desired to try password based > preauthentication if PKINIT fails. A > second instance of pam_krb5 must follow > pam_authtok_get if this option is used. > > I have submitted the diff marked man page containing that information > earlier in this thread. Based on comments from Joerg Barfurth I am withdrawing the proposed passwd_fallback option as it is not necessary. Here is the updated, diff marked pam_krb5(5) man page: --- pam_krb5_man_orig Fri Nov 6 14:47:20 2009 +++ pam_krb5_man_pkinit Tue Nov 10 15:02:45 2009 @@ -1,660 +1,797 @@ Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + PAM_AUTHTOK password item has not been set, which is + typically the case when pam_krb5 is stacked before + pam_authtok_get, the Kerberos V5 authentication module will + try to do PKINIT preauthentication if both the system and + the KDC are configured to support this type of + preauthentication. This form of preauthentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT preauthentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of preauthentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + + If the PAM_AUTHTOK password item has been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 + authentication module will only try password based + preauthentication. + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT preauthentication and fall + back to password based preauthentication then the sufficient + or optional control flags must be provided for the instance + of pam_krb5 stacked above pam_authtok_get and another + instance of pam_krb5 must be stacked below pam_authtok_get. + If there are PAM modules other than pam_krb5 that must be + evaluated below pam_authtok_get then the control flag should + be set to optional for the instance of pam_krb5 above + pam_authtok_get otherwise the control flag should be set to + sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module - has noted that the user's password has not expired. The fol- - lowing options may be passed in to the Kerberos V5 account - management module: + has noted that the user's password has not expired. This + does not apply if the module is using PKINIT + preauthentication. The following options may be passed in to + the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key - Distribution Center (KDC) database. The following flags may - be passed to pam_sm_chauthtok(3PAM): + Distribution Center (KDC) database. This does not apply if + the module is using PKINIT preauthentication. The following + flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based preauthentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based preauthentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf configuration file + that authenticates users through the Kerberos authentication + service and authenticates through the Unix login only if the + Kerberos authentication (using PKINIT) fails. This arrangement is + helpful when a majority of the users are networked by means of + Kerberos and when there are only a few non-Kerberos type user + accounts, such as root. The service illustrated below is for + dtlogin. Note, the user is prompted once for the PIN by pam_krb5. + + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_cred.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT preauth. + + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_krb5.so.1 + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth if they have a Kerberos account. Whether + pam_krb5 succeeds or fails the user must provide their Unix password + in order to login. + + dtlogin auth optional pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is able to + acquire a Kerberos credential via PKINT preauth and in addition must + provide their Unix password to pam_unix_auth. + + dtlogin auth required pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. If PKINIT succeeds the user will not be prompted for their + password. Note, if pam_krb5 PKINIT succeeds, the second instance of + pam_krb5 will not try password preauth and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth sufficient pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + + Example 9: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password preauth and will just return success. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will try + password based preauth and return success or failure. + + dtlogin auth optional pam_krb5.so.1 + dtlogin auth requisite pam_authtok_get.so.1 + dtlogin auth required pam_krb5.so.1 + dtlogin auth required pam_dhkeys.so.1 + dtlogin auth required pam_unix_cred.so.1 + dtlogin auth required pam_unix_auth.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or if that fails use pam_pkcs11 to + validate the user's PIN using their certificate and private + key. + + dtlogin auth sufficient pam_krb5.so.1 + dtlogin auth sufficient pam_pkcs11.so.1 + dtlogin auth required pam_unix_cred.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Darren.Moffat@sun.com Tue Nov 10 13:26:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAALQqF0023157 for ; Tue, 10 Nov 2009 13:26:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAALQj3r010433 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Nov 2009 21:26:51 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00I05WWOTO00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 13:26:48 -0800 (PST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW00839WWOVS40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 13:26:48 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAALQlWs006555 for ; Tue, 10 Nov 2009 21:26:47 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSW00100WMY0K00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 21:26:37 +0000 (GMT) Received: from [129.146.109.33] ([unknown] [129.146.109.33]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSW00E1UWW9I720@fe-emea-10.sun.com>; Tue, 10 Nov 2009 21:26:37 +0000 (GMT) Date: Tue, 10 Nov 2009 21:26:27 +0000 From: Darren J Moffat Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF9B729.4090701@anl.gov> Sender: Darren.Moffat@sun.com To: "Douglas E. Engert" Cc: Wyllys Ingersoll , Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AF9DA83.6060701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> <20091110175606.GJ27416@sun.com> <4AF9AE35.5060607@sun.com> <4AF9B729.4090701@anl.gov> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 1183 Douglas E. Engert wrote: >> I really strongly dislike the idea of having a special password that >> causes >> it to behave differently. It just smells like a bad hack. > > Yes, it is a hack, based on the current pam limitations of only prompting > for user and password. A more flexible pam architecture could prompt for > type > of authentication the user wants to try. There is nothing in the architecture or implementation of PAM that would stop pam_krb5 from doing that. A module can prompt for anything it likes it doesn't have to be restricted to just the standard PAM items. For example pam_krb5 could prompt the user to choose PKINIT or Password based auth when it starts. The prompting behaviour could be suppresesed and a choice made based on a module option. Or pam_krb5 could even use a new name=value pair in user_attr(4) that says wither PKINIT or password should be used for a given user. A generic change though of allowing the user to pick which auth stack they want to run (ie a set of modules configured by an admin) is a different mater though. The work on pam_eval and per user stacks would be helpful in that though. -- Darren J Moffat From Darren.Moffat@sun.com Tue Nov 10 13:43:03 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAALh2oF023217 for ; Tue, 10 Nov 2009 13:43:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAALh1k3012752 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 10 Nov 2009 13:43:02 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW0051DXNQ4F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 14:43:02 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW00IZ3XNOLL70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 14:43:01 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAALh0Xx025887 for ; Tue, 10 Nov 2009 21:43:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSW00L00XIMPF00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 10 Nov 2009 21:42:50 +0000 (GMT) Received: from [129.146.109.33] ([unknown] [129.146.109.33]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSW00JCJXN9KA30@fe-emea-09.sun.com>; Tue, 10 Nov 2009 21:42:50 +0000 (GMT) Date: Tue, 10 Nov 2009 21:42:39 +0000 From: Darren J Moffat Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091105200856.GF4337@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , Wyllys Ingersoll , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AF9DE4F.6030806@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910221256.n9MCu8fQ017623@borg.sfbay> <4AE08B0F.5090508@Sun.COM> <20091022215517.GA4337@sun.com> <20091105200856.GF4337@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091013) Status: RO Content-Length: 253 I'm happy with the latest spec that has been proposed. I think this is sufficient for now and it doesn't preclude adding module options or a krb5.conf stanza (or even user_attr(4) name=value pairs) to control this in the future. -- Darren J Moffat From deengert@anl.gov Tue Nov 10 14:02:43 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAAM2hnJ023991 for ; Tue, 10 Nov 2009 14:02:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAAM2c5k033746; Tue, 10 Nov 2009 15:02:41 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSW00001YKH7800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 14:02:41 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSW008WGYKHW270@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Nov 2009 14:02:41 -0800 (PST) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAALqBg4016311; Tue, 10 Nov 2009 22:02:40 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay11i.sun.com with ESMTP id BT-MMP-6348819; Tue, 10 Nov 2009 22:02:40 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-82655; Tue, 10 Nov 2009 22:02:40 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay1i.sun.com with ESMTP id BT-MMP-4765330; Tue, 10 Nov 2009 22:02:40 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id E66E27E; Tue, 10 Nov 2009 16:02:39 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id DAB7E7C; Tue, 10 Nov 2009 16:02:39 -0600 (CST) Date: Tue, 10 Nov 2009 16:02:39 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <4AF9DA83.6060701@Sun.COM> To: Darren J Moffat Cc: Wyllys Ingersoll , Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4AF9E2FF.8090004@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200911092220.nA9MKjIE016193@sac.sfbay.sun.com> <20091109235441.GH27416@sun.com> <4AF97EBC.90406@anl.gov> <20091110175606.GJ27416@sun.com> <4AF9AE35.5060607@sun.com> <4AF9B729.4090701@anl.gov> <4AF9DA83.6060701@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 2024 Darren J Moffat wrote: > Douglas E. Engert wrote: >>> I really strongly dislike the idea of having a special password that >>> causes >>> it to behave differently. It just smells like a bad hack. >> >> Yes, it is a hack, based on the current pam limitations of only prompting >> for user and password. A more flexible pam architecture could prompt >> for type >> of authentication the user wants to try. > > There is nothing in the architecture or implementation of PAM that would > stop pam_krb5 from doing that. A module can prompt for anything it > likes it doesn't have to be restricted to just the standard PAM items. I know that. But pam_authtok_get only prompts for user and password. I am arguing that if pam_authtok_get was enhanced to ask what type of authentication a users wants to try, it would be much more general, and all this special case use of pam_krb5 above or below pam_authtok_get would be much easier. I think I am arguing for what you are calling pam_eval below. > > For example pam_krb5 could prompt the user to choose PKINIT or Password > based auth when it starts. The prompting behaviour could be suppresesed > and a choice made based on a module option. Or pam_krb5 could even use > a new name=value pair in user_attr(4) that says wither PKINIT or > password should be used for a given user. Interesting says can work with LDAP too. The KDC might also be setup to only allow PKINIT and not a password for a user. > > A generic change though of allowing the user to pick which auth stack > they want to run (ie a set of modules configured by an admin) is a > different mater though. The work on pam_eval and per user stacks would > be helpful in that though. Yes, but it would have simplified this pam_krb5 changes. xscreensaver might still require pam_krb5 to do a prompt to give user a chance to insert the card... > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From gww@sac.sfbay.sun.com Wed Nov 11 16:06:04 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAC064YN011710 for ; Wed, 11 Nov 2009 16:06:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAC063pq007008 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 11 Nov 2009 17:06:04 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSY0000LYY3DQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Nov 2009 16:06:03 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSY00CVCYY2E590@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 11 Nov 2009 16:06:02 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAC060Fu026681; Wed, 11 Nov 2009 16:06:00 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAC060PF011707; Wed, 11 Nov 2009 16:06:00 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nAC060qE011706; Wed, 11 Nov 2009 16:06:00 -0800 (PST) Date: Wed, 11 Nov 2009 16:06:00 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] To: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <200911120006.nAC060qE011706@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2964 > I think this is > sufficient for now and it doesn't preclude adding module options or a > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > in the future. Hopefully pam_eval will be a longer term way of doing this. > I'm happy with the latest spec that has been proposed. I asked for through today at the meeting. Here's my summary: 1 I'm still uncomfortable with stacking pam_krb5 multiple times within the same stack type. IMO, it will lead to more confusion than the cost of generating a new module. I'll "hold my nose[tm]" here and hope the project team doesn't get customer calls. 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK to mean do PKINIT. See above. 3 In the case of stacking two pam_krb5(5) modules such that the first will pass through to pam_authtok_get(5), I'm unclear from the pam_sm_authenticate() spec what pam_authtok_get will do. Please specify what PAM items are set by the first instance so the admin knows what they will get from pam_authtok_get. I suspect there are two cases here: * PKINIT is not done, or fails; * PKINIT succeeds. 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied when PKINIT is done. Viz with the diff marks removed. Kerberos V5 Account Management Module The Kerberos account management component provides a function to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. This does not apply if the module is using PKINIT preauthentication. The following options may be passed in to the Kerberos V5 account management module: Does pam_sm_authenticate() fail? What the outcome of not applying account management? Does it mean accounts cannot be expired if PKINIT is used? 5 I'm still concerned that pam_sm_chauthtok() isn't applied when PKINIT is done. Viz with diff marks removed. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. This does not apply if the module is using PKINIT preauthentication. The following flags may be passed to pam_sm_chauthtok(3PAM): What does this mean to the example PAM password stack and kpasswd? 6 Nit, this project has a Minor release binding. Therefore it makes no sense to describe things in terms of dtlogin. 7 Has the project team coordianted with SunRay (SRSS) team (as the primary implementor of smartcards)? Has the project team coordinated with the TX team and how this may work/affect the multi-level desktop? Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they have been, please point me to where? I'll "hold my nose[tm]" relative to 1 and 2. Thanks for the extra time, Gary.. From Nicolas.Williams@sun.com Wed Nov 11 16:40:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAC0eeIO012557 for ; Wed, 11 Nov 2009 16:40:41 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAC0eZTq007341; Thu, 12 Nov 2009 00:40:40 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSZ00E010JR8B00@brm-avmta-1.central.sun.com>; Wed, 11 Nov 2009 17:40:39 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSZ00BS20JQ5430@brm-avmta-1.central.sun.com>; Wed, 11 Nov 2009 17:40:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAC0SxYM014609; Wed, 11 Nov 2009 18:28:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAC0SxmE014608; Wed, 11 Nov 2009 18:28:59 -0600 (CST) Date: Wed, 11 Nov 2009 18:28:59 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911120006.nAC060qE011706@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091112002859.GA1105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 4032 On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > I think this is > > sufficient for now and it doesn't preclude adding module options or a > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > in the future. > > Hopefully pam_eval will be a longer term way of doing this. These are the types of configurations one might want: - use PKINIT - use password-based auth - ask the KDC and evaluate a PAM config corresponding to the pre-auth required by the KDC - use pam_user_policy - ... pam_eval() helps with some. In the first two cases module options are needed. What this case does is select between PKINIT and password-based auth in a context-specific manner. > > I'm happy with the latest spec that has been proposed. > > I asked for through today at the meeting. Here's my summary: > > 3 In the case of stacking two pam_krb5(5) modules such that > the first will pass through to pam_authtok_get(5), I'm unclear > from the pam_sm_authenticate() spec what pam_authtok_get will > do. Please specify what PAM items are set by the first > instance so the admin knows what they will get from > pam_authtok_get. I suspect there are two cases here: > * PKINIT is not done, or fails; > * PKINIT succeeds. No PAM items are set by pam_krb5's auth module. If PAM_AUTHTOK is not set then it will try PKINIT, else it will try PA-ENC-TIMESTAMP. > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > when PKINIT is done. Viz with the diff marks removed. This: > Kerberos V5 Account Management Module > The Kerberos account management component provides a > function to perform account management, pam_sm_acct_mgmt(). > This function checks to see if the pam_krb5 authentication > module has noted that the user's password has not expired. >-------------->This does not apply if the module is using PKINIT >-------------->preauthentication. The following options may be passed in >-------------->to the Kerberos V5 account management module: Does not mean that no account authorization happens. It only means that when using PKINIT there is no password expiration, for semi-obvious reasons (a password wasn't used, and there may not be one). > Does pam_sm_authenticate() fail? What the outcome of not > applying account management? Does it mean accounts cannot be > expired if PKINIT is used? Account management does get applied, but in the PKINIT case there's nothing to do: in the PA-ENC-TIMESTAMP case the only thing done is to convert a KDC "key expired" error to PAM_NEW_AUTHTOK_REQD -- there's no equivalent for PKINIT. The KDC "key expired" error to PAM_NEW_AUTHTOK_REQD conversion is the only account management function that pam_krb5 ever implemented (it also calls the pam_krb5:pam_sm_authenticate() if pam_krb5_migrate was used, but that's orthogoanl here, and not really an authorization function). > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > when PKINIT is done. Viz with diff marks removed. > > Kerberos V5 Password Management Module > The Kerberos V5 password management component provides a > function to change passwords, pam_sm_chauthtok(), in the > Key Distribution Center (KDC) database. This does not > apply if the module is using PKINIT preauthentication. > The following flags may be passed to pam_sm_chauthtok(3PAM): > > What does this mean to the example PAM password stack and kpasswd? I think the above is wrong. That is, if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT. It may be good to make pam_krb5:pam_sm_chauthtok() return PAM_IGNORE if a) PKINIT was used and b) the KDC rejects the password change. (Will, I recommend making that change.) Nico -- From William.Fiveash@sun.com Thu Nov 12 13:12:12 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACLCCLN019779 for ; Thu, 12 Nov 2009 13:12:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nACLC7VN005097; Thu, 12 Nov 2009 13:12:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000C19LKAPN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 13:12:10 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000I8WLK81G40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 13:12:09 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACL4TKi026603; Thu, 12 Nov 2009 15:04:29 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACL4TDL026602; Thu, 12 Nov 2009 15:04:29 -0600 (CST) Date: Thu, 12 Nov 2009 15:04:29 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091112002859.GA1105@Sun.COM> To: Nicolas Williams Cc: Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Nicolas Williams , Gary Winiger , PSARC-ext@Sun.COM, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091112210429.GP27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> <20091112002859.GA1105@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 5045 On Wed, Nov 11, 2009 at 06:28:59PM -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > > sufficient for now and it doesn't preclude adding module options or a > > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > > in the future. > > > > Hopefully pam_eval will be a longer term way of doing this. > > These are the types of configurations one might want: > > - use PKINIT > - use password-based auth > - ask the KDC and evaluate a PAM config corresponding to the pre-auth > required by the KDC > - use pam_user_policy > - ... > > pam_eval() helps with some. In the first two cases module options are > needed. > > What this case does is select between PKINIT and password-based auth in > a context-specific manner. Correct. > > > I'm happy with the latest spec that has been proposed. > > > > I asked for through today at the meeting. Here's my summary: > > > > 3 In the case of stacking two pam_krb5(5) modules such that > > the first will pass through to pam_authtok_get(5), I'm unclear > > from the pam_sm_authenticate() spec what pam_authtok_get will > > do. Please specify what PAM items are set by the first > > instance so the admin knows what they will get from > > pam_authtok_get. I suspect there are two cases here: > > * PKINIT is not done, or fails; > > * PKINIT succeeds. > > No PAM items are set by pam_krb5's auth module. If PAM_AUTHTOK is not > set then it will try PKINIT, else it will try PA-ENC-TIMESTAMP. That is correct. > > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > > when PKINIT is done. Viz with the diff marks removed. > > This: > > > Kerberos V5 Account Management Module > > The Kerberos account management component provides a > > function to perform account management, pam_sm_acct_mgmt(). > > This function checks to see if the pam_krb5 authentication > > module has noted that the user's password has not expired. > >-------------->This does not apply if the module is using PKINIT > >-------------->preauthentication. The following options may be passed in > >-------------->to the Kerberos V5 account management module: > > Does not mean that no account authorization happens. It only means that > when using PKINIT there is no password expiration, for semi-obvious > reasons (a password wasn't used, and there may not be one). If the user's password is expired the KDC will send an error message whether the user tries PKINIT or password preauth. However a password is required to for pam_krb5 to verify so password fall back must be configured if this is a possibility. > > Does pam_sm_authenticate() fail? What the outcome of not > > applying account management? Does it mean accounts cannot be > > expired if PKINIT is used? > > Account management does get applied, but in the PKINIT case there's > nothing to do: in the PA-ENC-TIMESTAMP case the only thing done is to > convert a KDC "key expired" error to PAM_NEW_AUTHTOK_REQD -- there's no > equivalent for PKINIT. > > The KDC "key expired" error to PAM_NEW_AUTHTOK_REQD conversion is the > only account management function that pam_krb5 ever implemented (it also > calls the pam_krb5:pam_sm_authenticate() if pam_krb5_migrate was used, > but that's orthogoanl here, and not really an authorization function). Correct. > > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > > when PKINIT is done. Viz with diff marks removed. > > > > Kerberos V5 Password Management Module > > The Kerberos V5 password management component provides a > > function to change passwords, pam_sm_chauthtok(), in the > > Key Distribution Center (KDC) database. This does not > > apply if the module is using PKINIT preauthentication. > > The following flags may be passed to pam_sm_chauthtok(3PAM): > > > > What does this mean to the example PAM password stack and kpasswd? > > I think the above is wrong. That is, if some PAM module causes > pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app > subsequently calls pam_chauthtok(), pam_krb5 will change a user's > password. But this may well fail: the KDC may not want to allow a > PKINIT user to change/set a password since the user may be expected to > use PKINIT. It may be good to make pam_krb5:pam_sm_chauthtok() return > PAM_IGNORE if a) PKINIT was used and b) the KDC rejects the password > change. (Will, I recommend making that change.) I've made the modification such that if the pam_sm_authenticate in pam_krb5 did not use a password as is the case with PKINIT then pam_sm_chauthtok() will return PAM_IGNORE if: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Thu Nov 12 15:32:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACNWj72023573 for ; Thu, 12 Nov 2009 15:32:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nACNWgZM059877; Thu, 12 Nov 2009 16:32:44 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000707S2JJ900@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 15:32:43 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000MTOS2IH680@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 15:32:42 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACNP7WT027539; Thu, 12 Nov 2009 17:25:07 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACNP71o027538; Thu, 12 Nov 2009 17:25:07 -0600 (CST) Date: Thu, 12 Nov 2009 17:25:07 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091112210429.GP27416@sun.com> To: Nicolas Williams , Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Nicolas Williams , Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091112232507.GQ27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> <20091112002859.GA1105@Sun.COM> <20091112210429.GP27416@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1593 On Thu, Nov 12, 2009 at 03:04:29PM -0600, Will Fiveash wrote: > On Wed, Nov 11, 2009 at 06:28:59PM -0600, Nicolas Williams wrote: > > On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > > I think this is > > > > > Kerberos V5 Account Management Module > > > The Kerberos account management component provides a > > > function to perform account management, pam_sm_acct_mgmt(). > > > This function checks to see if the pam_krb5 authentication > > > module has noted that the user's password has not expired. > > >-------------->This does not apply if the module is using PKINIT > > >-------------->preauthentication. The following options may be passed in > > >-------------->to the Kerberos V5 account management module: > > > > Does not mean that no account authorization happens. It only means that > > when using PKINIT there is no password expiration, for semi-obvious > > reasons (a password wasn't used, and there may not be one). > > If the user's password is expired the KDC will send an error message > whether the user tries PKINIT or password preauth. However a password > is required to for pam_krb5 to verify so password fall back must be > configured if this is a possibility. I was wrong about the above (I was testing code changes). Even if pam_krb5 is configured to do PKINIT only in the auth stack, if the KDC indicates password expired the pam_krb5 account and password modules will function as they do now. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Thu Nov 12 15:48:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACNmcgt023834 for ; Thu, 12 Nov 2009 15:48:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nACNmKxT024476; Fri, 13 Nov 2009 07:48:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT00030RSSWQG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 15:48:32 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000IVESSV1EE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 15:48:32 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACNeudI027601; Thu, 12 Nov 2009 17:40:56 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACNeuhD027600; Thu, 12 Nov 2009 17:40:56 -0600 (CST) Date: Thu, 12 Nov 2009 17:40:56 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911120006.nAC060qE011706@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091112234056.GR27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 26449 On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > sufficient for now and it doesn't preclude adding module options or a > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > in the future. > > Hopefully pam_eval will be a longer term way of doing this. > > > I'm happy with the latest spec that has been proposed. > > I asked for through today at the meeting. Here's my summary: [points answered in other e-mail deleted] > 7 Has the project team coordianted with SunRay (SRSS) team > (as the primary implementor of smartcards)? Has the project > team coordinated with the TX team and how this may work/affect > the multi-level desktop? I am interacting with the SunRay team now and will check with the TX team. > Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they > have been, please point me to where? I'll "hold my nose[tm]" relative > to 1 and 2. > > Thanks for the extra time, Sure. Below is the updated pam_krb5(5) man page diffs: Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + PAM_AUTHTOK password item has not been set, which is + typically the case when pam_krb5 is stacked before + pam_authtok_get, the Kerberos V5 authentication module will + try to do PKINIT preauthentication if both the system and + the KDC are configured to support this type of + preauthentication. This form of preauthentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT preauthentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of preauthentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + pam_krb5 does not set any PAM items when doing PKINIT + authentication. + + If the PAM_AUTHTOK password item has been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 + authentication module will only try password based + preauthentication. + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT preauthentication and fall + back to password based preauthentication then the sufficient + or optional control flags must be provided for the instance + of pam_krb5 stacked above pam_authtok_get and another + instance of pam_krb5 must be stacked below pam_authtok_get. + If there are PAM modules other than pam_krb5 that must be + evaluated below pam_authtok_get then the control flag should + be set to optional for the instance of pam_krb5 above + pam_authtok_get otherwise the control flag should be set to + sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based preauthentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based preauthentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf configuration file + that authenticates users through the Kerberos authentication + service and authenticates through the Unix login only if the + Kerberos authentication (using PKINIT) fails. This arrangement is + helpful when a majority of the users are networked by means of + Kerberos and when there are only a few non-Kerberos type user + accounts, such as root. The service illustrated below is for + login. Note, the user is prompted once for the PIN by pam_krb5. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT preauth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth if they have a Kerberos account. Whether + pam_krb5 succeeds or fails the user must provide their Unix password + in order to login. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is able to + acquire a Kerberos credential via PKINT preauth and in addition must + provide their Unix password to pam_unix_auth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. If PKINIT succeeds the user will not be prompted for their + password. Note, if pam_krb5 PKINIT succeeds, the second instance of + pam_krb5 will not try password preauth and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + + Example 9: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password preauth and will just return success. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will try + password based preauth and return success or failure. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or if that fails use pam_pkcs11 to + validate the user's PIN using their certificate and private + key. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth sufficient pam_pkcs11.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@Sun.COM Thu Nov 12 16:11:54 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAD0Bs9f024633 for ; Thu, 12 Nov 2009 16:11:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAD0BqB6015181; Thu, 12 Nov 2009 17:11:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000A07TVSAI00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 16:11:52 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000M68TVSH6B0@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 16:11:52 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAD04GWO027801; Thu, 12 Nov 2009 18:04:16 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAD04GjC027800; Thu, 12 Nov 2009 18:04:16 -0600 (CST) Date: Thu, 12 Nov 2009 18:04:16 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911120006.nAC060qE011706@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091113000416.GS27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 5910 On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > sufficient for now and it doesn't preclude adding module options or a > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > in the future. > > Hopefully pam_eval will be a longer term way of doing this. > > > I'm happy with the latest spec that has been proposed. > > I asked for through today at the meeting. Here's my summary: > > 1 I'm still uncomfortable with stacking pam_krb5 multiple > times within the same stack type. IMO, it will lead > to more confusion than the cost of generating a new > module. I'll "hold my nose[tm]" here and hope the project > team doesn't get customer calls. > > 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK > to mean do PKINIT. See above. > > 3 In the case of stacking two pam_krb5(5) modules such that > the first will pass through to pam_authtok_get(5), I'm unclear > from the pam_sm_authenticate() spec what pam_authtok_get will > do. Please specify what PAM items are set by the first > instance so the admin knows what they will get from > pam_authtok_get. I suspect there are two cases here: > * PKINIT is not done, or fails; > * PKINIT succeeds. > > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > when PKINIT is done. Viz with the diff marks removed. > > Kerberos V5 Account Management Module > The Kerberos account management component provides a > function to perform account management, pam_sm_acct_mgmt(). > This function checks to see if the pam_krb5 authentication > module has noted that the user's password has not expired. > This does not apply if the module is using PKINIT > preauthentication. The following options may be passed in > to the Kerberos V5 account management module: > > Does pam_sm_authenticate() fail? What the outcome of not > applying account management? Does it mean accounts cannot be > expired if PKINIT is used? > > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > when PKINIT is done. Viz with diff marks removed. > > Kerberos V5 Password Management Module > The Kerberos V5 password management component provides a > function to change passwords, pam_sm_chauthtok(), in the > Key Distribution Center (KDC) database. This does not > apply if the module is using PKINIT preauthentication. > The following flags may be passed to pam_sm_chauthtok(3PAM): > > What does this mean to the example PAM password stack and kpasswd? > > 6 Nit, this project has a Minor release binding. Therefore > it makes no sense to describe things in terms of dtlogin. > > 7 Has the project team coordianted with SunRay (SRSS) team > (as the primary implementor of smartcards)? Has the project > team coordinated with the TX team and how this may work/affect > the multi-level desktop? > > Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they > have been, please point me to where? I'll "hold my nose[tm]" relative > to 1 and 2. Here is the updated fasttrack spec: 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: November 12, 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. pam_krb does not set any PAM items when doing PKINIT on the auth stack. 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. The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT. The other pam_krb5 modules (account and session) will not change. INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding new pam_krb5 options Committed Minor 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Wyllys.Ingersoll@sun.com Fri Nov 13 06:19:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nADEJkck021618 for ; Fri, 13 Nov 2009 06:19:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nADEJKTL015387 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Nov 2009 22:19:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT10010DX4T4000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 06:19:41 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT100FDNX4QHJ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 06:19:39 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nADEJcKk022077 for ; Fri, 13 Nov 2009 14:19:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT100I00WYPWP00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 07:19:38 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT1008SIX4QQEA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 07:19:38 -0700 (MST) Date: Fri, 13 Nov 2009 09:19:37 -0500 From: Wyllys Ingersoll Subject: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED Sender: Wyllys.Ingersoll@sun.com To: PSARC-ext , kerberos-discuss@opensolaris.org Message-id: <4AFD6AF9.5090407@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 156 The submitter has updated the spec and I believe all of the issues have been addressed. The timer expired yesterday, this case is now approved. -Wyllys From Wyllys.Ingersoll@sun.com Fri Nov 13 13:25:12 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nADEJkck021618 for ; Fri, 13 Nov 2009 06:19:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nADEJKTL015387 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Nov 2009 22:19:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT10010DX4T4000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 06:19:41 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT100FDNX4QHJ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 06:19:39 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nADEJcKk022077 for ; Fri, 13 Nov 2009 14:19:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KT100I00WYPWP00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 07:19:38 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KT1008SIX4QQEA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 07:19:38 -0700 (MST) Date: Fri, 13 Nov 2009 09:19:37 -0500 From: Wyllys Ingersoll Subject: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED Sender: Wyllys.Ingersoll@sun.com To: PSARC-ext , kerberos-discuss@opensolaris.org Message-id: <4AFD6AF9.5090407@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 156 The submitter has updated the spec and I believe all of the issues have been addressed. The timer expired yesterday, this case is now approved. -Wyllys From William.Fiveash@sun.com Fri Nov 13 13:30:33 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACNWj72023573 for ; Thu, 12 Nov 2009 15:32:46 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nACNWgZM059877; Thu, 12 Nov 2009 16:32:44 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000707S2JJ900@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 15:32:43 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000MTOS2IH680@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 15:32:42 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACNP7WT027539; Thu, 12 Nov 2009 17:25:07 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACNP71o027538; Thu, 12 Nov 2009 17:25:07 -0600 (CST) Date: Thu, 12 Nov 2009 17:25:07 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091112210429.GP27416@sun.com> To: Nicolas Williams , Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Nicolas Williams , Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091112232507.GQ27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> <20091112002859.GA1105@Sun.COM> <20091112210429.GP27416@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1593 On Thu, Nov 12, 2009 at 03:04:29PM -0600, Will Fiveash wrote: > On Wed, Nov 11, 2009 at 06:28:59PM -0600, Nicolas Williams wrote: > > On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > > I think this is > > > > > Kerberos V5 Account Management Module > > > The Kerberos account management component provides a > > > function to perform account management, pam_sm_acct_mgmt(). > > > This function checks to see if the pam_krb5 authentication > > > module has noted that the user's password has not expired. > > >-------------->This does not apply if the module is using PKINIT > > >-------------->preauthentication. The following options may be passed in > > >-------------->to the Kerberos V5 account management module: > > > > Does not mean that no account authorization happens. It only means that > > when using PKINIT there is no password expiration, for semi-obvious > > reasons (a password wasn't used, and there may not be one). > > If the user's password is expired the KDC will send an error message > whether the user tries PKINIT or password preauth. However a password > is required to for pam_krb5 to verify so password fall back must be > configured if this is a possibility. I was wrong about the above (I was testing code changes). Even if pam_krb5 is configured to do PKINIT only in the auth stack, if the KDC indicates password expired the pam_krb5 account and password modules will function as they do now. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Fri Nov 13 13:37:02 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACLCCLN019779 for ; Thu, 12 Nov 2009 13:12:12 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nACLC7VN005097; Thu, 12 Nov 2009 13:12:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000C19LKAPN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 13:12:10 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000I8WLK81G40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 13:12:09 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACL4TKi026603; Thu, 12 Nov 2009 15:04:29 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACL4TDL026602; Thu, 12 Nov 2009 15:04:29 -0600 (CST) Date: Thu, 12 Nov 2009 15:04:29 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <20091112002859.GA1105@Sun.COM> To: Nicolas Williams Cc: Gary Winiger , PSARC-ext@sun.com, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Nicolas Williams , Gary Winiger , PSARC-ext@Sun.COM, wyllys@borg.sfbay.sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091112210429.GP27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> <20091112002859.GA1105@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 5045 On Wed, Nov 11, 2009 at 06:28:59PM -0600, Nicolas Williams wrote: > On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > > sufficient for now and it doesn't preclude adding module options or a > > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > > in the future. > > > > Hopefully pam_eval will be a longer term way of doing this. > > These are the types of configurations one might want: > > - use PKINIT > - use password-based auth > - ask the KDC and evaluate a PAM config corresponding to the pre-auth > required by the KDC > - use pam_user_policy > - ... > > pam_eval() helps with some. In the first two cases module options are > needed. > > What this case does is select between PKINIT and password-based auth in > a context-specific manner. Correct. > > > I'm happy with the latest spec that has been proposed. > > > > I asked for through today at the meeting. Here's my summary: > > > > 3 In the case of stacking two pam_krb5(5) modules such that > > the first will pass through to pam_authtok_get(5), I'm unclear > > from the pam_sm_authenticate() spec what pam_authtok_get will > > do. Please specify what PAM items are set by the first > > instance so the admin knows what they will get from > > pam_authtok_get. I suspect there are two cases here: > > * PKINIT is not done, or fails; > > * PKINIT succeeds. > > No PAM items are set by pam_krb5's auth module. If PAM_AUTHTOK is not > set then it will try PKINIT, else it will try PA-ENC-TIMESTAMP. That is correct. > > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > > when PKINIT is done. Viz with the diff marks removed. > > This: > > > Kerberos V5 Account Management Module > > The Kerberos account management component provides a > > function to perform account management, pam_sm_acct_mgmt(). > > This function checks to see if the pam_krb5 authentication > > module has noted that the user's password has not expired. > >-------------->This does not apply if the module is using PKINIT > >-------------->preauthentication. The following options may be passed in > >-------------->to the Kerberos V5 account management module: > > Does not mean that no account authorization happens. It only means that > when using PKINIT there is no password expiration, for semi-obvious > reasons (a password wasn't used, and there may not be one). If the user's password is expired the KDC will send an error message whether the user tries PKINIT or password preauth. However a password is required to for pam_krb5 to verify so password fall back must be configured if this is a possibility. > > Does pam_sm_authenticate() fail? What the outcome of not > > applying account management? Does it mean accounts cannot be > > expired if PKINIT is used? > > Account management does get applied, but in the PKINIT case there's > nothing to do: in the PA-ENC-TIMESTAMP case the only thing done is to > convert a KDC "key expired" error to PAM_NEW_AUTHTOK_REQD -- there's no > equivalent for PKINIT. > > The KDC "key expired" error to PAM_NEW_AUTHTOK_REQD conversion is the > only account management function that pam_krb5 ever implemented (it also > calls the pam_krb5:pam_sm_authenticate() if pam_krb5_migrate was used, > but that's orthogoanl here, and not really an authorization function). Correct. > > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > > when PKINIT is done. Viz with diff marks removed. > > > > Kerberos V5 Password Management Module > > The Kerberos V5 password management component provides a > > function to change passwords, pam_sm_chauthtok(), in the > > Key Distribution Center (KDC) database. This does not > > apply if the module is using PKINIT preauthentication. > > The following flags may be passed to pam_sm_chauthtok(3PAM): > > > > What does this mean to the example PAM password stack and kpasswd? > > I think the above is wrong. That is, if some PAM module causes > pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app > subsequently calls pam_chauthtok(), pam_krb5 will change a user's > password. But this may well fail: the KDC may not want to allow a > PKINIT user to change/set a password since the user may be expected to > use PKINIT. It may be good to make pam_krb5:pam_sm_chauthtok() return > PAM_IGNORE if a) PKINIT was used and b) the KDC rejects the password > change. (Will, I recommend making that change.) I've made the modification such that if the pam_sm_authenticate in pam_krb5 did not use a password as is the case with PKINIT then pam_sm_chauthtok() will return PAM_IGNORE if: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Fri Nov 13 13:38:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAD0Bs9f024633 for ; Thu, 12 Nov 2009 16:11:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nAD0BqB6015181; Thu, 12 Nov 2009 17:11:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT000A07TVSAI00@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 16:11:52 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000M68TVSH6B0@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Nov 2009 16:11:52 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAD04GWO027801; Thu, 12 Nov 2009 18:04:16 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAD04GjC027800; Thu, 12 Nov 2009 18:04:16 -0600 (CST) Date: Thu, 12 Nov 2009 18:04:16 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911120006.nAC060qE011706@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, wyllys@borg.sfbay.sun.com Message-id: <20091113000416.GS27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 5910 On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > sufficient for now and it doesn't preclude adding module options or a > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > in the future. > > Hopefully pam_eval will be a longer term way of doing this. > > > I'm happy with the latest spec that has been proposed. > > I asked for through today at the meeting. Here's my summary: > > 1 I'm still uncomfortable with stacking pam_krb5 multiple > times within the same stack type. IMO, it will lead > to more confusion than the cost of generating a new > module. I'll "hold my nose[tm]" here and hope the project > team doesn't get customer calls. > > 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK > to mean do PKINIT. See above. > > 3 In the case of stacking two pam_krb5(5) modules such that > the first will pass through to pam_authtok_get(5), I'm unclear > from the pam_sm_authenticate() spec what pam_authtok_get will > do. Please specify what PAM items are set by the first > instance so the admin knows what they will get from > pam_authtok_get. I suspect there are two cases here: > * PKINIT is not done, or fails; > * PKINIT succeeds. > > 4 I'm still concerned that pam_sm_acct_mgmt() isn't applied > when PKINIT is done. Viz with the diff marks removed. > > Kerberos V5 Account Management Module > The Kerberos account management component provides a > function to perform account management, pam_sm_acct_mgmt(). > This function checks to see if the pam_krb5 authentication > module has noted that the user's password has not expired. > This does not apply if the module is using PKINIT > preauthentication. The following options may be passed in > to the Kerberos V5 account management module: > > Does pam_sm_authenticate() fail? What the outcome of not > applying account management? Does it mean accounts cannot be > expired if PKINIT is used? > > 5 I'm still concerned that pam_sm_chauthtok() isn't applied > when PKINIT is done. Viz with diff marks removed. > > Kerberos V5 Password Management Module > The Kerberos V5 password management component provides a > function to change passwords, pam_sm_chauthtok(), in the > Key Distribution Center (KDC) database. This does not > apply if the module is using PKINIT preauthentication. > The following flags may be passed to pam_sm_chauthtok(3PAM): > > What does this mean to the example PAM password stack and kpasswd? > > 6 Nit, this project has a Minor release binding. Therefore > it makes no sense to describe things in terms of dtlogin. > > 7 Has the project team coordianted with SunRay (SRSS) team > (as the primary implementor of smartcards)? Has the project > team coordinated with the TX team and how this may work/affect > the multi-level desktop? > > Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they > have been, please point me to where? I'll "hold my nose[tm]" relative > to 1 and 2. Here is the updated fasttrack spec: 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: November 12, 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. pam_krb does not set any PAM items when doing PKINIT on the auth stack. 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. The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT. The other pam_krb5 modules (account and session) will not change. INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding new pam_krb5 options Committed Minor 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Fri Nov 13 13:41:26 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nACNmcgt023834 for ; Thu, 12 Nov 2009 15:48:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nACNmKxT024476; Fri, 13 Nov 2009 07:48:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT00030RSSWQG00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 15:48:32 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT000IVESSV1EE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 12 Nov 2009 15:48:32 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nACNeudI027601; Thu, 12 Nov 2009 17:40:56 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nACNeuhD027600; Thu, 12 Nov 2009 17:40:56 -0600 (CST) Date: Thu, 12 Nov 2009 17:40:56 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] pam_krb5 PKINIT support [PSARC/2009/576 FastTrack timeout 10/29/2009] In-reply-to: <200911120006.nAC060qE011706@sac.sfbay.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Gary Winiger , Darren.Moffat@Sun.COM, PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091112234056.GR27416@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911120006.nAC060qE011706@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 26449 On Wed, Nov 11, 2009 at 04:06:00PM -0800, Gary Winiger wrote: > > > I think this is > > sufficient for now and it doesn't preclude adding module options or a > > krb5.conf stanza (or even user_attr(4) name=value pairs) to control this > > in the future. > > Hopefully pam_eval will be a longer term way of doing this. > > > I'm happy with the latest spec that has been proposed. > > I asked for through today at the meeting. Here's my summary: [points answered in other e-mail deleted] > 7 Has the project team coordianted with SunRay (SRSS) team > (as the primary implementor of smartcards)? Has the project > team coordinated with the TX team and how this may work/affect > the multi-level desktop? I am interacting with the SunRay team now and will check with the TX team. > Bottom line, IMO, 3, 4 and 5 need to be addressed in the spec. If they > have been, please point me to where? I'll "hold my nose[tm]" relative > to 1 and 2. > > Thanks for the extra time, Sure. Below is the updated pam_krb5(5) man page diffs: Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + PAM_AUTHTOK password item has not been set, which is + typically the case when pam_krb5 is stacked before + pam_authtok_get, the Kerberos V5 authentication module will + try to do PKINIT preauthentication if both the system and + the KDC are configured to support this type of + preauthentication. This form of preauthentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT preauthentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of preauthentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + pam_krb5 does not set any PAM items when doing PKINIT + authentication. + + If the PAM_AUTHTOK password item has been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked after pam_authtok_get, the Kerberos V5 + authentication module will only try password based + preauthentication. + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT preauthentication and fall + back to password based preauthentication then the sufficient + or optional control flags must be provided for the instance + of pam_krb5 stacked above pam_authtok_get and another + instance of pam_krb5 must be stacked below pam_authtok_get. + If there are PAM modules other than pam_krb5 that must be + evaluated below pam_authtok_get then the control flag should + be set to optional for the instance of pam_krb5 above + pam_authtok_get otherwise the control flag should be set to + sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based preauthentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based preauthentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based preauthentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf configuration file + that authenticates users through the Kerberos authentication + service and authenticates through the Unix login only if the + Kerberos authentication (using PKINIT) fails. This arrangement is + helpful when a majority of the users are networked by means of + Kerberos and when there are only a few non-Kerberos type user + accounts, such as root. The service illustrated below is for + login. Note, the user is prompted once for the PIN by pam_krb5. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT preauth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth if they have a Kerberos account. Whether + pam_krb5 succeeds or fails the user must provide their Unix password + in order to login. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is able to + acquire a Kerberos credential via PKINT preauth and in addition must + provide their Unix password to pam_unix_auth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. If PKINIT succeeds the user will not be prompted for their + password. Note, if pam_krb5 PKINIT succeeds, the second instance of + pam_krb5 will not try password preauth and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + + Example 9: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or using password based preauth if PKINIT + fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password preauth and will just return success. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will try + password based preauth and return success or failure. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos credential + using PKINIT preauth or if that fails use pam_pkcs11 to + validate the user's PIN using their certificate and private + key. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth sufficient pam_pkcs11.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From gww@eng.sun.com Fri Nov 13 14:29:06 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nADMT6KV004015 for ; Fri, 13 Nov 2009 14:29:06 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nADMT6Og022729 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 13 Nov 2009 14:29:06 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT20021ZJSIUM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 15:29:06 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT2009GGJSHFIC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 13 Nov 2009 15:29:06 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nADMT52T009724; Fri, 13 Nov 2009 14:29:05 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id nADMSn1t010829; Fri, 13 Nov 2009 14:28:49 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id nADMSnL3010828; Fri, 13 Nov 2009 14:28:49 -0800 (PST) Date: Fri, 13 Nov 2009 14:28:49 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED To: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys.Ingersoll@sun.com Message-id: <200911132228.nADMSnL3010828@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 477 > The submitter has updated the spec and I believe all of the issues have > been addressed. The timer expired yesterday, this case is now > approved. I believe this is premature. In any case Darren and I discussed things Wed afternoon and came up with a number of points. Since he was traveling, I was going to send them. I've not had the chance to do so yet. I'll review whter the case stands by next meeting to ensure the outstanding issues are resolved. Gary.. From gww@sac.sfbay.sun.com Tue Nov 17 13:58:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHLwb5d006580 for ; Tue, 17 Nov 2009 13:58:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nAHLwWxx002078 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 17 Nov 2009 21:58:37 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KT900G17X1O1S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 14:58:36 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KT900LDVX1NWDD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 17 Nov 2009 14:58:35 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAHLwWFH022116; Tue, 17 Nov 2009 13:58:32 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAHLwWlR006577; Tue, 17 Nov 2009 13:58:32 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nAHLwWh9006576; Tue, 17 Nov 2009 13:58:32 -0800 (PST) Date: Tue, 17 Nov 2009 13:58:32 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED To: PSARC-ext@sun.com, Wyllys.Ingersoll@sun.com, gww@eng.sun.com, kerberos-discuss@opensolaris.org Message-id: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO > > The submitter has updated the spec and I believe all of the issues have > > been addressed. The timer expired yesterday, this case is now > > approved. > > I believe this is premature. In any case Darren and I discussed > things Wed afternoon and came up with a number of points. Again thanks for the time to do another review. I split out the "final" man page into the case directory for easier viewing. Using it as the "final" spec along with pkinit-final.txt, unfortunately, I believe there are still open issues. I've been told the project team is on holiday. I'll move the timer to 3 Dec if the project team is not at the next PSARC meeting. As I said, Darren and I chatted last week. (I'm sure he'll correct me if I've misstated our conversation.) I also received unsolicited mail from someone in the Sun field who supports large customers stating that PAM is difficult enough to configure, so my previous points 1 and 2 should not be taken lightly. That was also part of Darren and my discussion. 1 I'm still uncomfortable with stacking pam_krb5 multiple times within the same stack type. IMO, it will lead to more confusion than the cost of generating a new module. I'll "hold my nose[tm]" here and hope the project team doesn't get customer calls. 2 I'm uncomfortable about keying off of an empty PAM_AUTHTOK to mean do PKINIT. See above. With this input in mind, I'm no longer comfortable holding my nose and feel TCR strong about having this resolved. Darren and I believe there are straight forward solutions to 1-2: * provide a separate pam_pkinit module (my and the field person's preference), * add a "pkinit" option to pam_krb5. and do not key off of an empty PAM_AUTHTOK. I feel TCA strong about the separate module. Given the project's schedule, according to the manager, first chance to integrate isn't until 2010/02, I believe factoring the code, most of which is library, into a separate module is doable and the cleanest way to view a pam.conf configuration. The man page and pkinit-final differ with respect to keying off of PAM items: "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." I assume that the man page is accurate and only PAM_AUTHOTK is keyed (recall the TCR strongness to resolve this as above). Relative to my previous point 3 3 In the case of stacking two pam_krb5(5) modules such that the first will pass through to pam_authtok_get(5), I'm unclear from the pam_sm_authenticate() spec what pam_authtok_get will do. Please specify what PAM items are set by the first instance so the admin knows what they will get from pam_authtok_get. I suspect there are two cases here: * PKINIT is not done, or fails; * PKINIT succeeds. The man page seems silent, however pkinit-final says: "pam_krb does not set any PAM items when doing PKINIT on the auth stack." Independent of how pkinit is stacked, PAM_USER must be set to the authenticated user's name if the auth stack succeeds. Perhaps I've missed something in my reading, I don't see where PAM_USER is set by this proposal. (Calling pam_get_user(3) ensures that PAM_USER is set ;-) Viz: + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 >From pkinit-final: "The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT." This information does not seem to be in the man page. How does the administrator know it? Not being a pkinit expert, I'd like to understand how the password stack will know if the user was authenticated by pkinit? I feel TCR strong that the man page needs to be complete relative to this part of the spec. I'm also concerned that pam_krb5 in the password stack won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set. Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK will be making these checks? >From pkinit-final: "The other pam_krb5 modules (account and session) will not change." >From the man page: "Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module:" If pam_sm_acct_mgmt() is unchanged, what is it that the "pam_krb5 authentication module" has told pam_sm_acct_mgmt? How does this all interact with pkinit? >From pkinit-final: "Interface Stability Release Binding new pam_krb5 options Committed Minor" Nit, I presume the new options is a typo. My personal recommendation: Develop a pam_pkinit (or similarly named) module with a separate man page. Have that man page describe the interactions between pam_pkinit and pam_krb5. Thanks for the extra time, Gary.. From Wyllys.Ingersoll@sun.com Wed Nov 18 13:50:22 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAILoM1q028027 for ; Wed, 18 Nov 2009 13:50:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAILoMPS016730 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 18 Nov 2009 13:50:22 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTB00F05RBYWD00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 13:50:22 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTB0055LRBXXLF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 13:50:21 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAILoLjc006068 for ; Wed, 18 Nov 2009 21:50:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTB00I00QQKCO00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 18 Nov 2009 14:50:21 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTB00M8QRBUIU40@mail-amer.sun.com>; Wed, 18 Nov 2009 14:50:18 -0700 (MST) Date: Wed, 18 Nov 2009 16:50:18 -0500 From: Wyllys Ingersoll Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> Sender: Wyllys.Ingersoll@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, gww@eng.sun.com, kerberos-discuss@opensolaris.org Message-id: <4B046C1A.4090409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 692 Gary Winiger wrote: > > My personal recommendation: Develop a pam_pkinit (or similarly named) module > with a separate man page. Have that man page describe the interactions > between pam_pkinit and pam_krb5. > > Thanks for the extra time, > Gary.. Will F is on vacation for a bit longer. I believe the main reason he did not want to create a new module was that it would result in an almost identical body of code. Perhaps the existing pam_krb5 tree can be refactored or the build process could be modified so that the 2 modules (should he choose to take your advice) share a common body of code except for the places where the logic differs for standard krb5 vs pkinit. -Wyllys From Darren.Moffat@sun.com Thu Nov 19 01:51:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAJ9pR8x028604 for ; Thu, 19 Nov 2009 01:51:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nAJ9pPDh028967 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Nov 2009 02:51:27 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTC00F0XOPQ0W00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 02:51:26 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTC0019POPQX780@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 02:51:26 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJ9pO3R004388 for ; Thu, 19 Nov 2009 09:51:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00000N4VYN00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 09:51:13 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTC00C91OP2XT80@fe-emea-09.sun.com>; Thu, 19 Nov 2009 09:51:02 +0000 (GMT) Date: Thu, 19 Nov 2009 09:51:01 +0000 From: Darren J Moffat Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <4B046C1A.4090409@sun.com> Sender: Darren.Moffat@sun.com To: Wyllys Ingersoll Cc: Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, gww@eng.sun.com Message-id: <4B051505.1010406@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> <4B046C1A.4090409@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 1083 Wyllys Ingersoll wrote: > Gary Winiger wrote: > >> My personal recommendation: Develop a pam_pkinit (or similarly named) module >> with a separate man page. Have that man page describe the interactions >> between pam_pkinit and pam_krb5. >> >> Thanks for the extra time, >> Gary.. > > > Will F is on vacation for a bit longer. I believe the main reason he did not > want to create a new module was that it would result in an almost identical > body of code. Perhaps the existing pam_krb5 tree can be refactored or > the build process could be modified so that the 2 modules (should he choose > to take your advice) share a common body of code except for the places > where the logic differs for standard krb5 vs pkinit. Hence my suggestion of keeping pam_krb5 as is and using a pkinit module option. I personally think this is a perfect use case for module options and I think that in the long run having two separate modules will actually turned out to be a problem. So I would prefer a pkinit module option, that should be trivial to implement. -- Darren J Moffat From Wyllys.Ingersoll@sun.com Thu Nov 19 06:22:37 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAJEMbbP005245 for ; Thu, 19 Nov 2009 06:22:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJEMaFi004938 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Nov 2009 06:22:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTD00D3919O8B00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 06:22:36 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTD00C6219MIJ10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 06:22:35 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAJEMYaa020249 for ; Thu, 19 Nov 2009 14:22:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTD00K0014YE500@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 07:22:34 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTD00J5819DK520@mail-amer.sun.com>; Thu, 19 Nov 2009 07:22:26 -0700 (MST) Date: Thu, 19 Nov 2009 09:22:25 -0500 From: Wyllys Ingersoll Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <4B051505.1010406@Sun.COM> Sender: Wyllys.Ingersoll@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, gww@eng.sun.com Message-id: <4B0554A1.709@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> <4B046C1A.4090409@sun.com> <4B051505.1010406@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1438 Darren J Moffat wrote: > Wyllys Ingersoll wrote: >> Gary Winiger wrote: >> >>> My personal recommendation: Develop a pam_pkinit (or similarly >>> named) module >>> with a separate man page. Have that man page describe the interactions >>> between pam_pkinit and pam_krb5. >>> >>> Thanks for the extra time, >>> Gary.. >> >> >> Will F is on vacation for a bit longer. I believe the main reason he >> did not >> want to create a new module was that it would result in an almost >> identical >> body of code. Perhaps the existing pam_krb5 tree can be refactored or >> the build process could be modified so that the 2 modules (should he >> choose >> to take your advice) share a common body of code except for the places >> where the logic differs for standard krb5 vs pkinit. > > Hence my suggestion of keeping pam_krb5 as is and using a pkinit module > option. > > I personally think this is a perfect use case for module options and I > think that in the long run having two separate modules will actually > turned out to be a problem. So I would prefer a pkinit module option, > that should be trivial to implement. > I would be OK with adding options in this case as well. Having the options visible in the pam.conf would make it obvious to the admin that the 2 instances in the stack have different uses and would, I think, address Gary's concern about confusion over having 2 pam_krb5 entries in the same stack. -Wyllys From Darren.Moffat@Sun.COM Thu Nov 19 06:29:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAJETjdj005430 for ; Thu, 19 Nov 2009 06:29:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJETiRG021287 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Nov 2009 06:29:44 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTD00L0D1LJ9X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 07:29:43 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTD00IDU1LIU020@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 07:29:43 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJETfx2026965 for ; Thu, 19 Nov 2009 14:29:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00H00ZR93400@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 14:29:30 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTD003YN1L21B40@fe-emea-10.sun.com>; Thu, 19 Nov 2009 14:29:26 +0000 (GMT) Date: Thu, 19 Nov 2009 14:29:26 +0000 From: Darren J Moffat Subject: Re: PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <4B0554A1.709@sun.com> Sender: Darren.Moffat@Sun.COM To: Wyllys Ingersoll Cc: Gary Winiger , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, gww@eng.sun.com Message-id: <4B055646.8070000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> <4B046C1A.4090409@sun.com> <4B051505.1010406@Sun.COM> <4B0554A1.709@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 2082 Wyllys Ingersoll wrote: > Darren J Moffat wrote: >> Wyllys Ingersoll wrote: >>> Gary Winiger wrote: >>> >>>> My personal recommendation: Develop a pam_pkinit (or similarly >>>> named) module >>>> with a separate man page. Have that man page describe the interactions >>>> between pam_pkinit and pam_krb5. >>>> >>>> Thanks for the extra time, >>>> Gary.. >>> >>> Will F is on vacation for a bit longer. I believe the main reason he >>> did not >>> want to create a new module was that it would result in an almost >>> identical >>> body of code. Perhaps the existing pam_krb5 tree can be refactored or >>> the build process could be modified so that the 2 modules (should he >>> choose >>> to take your advice) share a common body of code except for the places >>> where the logic differs for standard krb5 vs pkinit. >> Hence my suggestion of keeping pam_krb5 as is and using a pkinit module >> option. >> >> I personally think this is a perfect use case for module options and I >> think that in the long run having two separate modules will actually >> turned out to be a problem. So I would prefer a pkinit module option, >> that should be trivial to implement. >> > > I would be OK with adding options in this case as well. Having the options > visible in the pam.conf would make it obvious to the admin that the > 2 instances in the stack have different uses and would, I think, address > Gary's concern about confusion over having 2 pam_krb5 entries in the > same stack. Indeed, the difference is syntax more than anything else eg: other auth required pam_krb5.so pkinit versus other auth required pam_krb5_pkinit.so White space versus an underscore. I like module options, when used properly, and to me this is a perfect case of proper use of a module option. The code for password based versus PKINIT based Kerberos authentication is in the very high 90% range of common code, in fact it is pretty much just a flag to a lower level API. Gary however seems to prefer a separate module with the common code factored into a library. -- Darren J Moffat From William.Fiveash@sun.com Thu Nov 19 14:31:33 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAJMVXYa023645 for ; Thu, 19 Nov 2009 14:31:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAJMVWcD002725 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 19 Nov 2009 14:31:33 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTD00I1PNWKPT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 14:31:32 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTD00CDLNWHVT60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 14:31:29 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nAJMVTVs015267 for ; Thu, 19 Nov 2009 22:31:29 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTD00M00NMN6I00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 19 Nov 2009 15:31:29 -0700 (MST) Received: from [192.168.1.100] ([unknown] [205.172.16.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTD0071FNWFX2C0@mail-amer.sun.com>; Thu, 19 Nov 2009 15:31:28 -0700 (MST) Date: Thu, 19 Nov 2009 12:31:25 -1000 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <4B055646.8070000@Sun.COM> Sender: William.Fiveash@sun.com To: Darren J Moffat Cc: Will Fiveash , Wyllys Ingersoll , PSARC-ext@sun.com, gww@eng.sun.com, Gary Winiger , kerberos-discuss@opensolaris.org Message-id: <8BE11C58-13A8-46CB-9FF9-CFC1030A285E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> <4B046C1A.4090409@sun.com> <4B051505.1010406@Sun.COM> <4B0554A1.709@sun.com> <4B055646.8070000@Sun.COM> Status: RO Content-Length: 2752 On Nov 19, 2009, at 4:29 AM, Darren J Moffat wrote: > Wyllys Ingersoll wrote: >> Darren J Moffat wrote: >>> Wyllys Ingersoll wrote: >>>> Gary Winiger wrote: >>>> >>>>> My personal recommendation: Develop a pam_pkinit (or similarly >>>>> named) module >>>>> with a separate man page. Have that man page describe the >>>>> interactions >>>>> between pam_pkinit and pam_krb5. >>>>> >>>>> Thanks for the extra time, >>>>> Gary.. >>>> >>>> Will F is on vacation for a bit longer. I believe the main >>>> reason he >>>> did not >>>> want to create a new module was that it would result in an almost >>>> identical >>>> body of code. Perhaps the existing pam_krb5 tree can be >>>> refactored or >>>> the build process could be modified so that the 2 modules (should >>>> he >>>> choose >>>> to take your advice) share a common body of code except for the >>>> places >>>> where the logic differs for standard krb5 vs pkinit. >>> Hence my suggestion of keeping pam_krb5 as is and using a pkinit >>> module >>> option. >>> >>> I personally think this is a perfect use case for module options >>> and I >>> think that in the long run having two separate modules will actually >>> turned out to be a problem. So I would prefer a pkinit module >>> option, >>> that should be trivial to implement. >>> >> I would be OK with adding options in this case as well. Having >> the options >> visible in the pam.conf would make it obvious to the admin that the >> 2 instances in the stack have different uses and would, I think, >> address >> Gary's concern about confusion over having 2 pam_krb5 entries in the >> same stack. > > Indeed, the difference is syntax more than anything else eg: > > other auth required pam_krb5.so pkinit > > versus > > other auth required pam_krb5_pkinit.so > > White space versus an underscore. I like module options, when used > properly, and to me this is a perfect case of proper use of a module > option. The code for password based versus PKINIT based Kerberos > authentication is in the very high 90% range of common code, in fact > it is pretty much just a flag to a lower level API. Gary however > seems to prefer a separate module with the common code factored into > a library. I have to agree with the analysis that supporting a "pkinit" module argument is very easy. Note that so far my implementation of pkinit support in our pam_krb5 is about 50 new lines of code. Taking the other approach of refactoring the common code in to a lib shared between pam_krb5.so and pam_krb5_pkinit.so would be significantly more work with more opportunity for bugs I believe. Note, I'm on vacation until Nov 30. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT) From Nicolas.Williams@sun.com Fri Nov 20 09:35:58 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nAKHZvf9028819 for ; Fri, 20 Nov 2009 09:35:58 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nAKHZsfd019800; Fri, 20 Nov 2009 09:35:56 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KTF007074VVCT00@brm-avmta-1.central.sun.com>; Fri, 20 Nov 2009 10:35:55 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KTF001FO4VVMZ30@brm-avmta-1.central.sun.com>; Fri, 20 Nov 2009 10:35:55 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nAKHOFJn002953; Fri, 20 Nov 2009 11:24:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nAKHOFCN002952; Fri, 20 Nov 2009 11:24:15 -0600 (CST) Date: Fri, 20 Nov 2009 11:24:15 -0600 From: Nicolas Williams Subject: Re: [kerberos-discuss] PSARC 2009/576 pam_krb5 PKINIT support - APPROVED In-reply-to: <8BE11C58-13A8-46CB-9FF9-CFC1030A285E@sun.com> To: Will Fiveash Cc: Darren J Moffat , kerberos-discuss@opensolaris.org, gww@eng.sun.com, PSARC-ext@sun.com, Gary Winiger Message-id: <20091120172415.GB773@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200911172158.nAHLwWh9006576@sac.sfbay.sun.com> <4B046C1A.4090409@sun.com> <4B051505.1010406@Sun.COM> <4B0554A1.709@sun.com> <4B055646.8070000@Sun.COM> <8BE11C58-13A8-46CB-9FF9-CFC1030A285E@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 642 On Thu, Nov 19, 2009 at 12:31:25PM -1000, Will Fiveash wrote: > I have to agree with the analysis that supporting a "pkinit" module > argument is very easy. Note that so far my implementation of pkinit > support in our pam_krb5 is about 50 new lines of code. Taking the > other approach of refactoring the common code in to a lib shared > between pam_krb5.so and pam_krb5_pkinit.so would be significantly more > work with more opportunity for bugs I believe. For me it's all the same. PAM configuration is difficult and painful, and I don't see any of the options proposed so far as making any significant difference. Nico -- From Darren.Moffat@sun.com Mon Dec 7 09:59:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7HxhsA027552 for ; Mon, 7 Dec 2009 09:59:43 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7HxgTT022844 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 7 Dec 2009 09:59:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUA00305NBIP000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 10:59:42 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUA00CV4NBHW980@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 10:59:42 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7HxfDV018413 for ; Mon, 07 Dec 2009 17:59:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00I00N7NXV00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 17:59:26 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA007RYNB1NV50@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 07 Dec 2009 17:59:26 +0000 (GMT) Date: Mon, 07 Dec 2009 17:59:25 +0000 From: Darren J Moffat Subject: PSARC/2009/576 final spec Sender: Darren.Moffat@sun.com To: PSARC-ext@sun.com, Will Fiveash , kerberos-discuss@opensolaris.org Message-id: <4B1D427D.9050800@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 209 I believe we are still waiting on a final spec for this case. Specifically is the intent to add a 'pkinit' module option to the existing pam_krb5 module or add a pam_krb5_pkinit module. -- Darren J Moffat From William.Fiveash@Sun.COM Mon Dec 7 10:45:24 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB7IjOq1028169 for ; Mon, 7 Dec 2009 10:45:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB7IjMQ1014341; Mon, 7 Dec 2009 10:45:22 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUA00805PFM5S00@brm-avmta-1.central.sun.com>; Mon, 07 Dec 2009 11:45:22 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUA00CIIPFLWBD0@brm-avmta-1.central.sun.com>; Mon, 07 Dec 2009 11:45:21 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB7IcUTV014880; Mon, 07 Dec 2009 12:38:30 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB7IcUoh014879; Mon, 07 Dec 2009 12:38:30 -0600 (CST) Date: Mon, 07 Dec 2009 12:38:30 -0600 From: Will Fiveash Subject: Re: PSARC/2009/576 final spec In-reply-to: <4B1D427D.9050800@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@Sun.COM, Will Fiveash , kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091207183830.GA14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 642 On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > I believe we are still waiting on a final spec for this case. > > Specifically is the intent to add a 'pkinit' module option to the existing > pam_krb5 module or add a pam_krb5_pkinit module. Right, sorry for the delay (was on vacation). I'll update the spec taking the "pkinit" module option approach which is preferable over the pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for the reasons mentioned earlier in this discussion. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@Sun.COM Tue Dec 8 16:35:36 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB90ZaIN024768 for ; Tue, 8 Dec 2009 16:35:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB90ZYwj015663; Tue, 8 Dec 2009 16:35:34 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUD009070BAW600@brm-avmta-1.central.sun.com>; Tue, 08 Dec 2009 17:35:34 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUD0049E0B9JB50@brm-avmta-1.central.sun.com>; Tue, 08 Dec 2009 17:35:33 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB90SfVs022364; Tue, 08 Dec 2009 18:28:41 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB90SfEt022363; Tue, 08 Dec 2009 18:28:41 -0600 (CST) Date: Tue, 08 Dec 2009 18:28:41 -0600 From: Will Fiveash Subject: Re: PSARC/2009/576 final spec In-reply-to: <20091207183830.GA14767@sun.com> To: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091209002841.GB14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091207183830.GA14767@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1511 On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: > On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > > I believe we are still waiting on a final spec for this case. > > > > Specifically is the intent to add a 'pkinit' module option to the existing > > pam_krb5 module or add a pam_krb5_pkinit module. > > Right, sorry for the delay (was on vacation). I'll update the spec > taking the "pkinit" module option approach which is preferable over the > pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for > the reasons mentioned earlier in this discussion. One question; should pam_krb5 doing PKINIT ever try using the password acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below pam_authtok_get like so: login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 ? I was thinking that pam_krb5 could try doing PKINIT preauth with the user's password and if that failed would try PKINIT preauth again, this time prompting for the user's PIN. If that is a bad idea then pam_krb5 doing PKINIT would ignore the user's password and always prompt for the PIN regardless of where it was in the auth stack. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Shawn.Emery@sun.com Tue Dec 8 18:17:00 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB92H0p5027311 for ; Tue, 8 Dec 2009 18:17:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB92GuBk017020 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 8 Dec 2009 20:17:00 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUD00H0150B0B00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Dec 2009 18:16:59 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUD00G8F50AV900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 08 Dec 2009 18:16:58 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB92GwOL022230 for ; Wed, 09 Dec 2009 02:16:58 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUD00M004X2P100@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 08 Dec 2009 19:16:58 -0700 (MST) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUD00BQ55096Z40@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 08 Dec 2009 19:16:57 -0700 (MST) Date: Tue, 08 Dec 2009 19:15:39 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <20091209002841.GB14767@sun.com> Sender: Shawn.Emery@sun.com To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4B1F084B.2010509@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_5ZSO6rshQrwuDCyA0Lr95g)" X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091207183830.GA14767@sun.com> <20091209002841.GB14767@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 4303 This is a multi-part message in MIME format. --Boundary_(ID_5ZSO6rshQrwuDCyA0Lr95g) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Will Fiveash wrote: > On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: > >> On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: >> >>> I believe we are still waiting on a final spec for this case. >>> >>> Specifically is the intent to add a 'pkinit' module option to the existing >>> pam_krb5 module or add a pam_krb5_pkinit module. >>> >> Right, sorry for the delay (was on vacation). I'll update the spec >> taking the "pkinit" module option approach which is preferable over the >> pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for >> the reasons mentioned earlier in this discussion. >> > > One question; should pam_krb5 doing PKINIT ever try using the password > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > pam_authtok_get like so: > > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 pkinit > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_auth.so.1 > ? > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > user's password and if that failed would try PKINIT preauth again, this > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > doing PKINIT would ignore the user's password and always prompt for the > PIN regardless of where it was in the auth stack. The problem with trying to use an auth token that could be potentially be a password is that it could rapidly increase a smart card's lock out count. Ergo I would be conservative here and only attempt a PIN if PKINIT has been specified. -- Shawn. --Boundary_(ID_5ZSO6rshQrwuDCyA0Lr95g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Will Fiveash wrote: 
On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote:
  
On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote:
    
 I believe we are still waiting on a final spec for this case.

 Specifically is the intent to add a 'pkinit' module option to the existing 
 pam_krb5 module or add a pam_krb5_pkinit module.
      
Right, sorry for the delay (was on vacation).  I'll update the spec
taking the "pkinit" module option approach which is preferable over the
pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for
the reasons mentioned earlier in this discussion.
    

One question; should pam_krb5 doing PKINIT ever try using the password
acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below
pam_authtok_get like so:

       login auth required           pam_unix_cred.so.1
       login auth sufficient         pam_krb5.so.1 pkinit
       login auth requisite          pam_authtok_get.so.1
       login auth required           pam_dhkeys.so.1
       login auth required           pam_unix_auth.so.1
?

I was thinking that pam_krb5 could try doing PKINIT preauth with the
user's password and if that failed would try PKINIT preauth again, this
time prompting for the user's PIN.  If that is a bad idea then pam_krb5
doing PKINIT would ignore the user's password and always prompt for the
PIN  regardless of where it was in the auth stack.

The problem with trying to use an auth token that could be potentially be a password is that it could rapidly increase a smart card's lock out count.  Ergo I would be conservative here and only attempt a PIN if PKINIT has been specified.
-- 
Shawn.
--Boundary_(ID_5ZSO6rshQrwuDCyA0Lr95g)-- From Darren.Moffat@sun.com Wed Dec 9 01:46:05 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB99k4B3017361 for ; Wed, 9 Dec 2009 01:46:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB99k26k047054 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 02:46:04 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUD0000RPSRJA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 09 Dec 2009 02:46:03 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUD00LDJPSQJP10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 09 Dec 2009 02:46:03 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB99k1aO013300 for ; Wed, 09 Dec 2009 09:46:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUD00E00NPE0000@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 09 Dec 2009 09:45:42 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUD00M5BPRLZU90@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 09 Dec 2009 09:45:21 +0000 (GMT) Date: Wed, 09 Dec 2009 09:45:20 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/576 final spec In-reply-to: <20091209002841.GB14767@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4B1F71B0.3060408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091207183830.GA14767@sun.com> <20091209002841.GB14767@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 1841 Will Fiveash wrote: > On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: >> On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: >>> I believe we are still waiting on a final spec for this case. >>> >>> Specifically is the intent to add a 'pkinit' module option to the existing >>> pam_krb5 module or add a pam_krb5_pkinit module. >> Right, sorry for the delay (was on vacation). I'll update the spec >> taking the "pkinit" module option approach which is preferable over the >> pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for >> the reasons mentioned earlier in this discussion. > > One question; should pam_krb5 doing PKINIT ever try using the password > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > pam_authtok_get like so: > > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 pkinit > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_auth.so.1 That is above authtok_get. > I was thinking that pam_krb5 could try doing PKINIT preauth with the > user's password and if that failed would try PKINIT preauth again, this > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > doing PKINIT would ignore the user's password and always prompt for the > PIN regardless of where it was in the auth stack. I can see a use case for either case. Wither it is a bad idea or not depends on wither or not it would cause the PKCS#11 token to record a failed login attempt or if it would cause a Kerberos failed login attempt. So I'd say be on the safe side and if pkinit is specified don't use PAM_AUTHTOK at all for authenticating to the PKCS#11 token. -- Darren J Moffat From deengert@anl.gov Wed Dec 9 07:20:16 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9FKGbV021219 for ; Wed, 9 Dec 2009 07:20:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9FKDFS016045; Wed, 9 Dec 2009 07:20:15 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00B1559Q5100@brm-avmta-1.central.sun.com>; Wed, 09 Dec 2009 08:20:14 -0700 (MST) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE00LAD59PPYB0@brm-avmta-1.central.sun.com>; Wed, 09 Dec 2009 08:20:13 -0700 (MST) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB9El1SR004601; Wed, 09 Dec 2009 15:20:12 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay43i.sun.com with ESMTP id BT-MMP-8071169; Wed, 09 Dec 2009 15:20:12 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-88014699; Wed, 09 Dec 2009 15:20:12 +0000 (Z) Received: from mailhost.anl.gov ([130.202.113.50] [130.202.113.50]) by relay4i.sun.com with ESMTP id BT-MMP-3352184; Wed, 09 Dec 2009 15:20:12 +0000 (Z) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 25869DA; Wed, 09 Dec 2009 09:20:12 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 1A891D7; Wed, 09 Dec 2009 09:20:12 -0600 (CST) Date: Wed, 09 Dec 2009 09:20:12 -0600 From: "Douglas E. Engert" Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <20091209002841.GB14767@sun.com> To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Message-id: <4B1FC02C.2070904@anl.gov> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 0.070sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4B1D427D.9050800@Sun.COM> <20091207183830.GA14767@sun.com> <20091209002841.GB14767@sun.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 2127 Will Fiveash wrote: > On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: >> On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: >>> I believe we are still waiting on a final spec for this case. >>> >>> Specifically is the intent to add a 'pkinit' module option to the existing >>> pam_krb5 module or add a pam_krb5_pkinit module. >> Right, sorry for the delay (was on vacation). I'll update the spec >> taking the "pkinit" module option approach which is preferable over the >> pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for >> the reasons mentioned earlier in this discussion. > > One question; should pam_krb5 doing PKINIT ever try using the password > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > pam_authtok_get like so: > > login auth required pam_unix_cred.so.1 > login auth sufficient pam_krb5.so.1 pkinit > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth required pam_unix_auth.so.1 > ? > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > user's password and if that failed would try PKINIT preauth again, this > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > doing PKINIT would ignore the user's password and always prompt for the > PIN regardless of where it was in the auth stack. It may be a bad idea. Each attempt to use the PIN against the smart card counts as a failure. If the user really gets confused, and types in password then wrong PIN, its two strikes rather then one. If the user does this 3 times, its 6 strikes, and this may be enough to turn off the card. I suggest don't try and use a password for a PIN. When PIN pad readers are in wide use, you could not use the password anyway, as the PIN reader is designed to send the PIN directly to the card, bypassing the keyboard and computer. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From gww@sac.sfbay.sun.com Wed Dec 9 11:09:51 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9J9pQD001426 for ; Wed, 9 Dec 2009 11:09:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9J9m3e023714 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 11:09:51 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00A17FWEQR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 12:09:50 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE007DAFWE5O80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 12:09:50 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9J9mmU023540; Wed, 09 Dec 2009 11:09:48 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9J9mNo001423; Wed, 09 Dec 2009 11:09:48 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nB9J9mDl001422; Wed, 09 Dec 2009 11:09:48 -0800 (PST) Date: Wed, 09 Dec 2009 11:09:48 -0800 (PST) From: Gary Winiger Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec To: Darren.Moffat@sun.com, PSARC-ext@sun.com, deengert@anl.gov, kerberos-discuss@opensolaris.org Message-id: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1240 > > One question; should pam_krb5 doing PKINIT ever try using the password > > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > > pam_authtok_get like so: > > > > login auth required pam_unix_cred.so.1 > > login auth sufficient pam_krb5.so.1 pkinit > > login auth requisite pam_authtok_get.so.1 > > login auth required pam_dhkeys.so.1 > > login auth required pam_unix_auth.so.1 > > ? > > > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > > user's password and if that failed would try PKINIT preauth again, this > > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > > doing PKINIT would ignore the user's password and always prompt for the > > PIN regardless of where it was in the auth stack. IMO, it is a site configuration error to put pkinit below authtok_get. That said, it is possible for applications to set PAM_AUTHTOK before calling pam_authenticate. IMO, you either have an administrative error, or an application error. I'd say, if PAM_AUTHTOK is set to use it rather than prompt. If it locks out the card, the admin/application will be noted as buggy. Gary.. From Wyllys.Ingersoll@sun.com Wed Dec 9 11:34:19 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9JYIig001781 for ; Wed, 9 Dec 2009 11:34:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9JYIJu017869 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 13:34:18 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00D03H16C200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 12:34:18 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE00C0MH16NM10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 12:34:18 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB9JYITE022256 for ; Wed, 09 Dec 2009 19:34:18 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUE00J00GMXS200@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 12:34:18 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUE003HKH0X1K80@mail-amer.sun.com>; Wed, 09 Dec 2009 12:34:10 -0700 (MST) Date: Wed, 09 Dec 2009 14:34:09 -0500 From: Wyllys Ingersoll Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> Sender: Wyllys.Ingersoll@sun.com To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, deengert@anl.gov, kerberos-discuss@opensolaris.org Message-id: <4B1FFBB1.6070308@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1788 Gary Winiger wrote: >>> One question; should pam_krb5 doing PKINIT ever try using the password >>> acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below >>> pam_authtok_get like so: >>> >>> login auth required pam_unix_cred.so.1 >>> login auth sufficient pam_krb5.so.1 pkinit >>> login auth requisite pam_authtok_get.so.1 >>> login auth required pam_dhkeys.so.1 >>> login auth required pam_unix_auth.so.1 >>> ? >>> >>> I was thinking that pam_krb5 could try doing PKINIT preauth with the >>> user's password and if that failed would try PKINIT preauth again, this >>> time prompting for the user's PIN. If that is a bad idea then pam_krb5 >>> doing PKINIT would ignore the user's password and always prompt for the >>> PIN regardless of where it was in the auth stack. > > IMO, it is a site configuration error to put pkinit below > authtok_get. That said, it is possible for applications > to set PAM_AUTHTOK before calling pam_authenticate. > > IMO, you either have an administrative error, or an application > error. I'd say, if PAM_AUTHTOK is set to use it rather than > prompt. If it locks out the card, the admin/application will > be noted as buggy. > > Gary.. We talked about this in the KRB5 iTeam meeting today and I agree. Basically, my opinion boils down to this: * if PAM_AUTHTOK is set (regardless of who set it, the app or pam_authtok_get), pam_krb5+pkinit should attempt to use it. If it fails, return AUTHFAIL. * If PAM_AUTHTOK is NOT set, prompt for the PIN and attempt to use it. If it fails, return AUTHFAIL. Ignoring PAM_AUTHTOK is bad and it is equally bad to the user's experience to prompt twice for essentially the same information. -Wyllys From William.Fiveash@sun.com Wed Dec 9 12:52:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9KqQTg003203 for ; Wed, 9 Dec 2009 12:52:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nB9KqOic011757; Wed, 9 Dec 2009 13:52:25 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00H09KNCSU00@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Dec 2009 12:52:24 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE00CWVKNC6H40@nwk-avmta-2.sfbay.sun.com>; Wed, 09 Dec 2009 12:52:24 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB9KjWnI026026; Wed, 09 Dec 2009 14:45:32 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB9KjVxk026025; Wed, 09 Dec 2009 14:45:31 -0600 (CST) Date: Wed, 09 Dec 2009 14:45:31 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <4B1FFBB1.6070308@sun.com> To: Wyllys Ingersoll Cc: Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Wyllys Ingersoll , Gary Winiger , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091209204531.GC14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> <4B1FFBB1.6070308@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 3283 On Wed, Dec 09, 2009 at 02:34:09PM -0500, Wyllys Ingersoll wrote: > Gary Winiger wrote: > >>> One question; should pam_krb5 doing PKINIT ever try using the password > >>> acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > >>> pam_authtok_get like so: > >>> > >>> login auth required pam_unix_cred.so.1 > >>> login auth sufficient pam_krb5.so.1 pkinit > >>> login auth requisite pam_authtok_get.so.1 > >>> login auth required pam_dhkeys.so.1 > >>> login auth required pam_unix_auth.so.1 > >>> ? > >>> > >>> I was thinking that pam_krb5 could try doing PKINIT preauth with the > >>> user's password and if that failed would try PKINIT preauth again, this > >>> time prompting for the user's PIN. If that is a bad idea then pam_krb5 > >>> doing PKINIT would ignore the user's password and always prompt for the > >>> PIN regardless of where it was in the auth stack. > > > > IMO, it is a site configuration error to put pkinit below > > authtok_get. That said, it is possible for applications > > to set PAM_AUTHTOK before calling pam_authenticate. > > > > IMO, you either have an administrative error, or an application > > error. I'd say, if PAM_AUTHTOK is set to use it rather than > > prompt. If it locks out the card, the admin/application will > > be noted as buggy. > > > > Gary.. > > We talked about this in the KRB5 iTeam meeting today and I agree. > Basically, my opinion boils down to this: > > * if PAM_AUTHTOK is set (regardless of who set it, the app or pam_authtok_get), pam_krb5+pkinit > should attempt to use it. If it fails, return AUTHFAIL. Yes, this is what I was thinking. If the admin wants pam_krb5 pkinit to prompt for a PIN, stack it above pam_authtok_get. If, for whatever reason, they want to use the password acquired by pam_authtok_get to access the user's private key for PKINIT then stack pam_krb5 pkinit below pam_authtok_get. Note that this behavior does not preclude "try PKINIT, fall back to password krb auth" scenario in either of these stacks: Example 1: login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit # This prompts for PIN login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 # will try password based krb auth if pam_krb5.so.1 pkinit fails Example 2: login auth required pam_unix_cred.so.1 login auth requisite pam_authtok_get.so.1 login auth sufficient pam_krb5.so.1 pkinit # This uses PAM_AUTHTOK, will not prompt at all login auth required pam_krb5.so.1 # will try password based krb auth using PAM_AUTHTOK # if pam_krb5.so.1 pkinit fails > * If PAM_AUTHTOK is NOT set, prompt for the PIN and attempt to use it. If it fails, return > AUTHFAIL. Well, depending on the control flag it will either return failure or ignore. > Ignoring PAM_AUTHTOK is bad and it is equally bad to the user's experience to prompt twice > for essentially the same information. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Shawn.Emery@sun.com Wed Dec 9 14:00:58 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9M0wJh004964 for ; Wed, 9 Dec 2009 14:00:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9M0v3P018117 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 9 Dec 2009 14:00:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00F1LNTL6J00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 14:00:57 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE001QXNTKXF60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 14:00:57 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nB9M0ube025625 for ; Wed, 09 Dec 2009 22:00:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUE00500NIQ1U00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 09 Dec 2009 15:00:56 -0700 (MST) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUE0045SNT97HA0@mail-amer.sun.com>; Wed, 09 Dec 2009 15:00:46 -0700 (MST) Date: Wed, 09 Dec 2009 14:59:28 -0700 From: Shawn M Emery Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> Sender: Shawn.Emery@sun.com To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-ext@sun.com, deengert@anl.gov, kerberos-discuss@opensolaris.org Message-id: <4B201DC0.5050801@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vzAupEPkqmIFLxOxudyUBA)" X-PMX-Version: 5.4.1.325704 References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 4389 This is a multi-part message in MIME format. --Boundary_(ID_vzAupEPkqmIFLxOxudyUBA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Gary Winiger wrote: >>> One question; should pam_krb5 doing PKINIT ever try using the password >>> acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below >>> pam_authtok_get like so: >>> >>> login auth required pam_unix_cred.so.1 >>> login auth sufficient pam_krb5.so.1 pkinit >>> login auth requisite pam_authtok_get.so.1 >>> login auth required pam_dhkeys.so.1 >>> login auth required pam_unix_auth.so.1 >>> ? >>> >>> I was thinking that pam_krb5 could try doing PKINIT preauth with the >>> user's password and if that failed would try PKINIT preauth again, this >>> time prompting for the user's PIN. If that is a bad idea then pam_krb5 >>> doing PKINIT would ignore the user's password and always prompt for the >>> PIN regardless of where it was in the auth stack. >>> > > IMO, it is a site configuration error to put pkinit below > authtok_get. That said, it is possible for applications > to set PAM_AUTHTOK before calling pam_authenticate. > One use case that Will brought from a conversation w/Nico is a soft token that is encrypted in a user's password. The soft token could be something stored on a USB flash drive for instance. > IMO, you either have an administrative error, or an application > error. I'd say, if PAM_AUTHTOK is set to use it rather than > prompt. If it locks out the card, the admin/application will > be noted as buggy. > I'm in agreement here, if the admin has configured their stack this way then they deserve an accelerated smart card lockout. So with this in mind, I think we are in agreement now that PAM_AUTHTOK should be tried in the pkinit option scenario. -- Shawn. --Boundary_(ID_vzAupEPkqmIFLxOxudyUBA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Gary Winiger wrote: 
One question; should pam_krb5 doing PKINIT ever try using the password
acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below
pam_authtok_get like so:

       login auth required           pam_unix_cred.so.1
       login auth sufficient         pam_krb5.so.1 pkinit
       login auth requisite          pam_authtok_get.so.1
       login auth required           pam_dhkeys.so.1
       login auth required           pam_unix_auth.so.1
?

I was thinking that pam_krb5 could try doing PKINIT preauth with the
user's password and if that failed would try PKINIT preauth again, this
time prompting for the user's PIN.  If that is a bad idea then pam_krb5
doing PKINIT would ignore the user's password and always prompt for the
PIN  regardless of where it was in the auth stack.
      

	IMO, it is a site configuration error to put pkinit below
	authtok_get.  That said, it is possible for applications
	to set PAM_AUTHTOK before calling pam_authenticate.

One use case that Will brought from a conversation w/Nico is a soft token that is encrypted in a user's password.  The soft token could be something stored on a USB flash drive for instance.

	IMO, you either have an administrative error, or an application
	error.  I'd say, if PAM_AUTHTOK is set to use it rather than
	prompt.  If it locks out the card, the admin/application will
	be noted as buggy.

I'm in agreement here, if the admin has configured their stack this way then they deserve an accelerated smart card lockout.  So with this in mind, I think we are in agreement now that PAM_AUTHTOK should be tried in the pkinit option scenario.
-- 
Shawn.
--Boundary_(ID_vzAupEPkqmIFLxOxudyUBA)-- From William.Fiveash@sun.com Wed Dec 9 14:13:38 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nB9MDcrn005159 for ; Wed, 9 Dec 2009 14:13:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nB9MDZ8U019024; Wed, 9 Dec 2009 16:13:37 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUE00H01OEOV100@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Dec 2009 14:13:36 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUE001GDOEOXH90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Dec 2009 14:13:36 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nB9M6idQ026651; Wed, 09 Dec 2009 16:06:44 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nB9M6iEF026650; Wed, 09 Dec 2009 16:06:44 -0600 (CST) Date: Wed, 09 Dec 2009 16:06:44 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <20091209204531.GC14767@sun.com> To: Wyllys Ingersoll , Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@sun.com Mail-followup-to: Wyllys Ingersoll , Gary Winiger , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Darren.Moffat@Sun.COM Message-id: <20091209220644.GD14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> <4B1FFBB1.6070308@sun.com> <20091209204531.GC14767@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 556 On Wed, Dec 09, 2009 at 02:45:31PM -0600, Will Fiveash wrote: > On Wed, Dec 09, 2009 at 02:34:09PM -0500, Wyllys Ingersoll wrote: > > * If PAM_AUTHTOK is NOT set, prompt for the PIN and attempt to use it. If it fails, return > > AUTHFAIL. > > Well, depending on the control flag it will either return failure or > ignore. Nevermind the above, the module with return failure with the control flag influencing the auth stack evaluation. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@sun.com Wed Dec 9 18:30:37 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBA2Ub4p011455 for ; Wed, 9 Dec 2009 18:30:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBA2UZUH004796; Wed, 9 Dec 2009 20:30:35 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUF004010AZFD00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Dec 2009 18:30:35 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUF00CKY0AYIQ80@nwk-avmta-1.sfbay.Sun.COM>; Wed, 09 Dec 2009 18:30:35 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBA2Nh3e027983; Wed, 09 Dec 2009 20:23:43 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBA2Nhrb027982; Wed, 09 Dec 2009 20:23:43 -0600 (CST) Date: Wed, 09 Dec 2009 20:23:43 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <4B1F71B0.3060408@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091210022343.GE14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091207183830.GA14767@sun.com> <20091209002841.GB14767@sun.com> <4B1F71B0.3060408@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2473 On Wed, Dec 09, 2009 at 09:45:20AM +0000, Darren Moffat wrote: > Will Fiveash wrote: > > On Mon, Dec 07, 2009 at 12:38:30PM -0600, Will Fiveash wrote: > >> On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > >>> I believe we are still waiting on a final spec for this case. > >>> > >>> Specifically is the intent to add a 'pkinit' module option to the > >>> existing pam_krb5 module or add a pam_krb5_pkinit module. > >> Right, sorry for the delay (was on vacation). I'll update the spec > >> taking the "pkinit" module option approach which is preferable over the > >> pam_krb5_pkinit approach of creating a new PAM module to do PKINIT for > >> the reasons mentioned earlier in this discussion. > > One question; should pam_krb5 doing PKINIT ever try using the password > > acquired via pam_authtok_get as the PIN if pam_krb5 is stacked below > > pam_authtok_get like so: > > login auth required pam_unix_cred.so.1 > > login auth sufficient pam_krb5.so.1 pkinit > > login auth requisite pam_authtok_get.so.1 > > login auth required pam_dhkeys.so.1 > > login auth required pam_unix_auth.so.1 > > That is above authtok_get. Yeah, I need to take a bit more time before hitting send. 8^) I meant to modify that stack so pam_krb5 was below pam_authtok_get. > > I was thinking that pam_krb5 could try doing PKINIT preauth with the > > user's password and if that failed would try PKINIT preauth again, this > > time prompting for the user's PIN. If that is a bad idea then pam_krb5 > > doing PKINIT would ignore the user's password and always prompt for the > > PIN regardless of where it was in the auth stack. > > I can see a use case for either case. Wither it is a bad idea or not > depends on wither or not it would cause the PKCS#11 token to record a failed > login attempt or if it would cause a Kerberos failed login attempt. > > So I'd say be on the safe side and if pkinit is specified don't use > PAM_AUTHTOK at all for authenticating to the PKCS#11 token. I see that several people have that concern however Gary and Wyllys have stated that pam_krb5 pkinit should use PAM_AUTHTOK if set and not prompt so that's how things will work (as described in other e-mails on this thread). I'll send the updated materials out tomorrow. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From hotz@jpl.nasa.gov Thu Dec 10 10:23:26 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBAINQxa011454 for ; Thu, 10 Dec 2009 10:23:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBAINNpX014197; Thu, 10 Dec 2009 10:23:24 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUG008058F0K800@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Dec 2009 10:23:24 -0800 (PST) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUG006L28EYPM30@nwk-avmta-2.sfbay.sun.com>; Thu, 10 Dec 2009 10:23:22 -0800 (PST) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBAINMED025633; Thu, 10 Dec 2009 18:23:22 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-5453694; Thu, 10 Dec 2009 18:21:22 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-119633528; Thu, 10 Dec 2009 18:21:22 +0000 (Z) Received: from mail.jpl.nasa.gov ([128.149.139.106] [128.149.139.106]) by relay1i.sun.com with ESMTP id BT-MMP-24514848; Thu, 10 Dec 2009 18:21:21 +0000 (Z) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.1/Switch-3.4.1) with ESMTP id nBAIKih2016925; Thu, 10 Dec 2009 10:20:44 -0800 Date: Thu, 10 Dec 2009 10:20:44 -0800 From: "Henry B. Hotz" Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <4B1FFBB1.6070308@sun.com> To: Wyllys Ingersoll Cc: Gary Winiger , "PSARC-ext@Sun.COM" , "kerberos-discuss@opensolaris.org" , "Darren.Moffat@Sun.COM" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1077) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> <4B1FFBB1.6070308@sun.com> Status: RO Content-Length: 802 On Dec 9, 2009, at 11:34 AM, Wyllys Ingersoll wrote: > Basically, my opinion boils down to this: > > * if PAM_AUTHTOK is set (regardless of who set it, the app or pam_authtok_get), pam_krb5+pkinit > should attempt to use it. If it fails, return AUTHFAIL. > > * If PAM_AUTHTOK is NOT set, prompt for the PIN and attempt to use it. If it fails, return > AUTHFAIL. > > Ignoring PAM_AUTHTOK is bad and it is equally bad to the user's experience to prompt twice > for essentially the same information. I think this needs expanding to cover card readers with built-in PIN pads (as DE said). ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From William.Fiveash@Sun.COM Thu Dec 10 15:36:18 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBANaInR020286 for ; Thu, 10 Dec 2009 15:36:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBANaCA0051019; Thu, 10 Dec 2009 16:36:16 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUG0041DMWGAL00@brm-avmta-1.central.sun.com>; Thu, 10 Dec 2009 16:36:16 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUG00CBKMWEXP90@brm-avmta-1.central.sun.com>; Thu, 10 Dec 2009 16:36:15 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBANTMcw002167; Thu, 10 Dec 2009 17:29:22 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBANTMsv002166; Thu, 10 Dec 2009 17:29:22 -0600 (CST) Date: Thu, 10 Dec 2009 17:29:22 -0600 From: Will Fiveash Subject: Re: PSARC/2009/576 final spec In-reply-to: <4B1D427D.9050800@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@Sun.COM, Will Fiveash , kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091210232922.GA404@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg)" Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 58355 --Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > I believe we are still waiting on a final spec for this case. > > Specifically is the intent to add a 'pkinit' module option to the existing > pam_krb5 module or add a pam_krb5_pkinit module. I've attached the updated: - fasttrack - pam_krb5 man page - pam_krb5 man page diff marked -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA --Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg) Content-type: text/plain; NAME=fasttrack.txt; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=fasttrack.txt 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: December 10, 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 keys to acquire their Kerberos credential without using their long term Kerberos password. The pam_krb5 authentication module will be modified to support a new module option, "pkinit", which if present on the auth stack instance of pam_krb5 indicates that pam_krb5 should do PKINIT preauth. If PAM_AUTHTOK is set then pam_krb5 would try PKINIT preauth using that password. If PAM_AUTHTOK is not set then pam_krb5 would call the Kerberos library passing a prompter function that would allow the Kerberos pkinit preauth plugin to prompt for whatever information is required to access the user's private key via the PAM_CONV conversation function. In either case if PKINIT fails to acquire a Kerberos credential a PAM error would be returned. The pam_krb5 authentication module will support being stacked two times in the auth stack to support a "fall back to password based Kerberos preauth" scenario. The second instance of the pam_krb5 auth module in a auth stack would check if the previous instance of the pam_krb5 auth module returned PAM_SUCCESS and if so would immediately return PAM_IGNORE. If the previous instance did not return PAM_SUCCESS then the pam_krb5 auth module would try password based Kerberos preauth and return PAM_SUCCESS if a valid Kerberos credential was acquired. The pam_krb auth module, when doing PKINIT, will prompt for and set PAM_USER if that item is not already set in the auth stack. The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new password is NULL - the old password is NULL - verification of the old password fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the application subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT. The other pam_krb5 modules (account and session) will not change. INTERFACE STABILITY AND RELEASE BINDINGS ---------------------------------------- Interface Stability Release Binding new pam_krb5 option Committed Minor 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg) Content-type: text/plain; NAME=pam_krb5_man_pkinit; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5_man_pkinit Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. Note that if pam_sm_authenticate() is called and the "pkinit" module option is set the Kerberos V5 authentication module will try to do PKINIT authentication if both the system and the KDC are configured to support this type of authentication. This form of authentication uses a user's certificate and private key to acquire the user's initial Kerberos credential (TGT). Use of smartcards is supported by PKINIT authentication. See krb5.conf(4) for more details on PKINIT configuration. Also note that this form of authentication is typically useful for services where the system on which the auth stack is being processed has access to the user's certificate and private key. pam_krb5 does not set any PAM items when doing PKINIT authentication. If pam_sm_authenticate() is called and the "pkinit" module option is not set then the Kerberos V5 authentication module will do password based authentication. In either case, if the PAM_AUTHTOK password item has been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked after pam_authtok_get in the auth stack, the Kerberos V5 authentication module will use that PAM_AUTHTOK password for either PKINIT or password based Kerberos authentication. If the PAM_USER item is not set pam_krb5 with the "pkinit" option will prompt for and set that item. If the PAM_AUTHTOK password item has not been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked before pam_authtok_get in the auth stack, and the "pkinit" option is present the Kerberos V5 authentication module will allow the Kerberos pkinit preauth plugin to prompt for whatever information is needed to perform PKINIT (typically this will be for the user's PIN). No PAM items are set via this prompting. See krb5.conf(5) for more information on PKINIT configuration options. If it is desirable to initially have the Kerberos V5 authentication module try PKINIT Kerberos authentication and fall back to password based Kerberos authentication then either the sufficient or optional control flags must be provided for the instance of pam_krb5 with the "pkinit" module option set and another instance of pam_krb5 without the "pkinit" module option must be stacked below pam_authtok_get. If there are PAM modules other than pam_krb5 that must be evaluated below pam_authtok_get then the control flag should be set to optional for the instance of pam_krb5 with the "pkinit" module option set otherwise the control flag should be set to sufficient. Note that only two instances of pam_krb5 are supported in a auth stack. pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. pkinit Indicates that the Kerberos V5 authentication module should try Kerberos PKINIT authentication instead of the default password based Kerberos authentication. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. Example 2 Authenticate Users Through Kerberos Only using password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 Example 3 Authenticate Through Kerberos Optionally using password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. Example 4: Authenticate Users Through Kerberos PKINIT as First Choice The following is an excerpt of a sample pam.conf configuration file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication (using PKINIT) fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for login. Note, the user is prompted once for the PIN by pam_krb5. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 5: Authenticate Users Through Kerberos PKINIT Only The following example allows authentication only to users that have Kerberos-based accounts requiring PKINIT authentication. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit Example 6: Authenticate Users Through Kerberos PKINIT Optionally The following example allows users to acquire a Kerberos credential using PKINIT authentication if they have a Kerberos account. Whether pam_krb5 succeeds or fails the user must provide their Unix password in order to login. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 7: Authenticate Users Through Kerberos PKINIT as a requirement. The following example allows users to login if pam_krb5 is able to acquire a Kerberos credential via PKINT authentication and in addition must provide their Unix password to pam_unix_auth. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 8: Authenticate Users Through Kerberos PKINIT as a requirement using the PAM_AUTHTOK password. The following example allows users to login using their PAM_AUTHTOK password acquired by pam_authtok_get. This password would be used by pam_krb5 to try PKINIT authentication and would also be used by pam_unix_auth to authenticate the user via the user's Unix account. If PKINIT requires a password/PIN that differs from the user's Unix password then pam_krb5 must be stacked above pam_authtok_get. login auth required pam_unix_cred.so.1 login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 pkinit login auth required pam_unix_auth.so.1 Example 9: Authenticate Users Through Kerberos PKINIT, fall back to password based krb auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. If PKINIT succeeds the user will not be prompted for their password. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will return success. If PKINIT fails the user will be prompted for their Kerberos password. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 Example 10: Require users to authenticate either through Kerberos PKINIT or fall back to password based krb auth if PKINIT fails and authenticate with other required PAM modules. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will just return ignore. If pam_krb5 PKINIT fails the second instance of pam_krb5 will try password based authentication and return success or failure. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 11: Require users to authenticate either through Kerberos PKINIT or fall back to pam_pkcs11 auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or if that fails use pam_pkcs11 to validate the user's PIN using their certificate and private key. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth sufficient pam_pkcs11.so.1 ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg) Content-type: text/plain; NAME=pam_krb5.5.diffmarked; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5.5.diffmarked --- pam_krb5_man_orig Fri Nov 6 14:47:20 2009 +++ pam_krb5_man_pkinit Thu Dec 10 16:47:02 2009 @@ -1,660 +1,840 @@ Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + "pkinit" module option is set the Kerberos V5 authentication + module will try to do PKINIT authentication if both the + system and the KDC are configured to support this type of + authentication. This form of authentication uses a + user's certificate and private key to acquire the user's + initial Kerberos credential (TGT). Use of smartcards is + supported by PKINIT authentication. See krb5.conf(4) for + more details on PKINIT configuration. Also note that this + form of authentication is typically useful for services + where the system on which the auth stack is being processed + has access to the user's certificate and private key. + pam_krb5 does not set any PAM items when doing PKINIT + authentication. + If pam_sm_authenticate() is called and the "pkinit" module + option is not set then the Kerberos V5 authentication module + will do password based authentication. + + In either case, if the PAM_AUTHTOK password item has been + set when pam_sm_authenticate() is called, which is the case + when pam_krb5 is stacked after pam_authtok_get in the auth + stack, the Kerberos V5 authentication module will use that + PAM_AUTHTOK password for either PKINIT or password based + Kerberos authentication. + + If the PAM_USER item is not set pam_krb5 with the "pkinit" + option will prompt for and set that item. + + If the PAM_AUTHTOK password item has not been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked before pam_authtok_get in the auth + stack, and the "pkinit" option is present the Kerberos V5 + authentication module will allow the Kerberos pkinit preauth + plugin to prompt for whatever information is needed to + perform PKINIT (typically this will be for the user's PIN). + No PAM items are set via this prompting. See krb5.conf(5) + for more information on PKINIT configuration options. + + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT Kerberos authentication and + fall back to password based Kerberos authentication then + either the sufficient or optional control flags must be + provided for the instance of pam_krb5 with the "pkinit" + module option set and another instance of pam_krb5 without + the "pkinit" module option must be stacked below + pam_authtok_get. If there are PAM modules other than + pam_krb5 that must be evaluated below pam_authtok_get then + the control flag should be set to optional for the instance + of pam_krb5 with the "pkinit" module option set otherwise + the control flag should be set to sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. + pkinit Indicates that the Kerberos V5 authentication + module should try Kerberos PKINIT authentication + instead of the default password based Kerberos + authentication. + Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf + configuration file that authenticates users through the + Kerberos authentication service and authenticates through + the Unix login only if the Kerberos authentication (using + PKINIT) fails. This arrangement is helpful when a majority + of the users are networked by means of Kerberos and when + there are only a few non-Kerberos type user accounts, such + as root. The service illustrated below is for login. Note, + the user is prompted once for the PIN by pam_krb5. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT authentication. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication if they have a + Kerberos account. Whether pam_krb5 succeeds or fails the + user must provide their Unix password in order to login. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is + able to acquire a Kerberos credential via PKINT + authentication and in addition must provide their Unix + password to pam_unix_auth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT as a + requirement using the PAM_AUTHTOK password. + + The following example allows users to login using their + PAM_AUTHTOK password acquired by pam_authtok_get. This + password would be used by pam_krb5 to try PKINIT + authentication and would also be used by pam_unix_auth to + authenticate the user via the user's Unix account. If PKINIT + requires a password/PIN that differs from the user's Unix + password then pam_krb5 must be stacked above pam_authtok_get. + + login auth required pam_unix_cred.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 pkinit + login auth required pam_unix_auth.so.1 + + Example 9: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. If PKINIT succeeds the + user will not be prompted for their password. Note, if + pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password authentication and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. Note, if pam_krb5 + PKINIT succeeds, the second instance of pam_krb5 will not try + password authentication and will just return ignore. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will + try password based authentication and return success or + failure. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 11: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or if that fails use + pam_pkcs11 to validate the user's PIN using their certificate + and private key. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth sufficient pam_pkcs11.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_BsHIBLbcRkfA//rJDoLRBg)-- From William.Fiveash@sun.com Thu Dec 10 15:53:47 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBANrlsP020469 for ; Thu, 10 Dec 2009 15:53:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBANrjZb024414; Thu, 10 Dec 2009 17:53:45 -0600 (CST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUG0060NNPL1600@brm-avmta-1.central.sun.com>; Thu, 10 Dec 2009 16:53:45 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUG00CDQNPJXN90@brm-avmta-1.central.sun.com>; Thu, 10 Dec 2009 16:53:44 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBANdHAh002218; Thu, 10 Dec 2009 17:39:17 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBANdHld002217; Thu, 10 Dec 2009 17:39:17 -0600 (CST) Date: Thu, 10 Dec 2009 17:39:17 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: To: "Henry B. Hotz" Cc: Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "Darren.Moffat@Sun.COM" , Gary Winiger , "kerberos-discuss@opensolaris.org" Mail-followup-to: "Henry B. Hotz" , Wyllys Ingersoll , "PSARC-ext@Sun.COM" , "Darren.Moffat@Sun.COM" , Gary Winiger , "kerberos-discuss@opensolaris.org" Message-id: <20091210233917.GB404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912091909.nB9J9mDl001422@sac.sfbay.sun.com> <4B1FFBB1.6070308@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 1304 On Thu, Dec 10, 2009 at 10:20:44AM -0800, Henry B. Hotz wrote: > > On Dec 9, 2009, at 11:34 AM, Wyllys Ingersoll wrote: > > > Basically, my opinion boils down to this: > > > > * if PAM_AUTHTOK is set (regardless of who set it, the app or pam_authtok_get), pam_krb5+pkinit > > should attempt to use it. If it fails, return AUTHFAIL. > > > > * If PAM_AUTHTOK is NOT set, prompt for the PIN and attempt to use it. If it fails, return > > AUTHFAIL. > > > > Ignoring PAM_AUTHTOK is bad and it is equally bad to the user's experience to prompt twice > > for essentially the same information. > > > I think this needs expanding to cover card readers with built-in PIN pads (as DE said). pam_krb5 is relying on the underlying krb pkinit preauth plugin to prompt for what it needs in order to try PKINIT (this is also true of kinit). Given this I would say that the pkinit preauth plugin needs to support those type of card readers and do the right thing in regards to prompting. If support is found to be inadequate then a RFE CR (request for enhancement change request) needs to be created to have the pkinit preauth plugin enhanced to properly handle those type of card readers. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Darren.Moffat@sun.com Fri Dec 11 01:18:34 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBB9IXsS015157 for ; Fri, 11 Dec 2009 01:18:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBB9IW4c006175 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 11 Dec 2009 01:18:33 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUH00M01DUXJX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 11 Dec 2009 02:18:33 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUH00LPPDUWDX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 11 Dec 2009 02:18:33 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBB9IVlb023216 for ; Fri, 11 Dec 2009 09:18:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUH00K00C64YT00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 11 Dec 2009 09:18:31 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUH005HYDUOI690@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 11 Dec 2009 09:18:25 +0000 (GMT) Date: Fri, 11 Dec 2009 09:18:24 +0000 From: Darren J Moffat Subject: Re: PSARC/2009/576 final spec In-reply-to: <20091210232922.GA404@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <4B220E60.3000404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091210232922.GA404@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091109) Status: RO Content-Length: 1788 Will Fiveash wrote: > On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: >> I believe we are still waiting on a final spec for this case. >> >> Specifically is the intent to add a 'pkinit' module option to the existing >> pam_krb5 module or add a pam_krb5_pkinit module. > > I've attached the updated: > > - fasttrack > The pam_krb5 authentication module will support being stacked two times > in the auth stack to support a "fall back to password based Kerberos > preauth" scenario. The second instance of the pam_krb5 auth module in a > auth stack would check if the previous instance of the pam_krb5 auth > module returned PAM_SUCCESS and if so would immediately return > PAM_IGNORE. I assume a private to pam_krb5 PAM data item is being used for this, right ? > Use of smartcards is > + supported by PKINIT authentication I'd rather this was more generic (and true) by saying any PKCS#11 accessible keystore capable of storing the required credentials, eg a smartcard. Particularly since at this time there is no support for Smartcard in OpenSolaris (OpenSC is available from the /crontrib repository but it hasn't been signed so can't plugin to libpkcs11). I won't hold up the case for that though, since that is really just a man page clarification. For the fallback case I'm not sure I see why we need two instances of the module in the stack, couldn't this be done by adding another module option (eg password_fallback) in that case PAM_AUTHTOK would be set to what the user entered (assuming it was available) and password based preauth would be attempted. If that complicates things too much or there are other reasons to allow for two instances of pam_krb5 in the stack then I'm happy with the case as specified. -- Darren J Moffat From William.Fiveash@sun.com Fri Dec 11 10:02:44 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBBI2iTu024413 for ; Fri, 11 Dec 2009 10:02:44 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBBI2d0u058932; Fri, 11 Dec 2009 11:02:43 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUI0080P24I9W00@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Dec 2009 10:02:42 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUI004RC24I3M50@nwk-avmta-2.sfbay.sun.com>; Fri, 11 Dec 2009 10:02:42 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBBHtn3t019832; Fri, 11 Dec 2009 11:55:49 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBBHtnaC019831; Fri, 11 Dec 2009 11:55:49 -0600 (CST) Date: Fri, 11 Dec 2009 11:55:49 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <4B220E60.3000404@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091211175549.GF14767@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091210232922.GA404@sun.com> <4B220E60.3000404@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2654 On Fri, Dec 11, 2009 at 09:18:24AM +0000, Darren Moffat wrote: > Will Fiveash wrote: > > On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > >> I believe we are still waiting on a final spec for this case. > >> > >> Specifically is the intent to add a 'pkinit' module option to the > >> existing pam_krb5 module or add a pam_krb5_pkinit module. > > I've attached the updated: > > - fasttrack > > > The pam_krb5 authentication module will support being stacked two times > > in the auth stack to support a "fall back to password based Kerberos > > preauth" scenario. The second instance of the pam_krb5 auth module in a > > auth stack would check if the previous instance of the pam_krb5 auth > > module returned PAM_SUCCESS and if so would immediately return > > PAM_IGNORE. > > I assume a private to pam_krb5 PAM data item is being used for this, right ? Yes, there is a krb module data struct that is private to pam_krb5 and is being used for this purpose (among others). > > Use of smartcards is > > + supported by PKINIT authentication > > I'd rather this was more generic (and true) by saying any PKCS#11 accessible > keystore capable of storing the required credentials, eg a smartcard. > Particularly since at this time there is no support for Smartcard in > OpenSolaris (OpenSC is available from the /crontrib repository but it hasn't > been signed so can't plugin to libpkcs11). > > I won't hold up the case for that though, since that is really just a man > page clarification. Okay, I'll modify the man page update to state the above. > For the fallback case I'm not sure I see why we need two instances of the > module in the stack, couldn't this be done by adding another module option > (eg password_fallback) in that case PAM_AUTHTOK would be set to what the > user entered (assuming it was available) and password based preauth would be > attempted. If that complicates things too much or there are other reasons > to allow for two instances of pam_krb5 in the stack then I'm happy with the > case as specified. The problem is that the current design states that if PAM_AUTHTOK is set, that is what pam_krb5 will use regardless of whether it is doing password based krb preauth or PKINIT. This means that if the admin wants pam_krb5 pkinit to prompt for a PIN it must come before pam_authtok_get. If the admin also wants password fall-back then pam_krb5 must come after pam_authtok_get. That is why two instances of pam_krb5 in the auth stack is supported. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash@Sun.COM Fri Dec 11 15:08:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBBN8Rfx003687 for ; Fri, 11 Dec 2009 15:08:27 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBBN8PL8065296; Fri, 11 Dec 2009 16:08:25 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUI00G01GA19W00@brm-avmta-1.central.sun.com>; Fri, 11 Dec 2009 16:08:25 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUI005L5GA0FP60@brm-avmta-1.central.sun.com>; Fri, 11 Dec 2009 16:08:24 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBBN1Was015694; Fri, 11 Dec 2009 17:01:32 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBBN1WfS015685; Fri, 11 Dec 2009 17:01:32 -0600 (CST) Date: Fri, 11 Dec 2009 17:01:32 -0600 From: Will Fiveash Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <4B220E60.3000404@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Mail-followup-to: Darren J Moffat , PSARC-ext@Sun.COM, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <20091211230132.GG14767@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_FfAlB5KjBilcINMiYuB1Bw)" Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091210232922.GA404@sun.com> <4B220E60.3000404@Sun.COM> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 56329 --Boundary_(ID_FfAlB5KjBilcINMiYuB1Bw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline On Fri, Dec 11, 2009 at 09:18:24AM +0000, Darren Moffat wrote: > Will Fiveash wrote: > > On Mon, Dec 07, 2009 at 05:59:25PM +0000, Darren Moffat wrote: > >> I believe we are still waiting on a final spec for this case. > >> > >> Specifically is the intent to add a 'pkinit' module option to the > >> existing pam_krb5 module or add a pam_krb5_pkinit module. > > I've attached the updated: > > - fasttrack > > > The pam_krb5 authentication module will support being stacked two times > > in the auth stack to support a "fall back to password based Kerberos > > preauth" scenario. The second instance of the pam_krb5 auth module in a > > auth stack would check if the previous instance of the pam_krb5 auth > > module returned PAM_SUCCESS and if so would immediately return > > PAM_IGNORE. > > I assume a private to pam_krb5 PAM data item is being used for this, right ? > > > Use of smartcards is > > + supported by PKINIT authentication > > I'd rather this was more generic (and true) by saying any PKCS#11 accessible > keystore capable of storing the required credentials, eg a smartcard. > Particularly since at this time there is no support for Smartcard in > OpenSolaris (OpenSC is available from the /crontrib repository but it hasn't > been signed so can't plugin to libpkcs11). > > I won't hold up the case for that though, since that is really just a man > page clarification. I've attached the update man page, pam_krb5.5, and the diff marked version, pam_krb5.5.diffmarked. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA --Boundary_(ID_FfAlB5KjBilcINMiYuB1Bw) Content-type: text/plain; NAME=pam_krb5.5; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5.5 Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. Note that if pam_sm_authenticate() is called and the "pkinit" module option is set the Kerberos V5 authentication module will try to do PKINIT authentication if both the system and the KDC are configured to support this type of authentication. This form of authentication uses a user's certificate and private key to acquire the user's initial Kerberos credential (TGT). Note that one of the keystore formats supported is PKCS11 which supports use of any PKCS11 compatible keystore capable of storing the required credential and private key needed for PKINIT authentication (PKCS11 compatible smartcards are an example). See krb5.conf(4) for more details on PKINIT configuration. Also note that this form of authentication is typically useful for services where the system on which the auth stack is being processed has access to the user's certificate and private key. If pam_sm_authenticate() is called and the "pkinit" module option is not set then the Kerberos V5 authentication module will do password based authentication. In either case, if the PAM_AUTHTOK password item has been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked after pam_authtok_get in the auth stack, the Kerberos V5 authentication module will use that PAM_AUTHTOK password for either PKINIT or password based Kerberos authentication. If the PAM_USER item is not set pam_krb5 with the "pkinit" option will prompt for and set that item. If the PAM_AUTHTOK password item has not been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked before pam_authtok_get in the auth stack, and the "pkinit" option is present the Kerberos V5 authentication module will allow the Kerberos pkinit preauth plugin to prompt for whatever information is needed to perform PKINIT (typically this will be for the user's PIN). No PAM items are set via this prompting. See krb5.conf(5) for more information on PKINIT configuration options. If it is desirable to initially have the Kerberos V5 authentication module try PKINIT Kerberos authentication and fall back to password based Kerberos authentication then either the sufficient or optional control flags must be provided for the instance of pam_krb5 with the "pkinit" module option set and another instance of pam_krb5 without the "pkinit" module option must be stacked below pam_authtok_get. If there are PAM modules other than pam_krb5 that must be evaluated below pam_authtok_get then the control flag should be set to optional for the instance of pam_krb5 with the "pkinit" module option set otherwise the control flag should be set to sufficient. Note that only two instances of pam_krb5 are supported in a auth stack. pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. pkinit Indicates that the Kerberos V5 authentication module should try Kerberos PKINIT authentication instead of the default password based Kerberos authentication. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. Example 2 Authenticate Users Through Kerberos Only using password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 Example 3 Authenticate Through Kerberos Optionally using password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. Example 4: Authenticate Users Through Kerberos PKINIT as First Choice The following is an excerpt of a sample pam.conf configuration file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication (using PKINIT) fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for login. Note, the user is prompted once for the PIN by pam_krb5. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 5: Authenticate Users Through Kerberos PKINIT Only The following example allows authentication only to users that have Kerberos-based accounts requiring PKINIT authentication. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit Example 6: Authenticate Users Through Kerberos PKINIT Optionally The following example allows users to acquire a Kerberos credential using PKINIT authentication if they have a Kerberos account. Whether pam_krb5 succeeds or fails the user must provide their Unix password in order to login. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 7: Authenticate Users Through Kerberos PKINIT as a requirement. The following example allows users to login if pam_krb5 is able to acquire a Kerberos credential via PKINT authentication and in addition must provide their Unix password to pam_unix_auth. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 8: Authenticate Users Through Kerberos PKINIT as a requirement using the PAM_AUTHTOK password. The following example allows users to login using their PAM_AUTHTOK password acquired by pam_authtok_get. This password would be used by pam_krb5 to try PKINIT authentication and would also be used by pam_unix_auth to authenticate the user via the user's Unix account. If PKINIT requires a password/PIN that differs from the user's Unix password then pam_krb5 must be stacked above pam_authtok_get. login auth required pam_unix_cred.so.1 login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 pkinit login auth required pam_unix_auth.so.1 Example 9: Authenticate Users Through Kerberos PKINIT, fall back to password based krb auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. If PKINIT succeeds the user will not be prompted for their password. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will return success. If PKINIT fails the user will be prompted for their Kerberos password. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 Example 10: Require users to authenticate either through Kerberos PKINIT or fall back to password based krb auth if PKINIT fails and authenticate with other required PAM modules. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will just return ignore. If pam_krb5 PKINIT fails the second instance of pam_krb5 will try password based authentication and return success or failure. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 11: Require users to authenticate either through Kerberos PKINIT or fall back to pam_pkcs11 auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or if that fails use pam_pkcs11 to validate the user's PIN using their certificate and private key. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth sufficient pam_pkcs11.so.1 ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_FfAlB5KjBilcINMiYuB1Bw) Content-type: text/plain; NAME=pam_krb5.5.diffmarked; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5.5.diffmarked --- pam_krb5_man_orig Fri Nov 6 14:47:20 2009 +++ pam_krb5_man_pkinit Fri Dec 11 16:56:20 2009 @@ -1,660 +1,842 @@ Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + "pkinit" module option is set the Kerberos V5 authentication + module will try to do PKINIT authentication if both the + system and the KDC are configured to support this type of + authentication. This form of authentication uses a user's + certificate and private key to acquire the user's initial + Kerberos credential (TGT). Note that one of the keystore + formats supported is PKCS11 which supports use of any PKCS11 + compatible keystore capable of storing the required + credential and private key needed for PKINIT authentication + (PKCS11 compatible smartcards are an example). See + krb5.conf(4) for more details on PKINIT configuration. Also + note that this form of authentication is typically useful + for services where the system on which the auth stack is + being processed has access to the user's certificate and + private key. + If pam_sm_authenticate() is called and the "pkinit" module + option is not set then the Kerberos V5 authentication module + will do password based authentication. + + In either case, if the PAM_AUTHTOK password item has been + set when pam_sm_authenticate() is called, which is the case + when pam_krb5 is stacked after pam_authtok_get in the auth + stack, the Kerberos V5 authentication module will use that + PAM_AUTHTOK password for either PKINIT or password based + Kerberos authentication. + + If the PAM_USER item is not set pam_krb5 with the "pkinit" + option will prompt for and set that item. + + If the PAM_AUTHTOK password item has not been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked before pam_authtok_get in the auth + stack, and the "pkinit" option is present the Kerberos V5 + authentication module will allow the Kerberos pkinit preauth + plugin to prompt for whatever information is needed to + perform PKINIT (typically this will be for the user's PIN). + No PAM items are set via this prompting. See krb5.conf(5) + for more information on PKINIT configuration options. + + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT Kerberos authentication and + fall back to password based Kerberos authentication then + either the sufficient or optional control flags must be + provided for the instance of pam_krb5 with the "pkinit" + module option set and another instance of pam_krb5 without + the "pkinit" module option must be stacked below + pam_authtok_get. If there are PAM modules other than + pam_krb5 that must be evaluated below pam_authtok_get then + the control flag should be set to optional for the instance + of pam_krb5 with the "pkinit" module option set otherwise + the control flag should be set to sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. + pkinit Indicates that the Kerberos V5 authentication + module should try Kerberos PKINIT authentication + instead of the default password based Kerberos + authentication. + Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf + configuration file that authenticates users through the + Kerberos authentication service and authenticates through + the Unix login only if the Kerberos authentication (using + PKINIT) fails. This arrangement is helpful when a majority + of the users are networked by means of Kerberos and when + there are only a few non-Kerberos type user accounts, such + as root. The service illustrated below is for login. Note, + the user is prompted once for the PIN by pam_krb5. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT authentication. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication if they have a + Kerberos account. Whether pam_krb5 succeeds or fails the + user must provide their Unix password in order to login. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is + able to acquire a Kerberos credential via PKINT + authentication and in addition must provide their Unix + password to pam_unix_auth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT as a + requirement using the PAM_AUTHTOK password. + + The following example allows users to login using their + PAM_AUTHTOK password acquired by pam_authtok_get. This + password would be used by pam_krb5 to try PKINIT + authentication and would also be used by pam_unix_auth to + authenticate the user via the user's Unix account. If PKINIT + requires a password/PIN that differs from the user's Unix + password then pam_krb5 must be stacked above pam_authtok_get. + + login auth required pam_unix_cred.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 pkinit + login auth required pam_unix_auth.so.1 + + Example 9: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. If PKINIT succeeds the + user will not be prompted for their password. Note, if + pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password authentication and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. Note, if pam_krb5 + PKINIT succeeds, the second instance of pam_krb5 will not try + password authentication and will just return ignore. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will + try password based authentication and return success or + failure. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 11: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or if that fails use + pam_pkcs11 to validate the user's PIN using their certificate + and private key. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth sufficient pam_pkcs11.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_FfAlB5KjBilcINMiYuB1Bw)-- From Darren.Moffat@sun.com Mon Dec 14 02:19:31 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBEAJVaZ025787 for ; Mon, 14 Dec 2009 02:19:31 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBEAJTuO029971 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Dec 2009 04:19:30 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUN0090P0OIMX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 02:19:30 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUN001B30OHSW70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 02:19:29 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nBEAJRrN026449 for ; Mon, 14 Dec 2009 10:19:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUN008000AJIU00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 10:19:22 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUN007P20O1K1D0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 10:19:13 +0000 (GMT) Date: Mon, 14 Dec 2009 10:19:12 +0000 From: Darren J Moffat Subject: Re: [kerberos-discuss] PSARC/2009/576 final spec In-reply-to: <20091211175549.GF14767@sun.com> Sender: Darren.Moffat@sun.com To: Darren J Moffat , PSARC-ext@sun.com, kerberos-discuss@opensolaris.org, Wyllys Ingersoll Message-id: <4B261120.2060305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B1D427D.9050800@Sun.COM> <20091210232922.GA404@sun.com> <4B220E60.3000404@Sun.COM> <20091211175549.GF14767@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 51 I'm happy with the final spec. -- Darren J Moffat From Wyllys.Ingersoll@sun.com Mon Dec 14 11:41:47 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBEJfloC006665 for ; Mon, 14 Dec 2009 11:41:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBEJflFG001576 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Dec 2009 11:41:47 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUN00001QPN2Q00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 12:41:47 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUN00INLQPGWE30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 12:41:40 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBEJfeaq021666 for ; Mon, 14 Dec 2009 19:41:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUN00700QH0J000@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 12:41:40 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUN00K44QPFXEA0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 12:41:39 -0700 (MST) Date: Mon, 14 Dec 2009 14:41:39 -0500 From: Wyllys Ingersoll Subject: PSARC 2009/576 pam_krb5 pkinit - final spec Sender: Wyllys.Ingersoll@sun.com To: PSARC-ext , Will Fiveash Message-id: <4B2694F3.60203@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 203 The final spec and man page for the pam_krb5 pkinit project have been put into the case directory. If there are no further objections, this case should get approved at the meeting this week. -Wyllys From gww@sac.sfbay.sun.com Mon Dec 14 14:52:52 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBEMqq8W011103 for ; Mon, 14 Dec 2009 14:52:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBEMqq6e012470 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 14 Dec 2009 14:52:52 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUN00505ZK42A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 14:52:52 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUN00DSZZK4MAD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 14 Dec 2009 14:52:52 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBEMqpTa026181; Mon, 14 Dec 2009 14:52:51 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBEMqpKx011100; Mon, 14 Dec 2009 14:52:51 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nBEMqpjA011099; Mon, 14 Dec 2009 14:52:51 -0800 (PST) Date: Mon, 14 Dec 2009 14:52:51 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2009/576 pam_krb5 pkinit - final spec To: PSARC-ext@sun.com, William.Fiveash@sun.com, Wyllys.Ingersoll@sun.com Message-id: <200912142252.nBEMqpjA011099@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1553 > The final spec and man page for the pam_krb5 pkinit project > have been put into the case directory. If there are no > further objections, this case should get approved at the meeting > this week. From message 60 of 17 Nov and not yet answered: Gary.. ====== >From pkinit-final: "The pam_krb5 password module will change in that if PKINIT authentication was done it will return PAM_IGNORE in the following cases: - the new passwd is NULL - the old passwd is NULL - verification of the old passwd fails. If none of the above is true then pam_krb tries to change the password and will return an error if that fails. The rational behind this is if some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change a user's password. But this may well fail: the KDC may not want to allow a PKINIT user to change/set a password since the user may be expected to use PKINIT." This information does not seem to be in the man page. How does the administrator know it? Not being a pkinit expert, I'd like to understand how the password stack will know if the user was authenticated by pkinit? I feel TCR strong that the man page needs to be complete relative to this part of the spec. I'm also concerned that pam_krb5 in the password stack won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set. Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK will be making these checks? From William.Fiveash@sun.com Mon Dec 14 15:41:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBENfl7P012429 for ; Mon, 14 Dec 2009 15:41:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBENflaJ019500; Mon, 14 Dec 2009 16:41:47 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUO001091TMFV00@brm-avmta-1.central.sun.com>; Mon, 14 Dec 2009 16:41:46 -0700 (MST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUO00GCQ1TL5T50@brm-avmta-1.central.sun.com>; Mon, 14 Dec 2009 16:41:45 -0700 (MST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBENgNr1018558; Mon, 14 Dec 2009 17:42:23 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBENgN5p018557; Mon, 14 Dec 2009 17:42:23 -0600 (CST) Date: Mon, 14 Dec 2009 17:42:23 -0600 From: Will Fiveash Subject: Re: PSARC 2009/576 pam_krb5 pkinit - final spec In-reply-to: <200912142252.nBEMqpjA011099@sac.sfbay.sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, William.Fiveash@sun.com, Wyllys.Ingersoll@sun.com Message-id: <20091214234223.GP7738@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912142252.nBEMqpjA011099@sac.sfbay.sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 2422 On Mon, Dec 14, 2009 at 02:52:51PM -0800, Gary Winiger wrote: > > The final spec and man page for the pam_krb5 pkinit project > > have been put into the case directory. If there are no > > further objections, this case should get approved at the meeting > > this week. > > From message 60 of 17 Nov and not yet answered: > > Gary.. > ====== > >From pkinit-final: > > "The pam_krb5 password module will change in that if PKINIT > authentication was done it will return PAM_IGNORE in the following > cases: > > - the new passwd is NULL > - the old passwd is NULL > - verification of the old passwd fails. > > If none of the above is true then pam_krb tries to change the password > and will return an error if that fails. The rational behind this is if > some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD > and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change > a user's password. But this may well fail: the KDC may not want to > allow a PKINIT user to change/set a password since the user may be > expected to use PKINIT." > > This information does not seem to be in the man page. How does the > administrator know it? I will update the man page to include this. > Not being a pkinit expert, I'd like to understand how the password > stack will know if the user was authenticated by pkinit? A field in the krb module data struct will indicate this. > I feel TCR strong that the man page needs to be complete relative to this > part of the spec. I'm also concerned that pam_krb5 in the password stack > won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set. I am not changing the conditions under which pam_krb5 pam_sm_chauthtok() is being called, only it's behavior if pam_krb5 did PKINIT using a PIN (not the PAM_AUTHTOK password) in the auth stack. > Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK > will be making these checks? The checks are made if the PAM_UPDATE_AUTHTOK flag is set. The project is not changing the behavior of pam_sm_chauthtok() if the PAM_PRELIM_CHECK flag is set which is to return PAM_IGNORE. -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/ From William.Fiveash@sun.com Mon Dec 14 18:02:50 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBF22oeL015399 for ; Mon, 14 Dec 2009 18:02:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBF22lQL040787; Mon, 14 Dec 2009 19:02:49 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUO00K0H8CPNP00@nwk-avmta-2.sfbay.sun.com>; Mon, 14 Dec 2009 18:02:49 -0800 (PST) Received: from alton.Central.Sun.COM ([129.153.128.101]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUO00BO78COFZ60@nwk-avmta-2.sfbay.sun.com>; Mon, 14 Dec 2009 18:02:49 -0800 (PST) Received: from alton.Central.Sun.COM (localhost [127.0.0.1]) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nBF1tu76019109; Mon, 14 Dec 2009 19:55:56 -0600 (CST) Received: (from willf@localhost) by alton.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nBF1tu54019108; Mon, 14 Dec 2009 19:55:56 -0600 (CST) Date: Mon, 14 Dec 2009 19:55:56 -0600 From: Will Fiveash Subject: Re: PSARC 2009/576 pam_krb5 pkinit - final spec In-reply-to: <20091214234223.GP7738@sun.com> To: Gary Winiger Cc: PSARC-ext@sun.com, William.Fiveash@sun.com, Wyllys.Ingersoll@sun.com, kerberos-discuss@opensolaris.org Mail-followup-to: Gary Winiger , PSARC-ext@Sun.COM, Wyllys.Ingersoll@Sun.COM, kerberos-discuss@opensolaris.org Message-id: <20091215015556.GQ7738@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_/m2ydJNcdqsCrtxGxOdR4A)" Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200912142252.nBEMqpjA011099@sac.sfbay.sun.com> <20091214234223.GP7738@sun.com> User-Agent: Mutt/1.5.14 (2007-03-31) Status: RO Content-Length: 59688 --Boundary_(ID_/m2ydJNcdqsCrtxGxOdR4A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline I've attached updated pam_krb5.5 and pam_krb5.5.diffmarked. On Mon, Dec 14, 2009 at 05:42:23PM -0600, Will Fiveash wrote: > On Mon, Dec 14, 2009 at 02:52:51PM -0800, Gary Winiger wrote: > > > The final spec and man page for the pam_krb5 pkinit project > > > have been put into the case directory. If there are no > > > further objections, this case should get approved at the meeting > > > this week. > > > > From message 60 of 17 Nov and not yet answered: > > > > Gary.. > > ====== > > >From pkinit-final: > > > > "The pam_krb5 password module will change in that if PKINIT > > authentication was done it will return PAM_IGNORE in the following > > cases: > > > > - the new passwd is NULL > > - the old passwd is NULL > > - verification of the old passwd fails. > > > > If none of the above is true then pam_krb tries to change the password > > and will return an error if that fails. The rational behind this is if > > some PAM module causes pam_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD > > and/or the app subsequently calls pam_chauthtok(), pam_krb5 will change > > a user's password. But this may well fail: the KDC may not want to > > allow a PKINIT user to change/set a password since the user may be > > expected to use PKINIT." > > > > This information does not seem to be in the man page. How does the > > administrator know it? > > I will update the man page to include this. > > > Not being a pkinit expert, I'd like to understand how the password > > stack will know if the user was authenticated by pkinit? > > A field in the krb module data struct will indicate this. > > > I feel TCR strong that the man page needs to be complete relative to this > > part of the spec. I'm also concerned that pam_krb5 in the password stack > > won't likely be called without PAM_AUTHTOK or PAM_OLDAUTHTOK set. > > I am not changing the conditions under which pam_krb5 pam_sm_chauthtok() > is being called, only it's behavior if pam_krb5 did PKINIT using a PIN > (not the PAM_AUTHTOK password) in the auth stack. > > > Which call to pam_sm_chauthtok() PAM_PRELIM_CHECK and/or PAM_UPDATE_AUTHTOK > > will be making these checks? > > The checks are made if the PAM_UPDATE_AUTHTOK flag is set. The project > is not changing the behavior of pam_sm_chauthtok() if the > PAM_PRELIM_CHECK flag is set which is to return PAM_IGNORE. > > -- > Will Fiveash > Sun Microsystems Office x64079/512-401-1079 > Austin, TX, 78727 (TZ=CST6CDT), USA > Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com > http://opensolaris.org/os/project/kerberos/ -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/ --Boundary_(ID_/m2ydJNcdqsCrtxGxOdR4A) Content-type: text/plain; NAME=pam_krb5.5; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5.5 Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. Note that if pam_sm_authenticate() is called and the "pkinit" module option is set the Kerberos V5 authentication module will try to do PKINIT authentication if both the system and the KDC are configured to support this type of authentication. This form of authentication uses a user's certificate and private key to acquire the user's initial Kerberos credential (TGT). Note that one of the keystore formats supported is PKCS11 which supports use of any PKCS11 compatible keystore capable of storing the required credential and private key needed for PKINIT authentication (PKCS11 compatible smartcards are an example). See krb5.conf(4) for more details on PKINIT configuration. Also note that this form of authentication is typically useful for services where the system on which the auth stack is being processed has access to the user's certificate and private key. If pam_sm_authenticate() is called and the "pkinit" module option is not set then the Kerberos V5 authentication module will do password based authentication. In either case, if the PAM_AUTHTOK password item has been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked after pam_authtok_get in the auth stack, the Kerberos V5 authentication module will use that PAM_AUTHTOK password for either PKINIT or password based Kerberos authentication. If the PAM_USER item is not set pam_krb5 with the "pkinit" option will prompt for and set that item. If the PAM_AUTHTOK password item has not been set when pam_sm_authenticate() is called, which is the case when pam_krb5 is stacked before pam_authtok_get in the auth stack, and the "pkinit" option is present the Kerberos V5 authentication module will allow the Kerberos pkinit preauth plugin to prompt for whatever information is needed to perform PKINIT (typically this will be for the user's PIN). No PAM items are set via this prompting. See krb5.conf(5) for more information on PKINIT configuration options. If it is desirable to initially have the Kerberos V5 authentication module try PKINIT Kerberos authentication and fall back to password based Kerberos authentication then either the sufficient or optional control flags must be provided for the instance of pam_krb5 with the "pkinit" module option set and another instance of pam_krb5 without the "pkinit" module option must be stacked below pam_authtok_get. If there are PAM modules other than pam_krb5 that must be evaluated below pam_authtok_get then the control flag should be set to optional for the instance of pam_krb5 with the "pkinit" module option set otherwise the control flag should be set to sufficient. Note that only two instances of pam_krb5 are supported in a auth stack. pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. pkinit Indicates that the Kerberos V5 authentication module should try Kerberos PKINIT authentication instead of the default password based Kerberos authentication. Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key Distribution Center (KDC) database. Note that if the Kerberos V5 authentication module used PKINIT authentication in the auth stack then the Kerberos V5 password management module will return PAM_IGNORE in the following cases: - The new password is NULL. - The old password is NULL. - Verification of the old password fails. The rational behind this is that the KDC may not allow a PKINIT user to change/set a password since the user may be expected to use PKINIT only. If all of the cases above are false the Kerberos V5 password management module will try to change the user's password in the KDC database. Note, if the KDC only supports PKINIT authentication then the Kerberos V5 password management module should not be present in any password stacks. Related to PKINIT the Kerberos V5 password management module does not support changing the key store PIN used to access a user's private key and certificate. The following flags may be passed to pam_sm_chauthtok(3PAM): PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. Example 2 Authenticate Users Through Kerberos Only using password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 Example 3 Authenticate Through Kerberos Optionally using password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. Example 4: Authenticate Users Through Kerberos PKINIT as First Choice The following is an excerpt of a sample pam.conf configuration file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication (using PKINIT) fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for login. Note, the user is prompted once for the PIN by pam_krb5. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 5: Authenticate Users Through Kerberos PKINIT Only The following example allows authentication only to users that have Kerberos-based accounts requiring PKINIT authentication. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit Example 6: Authenticate Users Through Kerberos PKINIT Optionally The following example allows users to acquire a Kerberos credential using PKINIT authentication if they have a Kerberos account. Whether pam_krb5 succeeds or fails the user must provide their Unix password in order to login. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 7: Authenticate Users Through Kerberos PKINIT as a requirement. The following example allows users to login if pam_krb5 is able to acquire a Kerberos credential via PKINT authentication and in addition must provide their Unix password to pam_unix_auth. login auth required pam_unix_cred.so.1 login auth required pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_unix_auth.so.1 Example 8: Authenticate Users Through Kerberos PKINIT as a requirement using the PAM_AUTHTOK password. The following example allows users to login using their PAM_AUTHTOK password acquired by pam_authtok_get. This password would be used by pam_krb5 to try PKINIT authentication and would also be used by pam_unix_auth to authenticate the user via the user's Unix account. If PKINIT requires a password/PIN that differs from the user's Unix password then pam_krb5 must be stacked above pam_authtok_get. login auth required pam_unix_cred.so.1 login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 pkinit login auth required pam_unix_auth.so.1 Example 9: Authenticate Users Through Kerberos PKINIT, fall back to password based krb auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. If PKINIT succeeds the user will not be prompted for their password. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will return success. If PKINIT fails the user will be prompted for their Kerberos password. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 Example 10: Require users to authenticate either through Kerberos PKINIT or fall back to password based krb auth if PKINIT fails and authenticate with other required PAM modules. The following example allows users to acquire a Kerberos credential using PKINIT authentication or using password based authentication if PKINIT fails. Note, if pam_krb5 PKINIT succeeds, the second instance of pam_krb5 will not try password authentication and will just return ignore. If pam_krb5 PKINIT fails the second instance of pam_krb5 will try password based authentication and return success or failure. login auth required pam_unix_cred.so.1 login auth optional pam_krb5.so.1 pkinit login auth requisite pam_authtok_get.so.1 login auth required pam_krb5.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 Example 11: Require users to authenticate either through Kerberos PKINIT or fall back to pam_pkcs11 auth if PKINIT fails. The following example allows users to acquire a Kerberos credential using PKINIT authentication or if that fails use pam_pkcs11 to validate the user's PIN using their certificate and private key. login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 pkinit login auth sufficient pam_pkcs11.so.1 ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_/m2ydJNcdqsCrtxGxOdR4A) Content-type: text/plain; NAME=pam_krb5.5.diffmarked; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pam_krb5.5.diffmarked --- pam_krb5_man_orig Mon Dec 14 19:47:10 2009 +++ pam_krb5_man_pkinit Mon Dec 14 19:49:41 2009 @@ -1,657 +1,863 @@ Standards, Environments, and Macros pam_krb5(5) NAME pam_krb5 - authentication, account, session, and password management PAM modules for Kerberos V5 SYNOPSIS /usr/lib/security/pam_krb5.so.1 DESCRIPTION The Kerberos V5 service module for PAM provides functional- ity for all four PAM modules: authentication, account management, session management, and password management. The service module is a shared object that can be dynamically loaded to provide the necessary functionality upon demand. Its path is specified in the PAM configuration file. Kerberos Authentication Module The Kerberos V5 authentication component provides functions to verify the identity of a user, pam_sm_authenticate(), and to manage the Kerberos credentials cache, pam_sm_setcred(). pam_sm_authenticate() authenticates a user principal through the Kerberos authentication service. If the authentication request is successful, the authentication service sends a ticket-granting ticket (TGT) back to the service module, which then verifies that the TGT came from a valid Key Dis- tribution Center (KDC) by attempting to get a service ticket for the local host service. For this to succeed, the local host's keytab file (/etc/krb5/krb5.keytab) must contain the entry for the local host service. For example, in the file host/hostname.com@REALM, hostname.com is the fully qualified local hostname and REALM is the default realm of the local host as defined in /etc/krb5/krb5.conf. If the host entry is not found in the keytab file, the authentication fails. Administrators may optionally disable this "strict" verifi- cation by setting "verify_ap_req_nofail = false" in /etc/krb5/krb5.conf. See krb5.conf(4) for more details on this option. This allows TGT verification to succeed in the absence of a keytab host principal entry. + Note that if pam_sm_authenticate() is called and the + "pkinit" module option is set the Kerberos V5 authentication + module will try to do PKINIT authentication if both the + system and the KDC are configured to support this type of + authentication. This form of authentication uses a user's + certificate and private key to acquire the user's initial + Kerberos credential (TGT). Note that one of the keystore + formats supported is PKCS11 which supports use of any PKCS11 + compatible keystore capable of storing the required + credential and private key needed for PKINIT authentication + (PKCS11 compatible smartcards are an example). See + krb5.conf(4) for more details on PKINIT configuration. Also + note that this form of authentication is typically useful + for services where the system on which the auth stack is + being processed has access to the user's certificate and + private key. + If pam_sm_authenticate() is called and the "pkinit" module + option is not set then the Kerberos V5 authentication module + will do password based authentication. + + In either case, if the PAM_AUTHTOK password item has been + set when pam_sm_authenticate() is called, which is the case + when pam_krb5 is stacked after pam_authtok_get in the auth + stack, the Kerberos V5 authentication module will use that + PAM_AUTHTOK password for either PKINIT or password based + Kerberos authentication. + + If the PAM_USER item is not set pam_krb5 with the "pkinit" + option will prompt for and set that item. + + If the PAM_AUTHTOK password item has not been set when + pam_sm_authenticate() is called, which is the case when + pam_krb5 is stacked before pam_authtok_get in the auth + stack, and the "pkinit" option is present the Kerberos V5 + authentication module will allow the Kerberos pkinit preauth + plugin to prompt for whatever information is needed to + perform PKINIT (typically this will be for the user's PIN). + No PAM items are set via this prompting. See krb5.conf(5) + for more information on PKINIT configuration options. + + If it is desirable to initially have the Kerberos V5 + authentication module try PKINIT Kerberos authentication and + fall back to password based Kerberos authentication then + either the sufficient or optional control flags must be + provided for the instance of pam_krb5 with the "pkinit" + module option set and another instance of pam_krb5 without + the "pkinit" module option must be stacked below + pam_authtok_get. If there are PAM modules other than + pam_krb5 that must be evaluated below pam_authtok_get then + the control flag should be set to optional for the instance + of pam_krb5 with the "pkinit" module option set otherwise + the control flag should be set to sufficient. + + Note that only two instances of pam_krb5 are supported in a + auth stack. + pam_sm_authenticate(3PAM) may be passed the following flag: PAM_DISALLOW_NULL_AUTHTOK This flag is ignored. The Kerberos authentication mechanism will not allow an empty password string by default. SunOS 5.11 Last change: 8 Apr 2008 1 Standards, Environments, and Macros pam_krb5(5) pam_sm_setcred() creates and modifies the user's credential cache. This function initializes the user's credential cache, if it does not already exist, and stores the initial credentials for later use by Kerberized network applica- tions. The following flags may be set in the flags field. They are best described by their effect on the user's credential cache. PAM_ESTABLISH_CRED Stores the initial credentials in the user's credential cache so that the user may access Kerberos network ser- vices. If a successful authentication pass was made, the new credentials are stored in the credential cache, overwriting any existing credentials that were previ- ously stored. If an unsuccessful authentication pass was made, PAM_CRED_UNAVAIL is returned. PAM_DELETE_CRED This flag has no effect on the credential cache and always returns PAM_SUCCESS. The credential cache is not deleted because there is no accurate method to determine if the credentials are needed by another process. The credential cache may be deleted with the kdestroy(1) command. PAM_REINITIALIZE_CRED Deletes the user's existing credential cache, if it exists, and creates a new credential cache. The new credentials are stored in the new cache and the user's ticket lifetime and renewable life time values are reset. PAM_REFRESH_CRED Does not require a previous authentication pass, but if a successful one is made, the new credentials are stored in the credential cache. If a previous authentication pass was not made or was unsuccessful, an attempt to renew the existing credentials is made. Note that this function fails if the user's renewable ticket lifetime is expired. The following options can be passed to the Kerberos V5 authentication module: SunOS 5.11 Last change: 8 Apr 2008 2 Standards, Environments, and Macros pam_krb5(5) debug Provides syslog(3C) debugging information at LOG_DEBUG level. nowarn Turns off warning messages. + pkinit Indicates that the Kerberos V5 authentication + module should try Kerberos PKINIT authentication + instead of the default password based Kerberos + authentication. + Kerberos V5 Account Management Module The Kerberos account management component provides a func- tion to perform account management, pam_sm_acct_mgmt(). This function checks to see if the pam_krb5 authentication module has noted that the user's password has not expired. The fol- lowing options may be passed in to the Kerberos V5 account management module: debug Provides syslog(3C) debugging information at LOG_DEBUG level nowarn Turns off warning messages. Also, does not query KDC for impending password expiration information used to warn the user. Kerberos V5 Session Management Module The Kerberos V5 session management component provides func- tions to initiate pam_sm_open_session() and terminate pam_sm_close_session() Kerberos sessions. For Kerberos V5, both pam_sm_open_session and pam_sm_close_session() are null functions, returning PAM_IGNORE. Kerberos V5 Password Management Module The Kerberos V5 password management component provides a function to change passwords, pam_sm_chauthtok(), in the Key - Distribution Center (KDC) database. The following flags may - be passed to pam_sm_chauthtok(3PAM): + Distribution Center (KDC) database. + Note that if the Kerberos V5 authentication module used + PKINIT authentication in the auth stack then the Kerberos V5 + password management module will return PAM_IGNORE in the + following cases: + + - The new password is NULL. + - The old password is NULL. + - Verification of the old password fails. + + The rational behind this is that the KDC may not allow a + PKINIT user to change/set a password since the user may be + expected to use PKINIT only. If all of the cases above are + false the Kerberos V5 password management module will try to + change the user's password in the KDC database. + + Note, if the KDC only supports PKINIT authentication then + the Kerberos V5 password management module should not be + present in any password stacks. + + Related to PKINIT the Kerberos V5 password management module + does not support changing the key store PIN used to access a + user's private key and certificate. + + The following flags may be passed to pam_sm_chauthtok(3PAM): + PAM_CHANGE_EXPIRED_AUTHTOK The password service should only update the user's Ker- beros password if it is expired. Otherwise, this func- tion returns PAM_IGNORE. The default behaviour is to always change the user's Kerberos password. PAM_PRELIM_CHECK This is a null function that always returns PAM_IGNORE. PAM_UPDATE_AUTHTOK SunOS 5.11 Last change: 8 Apr 2008 3 Standards, Environments, and Macros pam_krb5(5) This flag is necessary to change the user's Kerberos password. If this flag is not set, pam_krb5 returns PAM_SYSTEM_ERR. The following option can be passed to the Kerberos V5 pass- word module: debug Provides syslog(3C) debugging information at LOG_DEBUG level. ERRORS The following error codes are returned for pam_sm_authenticate(): PAM_AUTH_ERR Authentication failure PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. PAM_SUCCESS Successfully obtained Kerberos creden- tials . PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error codes are returned for pam_sm_setcred(): PAM_AUTH_ERR Authentication failure. PAM_BUF_ERR Memory buffer error. PAM_IGNORE The user is "root" and the root key exists in the default keytab. SunOS 5.11 Last change: 8 Apr 2008 4 Standards, Environments, and Macros pam_krb5(5) PAM_SYSTEM_ERR System error. PAM_SUCCESS Successfully modified the Kerberos creden- tial cache. The following error codes are returned for pam_sm_acct_mgmt(): PAM_AUTH_ERR Authentication failure. PAM_IGNORE Kerberos service module pam_sm_authenticate() was never called, or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD Obtain new authentication token from the user. PAM_SERVICE_ERR Error in underlying service module. PAM_SUCCESS Kerberos principal account is valid. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. The following error code is returned for pam_sm_open_session() and pam_sm_close_session(): PAM_IGNORE These two functions are null functions in pam_krb5: The following error codes are returned for pam_sm_chauthtok(): PAM_AUTH_ERR Authentication failure. SunOS 5.11 Last change: 8 Apr 2008 5 Standards, Environments, and Macros pam_krb5(5) PAM_IGNORE The user has not been authenticated by Kerberos service module pam_sm_authenticate(), or the user is "root" and the root key exists in the default keytab. PAM_NEW_AUTHTOK_REQD User's Kerberos password has expired. PAM_SERVICE_ERR Error in module. At least one input parameter is missing. PAM_SYSTEM_ERR System error. PAM_USER_UNKNOWN An unknown Kerberos principal was requested. PAM_SUCCESS Successfully changed the user's Ker- beros password. EXAMPLES Example 1 Authenticate Users Through Kerberos as First - Choice + Choice using password based authentication The following is an excerpt of a sample pam.conf configura- tion file that authenticates users through the Kerberos authentication service and authenticates through the Unix login only if the Kerberos authentication fails. This arrangement is helpful when a majority of the users are networked by means of Kerberos and when there are only a few non-Kerberos type user accounts, such as root. The service illustrated below is for dtlogin. dtlogin auth requisite pam_smartcard.so.1 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 sufficient pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 Note that these changes should not be made to the existing krlogin, krsh, and ktelnet service entries. Those services SunOS 5.11 Last change: 8 Apr 2008 6 Standards, Environments, and Macros pam_krb5(5) require Kerberos authentication, so using a seemingly suffi- cient control flag would not provide the necessary func- tionality for privacy and integrity. There should be no need to change those entries. The following entries check for password expiration when dealing with Kerberos and Unix password aging policies: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 The following entries would change the Kerberos password of the user and continue to change the Unix login password only if the Kerberos password change had failed: other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 When changing Kerberos based user's password, use kpasswd(1). When changing a non-Kerberos user's password, it is recommended that the repository is specified (-r) with the passwd(1) command. - Example 2 Authenticate Users Through Kerberos Only + Example 2 Authenticate Users Through Kerberos Only using + password based authentication The following example allows authentication only to users that have Kerberos-based accounts. dtlogin auth requisite pam_smartcard.so.1 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 binding pam_krb5.so.1 dtlogin auth required pam_unix_auth.so.1 SunOS 5.11 Last change: 8 Apr 2008 7 Standards, Environments, and Macros pam_krb5(5) Typically, you would have another service specified in the pam.conf file that would allow local users, such as data- base, web server, system administrator accounts, to log in to the host machine. For example, the service name "login" could be used for these users. Note that these users should not belong to any roles. The rest of the module types look similar to that shown in the previous example: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 With binding specified in the following, it is important that non-Kerberos users specify the repository in which they reside using the -r option with the passwd(1) command. This configuration is also based on the assumptions that: o Kerberos users maintain only their Kerberos pass- words; o changing their Unix password is not necessary, given that they are authenticated only through their Kerberos passwords when logging in. other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password binding pam_krb5.so.1 other password required pam_authtok_store.so.1 - Example 3 Authenticate Through Kerberos Optionally + Example 3 Authenticate Through Kerberos Optionally using + password based authentication This configuration is helpful when the majority of users are non-Kerberos users and would like to authenticate through Kerberos if they happened to exist in the Kerberos database. The effect of this is similar to users voluntarily executing kinit(1) after they have successfully logged in: dtlogin auth requisite pam_smartcard.so.1 dtlogin auth requisite pam_authtok_get.so.1 dtlogin auth required pam_dhkeys.so.1 SunOS 5.11 Last change: 8 Apr 2008 8 Standards, Environments, and Macros pam_krb5(5) dtlogin auth required pam_unix_cred.so.1 dtlogin auth required pam_unix_auth.so.1 dtlogin auth optional pam_krb5.so.1 The rest of the configuration is as follows: other account requisite pam_roles.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password optional pam_krb5.so.1 Non-Kerberos users should specify their respective reposi- tories by using the -r option when changing their password with the passwd(1) command. + Example 4: Authenticate Users Through Kerberos PKINIT as First Choice + + The following is an excerpt of a sample pam.conf + configuration file that authenticates users through the + Kerberos authentication service and authenticates through + the Unix login only if the Kerberos authentication (using + PKINIT) fails. This arrangement is helpful when a majority + of the users are networked by means of Kerberos and when + there are only a few non-Kerberos type user accounts, such + as root. The service illustrated below is for login. Note, + the user is prompted once for the PIN by pam_krb5. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 5: Authenticate Users Through Kerberos PKINIT Only + + The following example allows authentication only to users that have + Kerberos-based accounts requiring PKINIT authentication. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + + Example 6: Authenticate Users Through Kerberos PKINIT Optionally + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication if they have a + Kerberos account. Whether pam_krb5 succeeds or fails the + user must provide their Unix password in order to login. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 7: Authenticate Users Through Kerberos PKINIT as a + requirement. + + The following example allows users to login if pam_krb5 is + able to acquire a Kerberos credential via PKINT + authentication and in addition must provide their Unix + password to pam_unix_auth. + + login auth required pam_unix_cred.so.1 + login auth required pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_unix_auth.so.1 + + Example 8: Authenticate Users Through Kerberos PKINIT as a + requirement using the PAM_AUTHTOK password. + + The following example allows users to login using their + PAM_AUTHTOK password acquired by pam_authtok_get. This + password would be used by pam_krb5 to try PKINIT + authentication and would also be used by pam_unix_auth to + authenticate the user via the user's Unix account. If PKINIT + requires a password/PIN that differs from the user's Unix + password then pam_krb5 must be stacked above pam_authtok_get. + + login auth required pam_unix_cred.so.1 + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 pkinit + login auth required pam_unix_auth.so.1 + + Example 9: Authenticate Users Through Kerberos PKINIT, fall + back to password based krb auth if PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. If PKINIT succeeds the + user will not be prompted for their password. Note, if + pam_krb5 PKINIT succeeds, the second instance of pam_krb5 + will not try password authentication and will return success. + If PKINIT fails the user will be prompted for their Kerberos + password. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + + Example 10: Require users to authenticate either through + Kerberos PKINIT or fall back to password based krb auth if + PKINIT fails and authenticate with other required PAM + modules. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or using password + based authentication if PKINIT fails. Note, if pam_krb5 + PKINIT succeeds, the second instance of pam_krb5 will not try + password authentication and will just return ignore. If + pam_krb5 PKINIT fails the second instance of pam_krb5 will + try password based authentication and return success or + failure. + + login auth required pam_unix_cred.so.1 + login auth optional pam_krb5.so.1 pkinit + login auth requisite pam_authtok_get.so.1 + login auth required pam_krb5.so.1 + login auth required pam_dhkeys.so.1 + login auth required pam_unix_auth.so.1 + + Example 11: Require users to authenticate either through + Kerberos PKINIT or fall back to pam_pkcs11 auth if + PKINIT fails. + + The following example allows users to acquire a Kerberos + credential using PKINIT authentication or if that fails use + pam_pkcs11 to validate the user's PIN using their certificate + and private key. + + login auth required pam_unix_cred.so.1 + login auth sufficient pam_krb5.so.1 pkinit + login auth sufficient pam_pkcs11.so.1 + + ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: ____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|_____________________________| | Interface Stability | Evolving | |_____________________________|_____________________________| SEE ALSO kdestroy(1), kinit(1), kpasswd(1), passwd(1), ktkt_warnd(1M), libpam(3LIB), pam(3PAM), pam_sm(3PAM), pam_sm_acct_mgmt(3PAM), pam_sm_authenticate(3PAM), pam_sm_chauthtok(3PAM), pam_sm_close_session(3PAM), pam_sm_open_session(3PAM), pam_sm_setcred(3PAM), syslog(3C), pam.conf(4), attributes(5), kerberos(5), krb5envvar(5) NOTES The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. SunOS 5.11 Last change: 8 Apr 2008 9 Standards, Environments, and Macros pam_krb5(5) On successful acquisition of initial credentials (ticket- granting ticket), ktkt_warnd(1M) will be notified, to alert the user when the initial credentials are about to expire. SunOS 5.11 Last change: 8 Apr 2008 10 --Boundary_(ID_/m2ydJNcdqsCrtxGxOdR4A)-- From gww@sac.sfbay.sun.com Tue Dec 15 12:24:28 2009 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFKOSHb019181 for ; Tue, 15 Dec 2009 12:24:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFKOROC014462 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Dec 2009 14:24:27 -0600 (CST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUP00E0BNCRDB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 12:24:27 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUP009XANCRPL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 12:24:27 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nBFKOPYM001624; Tue, 15 Dec 2009 12:24:25 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFKOP5H019178; Tue, 15 Dec 2009 12:24:25 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nBFKOPLl019177; Tue, 15 Dec 2009 12:24:25 -0800 (PST) Date: Tue, 15 Dec 2009 12:24:25 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2009/576 pam_krb5 pkinit - final spec To: William.Fiveash@sun.com Cc: PSARC-ext@sun.com, Wyllys.Ingersoll@sun.com, kerberos-discuss@opensolaris.org Message-id: <200912152024.nBFKOPLl019177@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 73 > I've attached updated pam_krb5.5 and pam_krb5.5.diffmarked. +1 Gary.. From Wyllys.Ingersoll@Sun.COM Tue Dec 15 12:58:36 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nBFKwZfG019962 for ; Tue, 15 Dec 2009 12:58:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id nBFKwZ4Z060719 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 15 Dec 2009 13:58:35 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KUP00J01OXNUI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 12:58:35 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KUP00E7EOXM8E60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 12:58:34 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nBFKwYKG016831 for ; Tue, 15 Dec 2009 20:58:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUP00J00O3IIY00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 13:58:34 -0700 (MST) Received: from [192.168.1.50] (usr136.res.openband.net [216.40.74.136]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUP00INFOXABK90@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 15 Dec 2009 13:58:22 -0700 (MST) Date: Tue, 15 Dec 2009 15:58:22 -0500 From: Wyllys Ingersoll Subject: PSARC 2009/576 pam_krb5 pkinit - docs updated Sender: Wyllys.Ingersoll@Sun.COM To: PSARC-ext , Will Fiveash Message-id: <4B27F86E.5000200@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 157 I updated the man page and the diff-marked man page for the pam_krb5 pkinit project. I *think* we are done, and hope to mark it approved tomorrow. -Wyllys