pkinit and passwords issues

[Nicolas Williams]

On Fri, Feb 12, 2010 at 05:57:32PM -0500, Jeffrey Altman wrote:
> On 2/11/2010 6:43 PM, Sam Hartman wrote:
> > 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.

It's not just that.  A customer might want to be able to enforce a
policy that only PKINIT is used (coupled, for example, with a smartcard
key/cert provisioning process to ensure that smartcards are used).

> I recommend a table with an entry for each loaded pre-auth mechanism
> that would be initialized by the mechanism.

I'm not sure I follow.  I think what we need is a per-user pre-auth
policy.  Because pre-auth is an open set, the manner in which policy can
be specified per-principal needs to be extensible.  Either a TL data scheme
or per-policy equivalent seem appropriate.

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

True.  Changing an expired password using PKINIT could (would) obviate
the need to prompt for the old password, for example.

Nico
--