On Mon, Feb 04, 2002 at 04:51:30PM -0700, Joseph Galbraith wrote:
> > > Actually it might even be better to have it as a MUST since not doing
> > > so allows for the potential of a client/server pair that can bypass
> admin
> > > policy and we shouldn't really encourage that.
> >
> > Well, the password policy should be entirely enforced by the server.
> >
> > MUST would rule out a "soft password expiration" policy where the
> > server could strongly suggest, but not require, a password change, for
> > some time interval before the change became mandatory..
>
> I think this would be difficult to achieve
> because of the way the authentication service works.
You mean, "the way it works now". ie, trying to shoehorn in a soft password
expiration will be difficult.
[ problems with having only a single SSH_MSG for change password ]
> We could treat the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
> as a failure message, in which case how does the
> client proceed to success? The password mechanism
> would have to behave differently the second
> time through (stateful) -- I find this distasteful.
I agree, that would be poor.
> If we really wanted to clean this up,
> we should (and I really don't think we
> want to do all this now):
>
> 1. Allow authentication messages at any time --
> requests after success are immediately failed
> without further checking if they use a different
> username.
[...]
> 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING
> which included how much time was left before
> expiration. The server would send this and
> the usual success or partial failure message.
> The client would display a "You password will
> expire in n days. Would you like to change
> it now?"
This seems superior.
> 3. The client could issue a change request at
> any time (because of #1)
>
> And as long as were making changes like this,
> we should:
>
> 4. Add a message that the server can send to
> the client to require re-authentication
> (credentials expired.)
Interesting.
I'd just like to note that keyboard-interactive can handle this
transparently and cleanly. For the "password" auth type, I think you
really do need to implement option #2.
Also, I think this should be implemented. Almost all (if not all)
modern unices support warning before password expiration; ssh should
support this.