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

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

On Tue, Feb 05, 2002 at 12:46:41PM -0700, Joseph Galbraith wrote:
> > > 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.
> 
> The problem is, #2 depends on #1 -- so
> we have to make both changes in order for
> it to work -- with-out #1, the password
> change request will be ignored by the
> server.
> 
> Do we really want to make that kind of
> change now?  In my implementation it
> wouldn't really be that hard (actually,
> I think we currently get this wrong), but --

You could have an ack message from the client (either
USERAUTH_PASSWD_CHANGEREQ, or a "null" message.)  *Then*
the server responds success/failure.

You could just have the message be "ignored" by the client, ie the user
cannot change their password this way.

    S: SSH_MSG_USERAUTH_PASSWD_EXPIRING
    S: SSH_MSG_USERAUTH_SUCCESS

> What worrys me is that there would be
> other implications to this change
> that we haven't thought of -- we are
> trying to hurry to last call, so we might
> not have enough time to flush these out.
> 
> I think we should go with this proposal,
> which doesn't address the "soft expiration
> policy" issue, but resolves the basic
> ambiguity of how a client is obligated
> to respond to a CHANGEREQ message:
> 
>    Normally, the server responds to this message with success or
>    failure.  However, if the password has expired the server SHOULD
>    indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
>    instead.  In any case the server MUST NOT allow an expired password
>    to be used for authentication.
> 
>      byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
>      string    prompt (ISO-10646 UTF-8)
>      string    language tag (as defined in [RFC1766])
> 
>    In this case, the client MAY continue with a different
>    authentication method, or request a new password from
>    the user and retry password authentication using the
>    following message. The client MAY also send this message
>    instead of the normal password authentication request
>    without the server asking for it.

I like it.

/fc