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
