Re: WG Last Call (third time's the charm?) for SSH core drafts

[Frank Cusack <fcusack%fcusack.com@localhost>]

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.

/fc