pkinit and passwords issues

[Will Fiveash]

On Fri, Feb 12, 2010 at 05:57:32PM -0500, Jeffrey Altman wrote:
> On 2/11/2010 6:43 PM, Sam Hartman wrote:
> >>>>>> "Will" == Will Fiveash <William.Fiveash at sun.com> writes:
> > 
> >     Will> I've noticed that if a princ's password has expired the KDC is
> >     Will> sending back a passwd expired error message even if PKINIT is
> >     Will> being attempted with a valid cert.  This strikes me as buggy.
> >     Will> Why should the KDC check the validity of a princ's password if
> >     Will> the princ is attempting PKINIT preauth?
> > 
> >     Will> I believe the problem lies with this check in
> >     Will> validate_as_request():
> > 
> > 
> > It seems like this falls into two categories:
> > 
> > 1) The principal has a password that is sometimes used.  In this case
> > I'd think a lot of sites would actually find resetting the password
> > valuable at this point.
> 
> Agreed.  However, I'm not sure it is relevant to the current
> authentication.  We have the ability to send a message to the user
> upon successful authentication.  This is often used to indicate how
> many days left until the password would expire.   I think it is
> perfectly reasonable to accept the PKINIT authentication and send
> a message that the password has expired and request that the user
> change it.

That seems reasonable to me as long as PKINIT can succeed.

> Given the prevalence of NATs and the fact that password changing
> still does not work from behind them I am reluctant to lock someone
> out if their pre-authentication method doesn't rely on use of the
> password.
> 
> > So, if there is a mechanism to bypass this check it should be optional.
> 
> Adding a kdc.cnf option to require that the password be changed
> regardless of the pre-auth method being used seems reasonable but
> I would not want it to be the default.

Same here.

> > 2) There is no valid password.  In which, the password should not be set
> > to expire.
> 
> Setting a random password and setting it to never expire results in
> there being a password that can be brute forced over a long period of
> time and used as a backdoor.  It would be much better if a property on
> the principal simply indicated "no password authentication permitted"
> and be done with it.

Yeah, this is more straightforward than having to specify which preauth
methods a princ is allowed to use.  Perhaps there could be krb5.conf
rules that would specify which princs are allowed to use password auth
(like service princs) and which princs are not allowed using a regex
syntax.

> > The biggest question I have about how to fix this is how to decide in a
> > generic manner whether you're using a preauthentication mechanism for
> > which password expiration is important.
> > do you have any thoughts on how to accomplish this?
> 
> I recommend a table with an entry for each loaded pre-auth mechanism
> that would be initialized by the mechanism.

Right, it makes sense to me to have the pre-auth mech indicate this and
modify the KDC to look at that table in order to determine what to do
for the pre-auth mech currently being used.

> Something else to think about is "can a password change authenticated by
> a PKINIT work?"   Has anyone tried this?   I'm not sure the existing
> password change mechanism on the client side can support this from a
> UI perspective.

I have not tried this but given what I've seen so far I doubt it is
supported.

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA