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

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

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

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.

- Joseph