pkinit and passwords issues

[Jeffrey Altman]

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.

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.

> 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.

> 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.

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.

Jeffrey Altman