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

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

> > 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.
Quite frankly, in most real world cases, the user
is either going to have to change their password
or disconnect.  The new wording allows the user
to pick an alternative to password, but if the
user had an alternative they probably would have
used it in the first place.

On the other hand, the new wording does take the
burden of enforcing this away when the server really
doesn't need to enforce it -- the server just MUST NOT
accept an expired password.

The challenge in allowing "soft password expiration"
as I understand what you mean is the question of
what the client should do if he/she has only a password
to authenticate with and they don't want to change it.

In this case, the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
message really isn't a failure message (we'd probably
want two different messages one that meant you can't
authenticate with password until you change it, and
one that meant you should change your password soon.)

If it isn't a failure message, what's the next step?
There is really only one thing that really make
sense to me -- The server sends a SUCCESS message
or a partial failure.  (We need this because
of the partial failure case -- the password is okay,
but more authentication is necessary.)

If the server does this, in the success case it
is no longer possible for the user to change
their password (authentication messages after
success must be ignored.)

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.

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.

   Authentication requests after success MAY NOT
   change the authorization status of the connection.
   (Processes already running, etc.)

   Failed requests don't affect the authentication /
   authorization status.  (We need this because the
   client might have sent a whole bunch of requests
   without waiting to find out which one would
   succeed.)

   The server MAY count failed requests against
   a authentication attempt counter even after
   success, though any such counter SHOULD be
   reset to zero upon success.

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

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

- Joseph