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

From: Darren Moffat <[email-masked]>
Date: Mon, 4 Feb 2002 14:51:57 -0800 (PST)

>> Based on recent traffic I think we might have one outstanding issue,
>> to do with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. Currently the text allows
>> the client to ignore the message and assume SUCCESS (at least that is how
>> I read it).  
>
>I don't read it that way -- the current text is just plain silent
>about both client and server behavior should the client not send a
>password change request.
>
>I assume the proposed fix is to say something like:
>
>	server MAY send an error message and drop the connection if
>	client fails to send a password change request.

I could live with that but I would change the MAY to a SHOULD (I think
the final outcome is pretty much the same but it is more a hint to where the
burden of responsibility should be).  Compare this to telnet if you
have to change your password you probably can't get past giving a good
new password. 

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.

I'm okay with the server ignoring the client sending PASSWD_CHANGEREQ
messages.

--
Darren J Moffat

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 04 Feb 2002 17:59:31 -0500

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

					- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 4 Feb 2002 16:51:30 -0700

> 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

---

From: Frank Cusack <[email-masked]>
Date: Mon, 4 Feb 2002 18:29:27 -0800

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

> time through (stateful) -- I find this distasteful.

I agree, that would be poor.

>    without further checking if they use a different

[...]

>    expire in n days.  Would you like to change

This seems superior.

>    the client to require re-authentication

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

---

From: "Dan O'Reilly" <[email-masked]>
Date: Mon, 04 Feb 2002 19:35:50 -0700

>modern unices support warning before password expiration; ssh should

True, they support warning, but how many prompt as option 2 would?  From
my standpoint, I'm more interested in VMS than UNIX systems, but the same
question applies.  If none do, this strikes me more as "gilding the lilly";
i.e., putting something in because it's potentially neat to do, rather
than useful or being used in the real world.

------
+-------------------------------+---------------------------------------+
| Dan O'Reilly                  |                                       |
| Principal Engineer            |  "Why should I care about posterity?  |
| Process Software              |   What's posterity ever done for me?" |
| http://www.process.com        |                    -- Groucho Marx    |
+-------------------------------+---------------------------------------+

---

From: Frank Cusack <[email-masked]>
Date: Mon, 4 Feb 2002 19:17:55 -0800

> True, they support warning, but how many prompt as option 2 would?  From

Yeah, you are right, no system (I know of) prompts and then gives you the
option to change your password.

> than useful or being used in the real world.

I think there does need to be a way to pass the warning message, which
currently does not exist in the "password" method.  There could be a
generic SSH_MSG_USERAUTH_PASSWD_MESSAGE.  The PASSWD_EXPIRING message
has the advantage that the client can prompt the user to change it now,
but the disadvantage of being a very specific message.  While in principle
I like the general case, the "password" method already has a design of
very specific messages, I believe this should continue for consistency.

If you want to handle generic/arbitrary messages, use keyboard-interactive.

So, in the above, instead of "The client would display ...", it seems better
to read "The client would display a warning message, and possibly prompt
the user to change the password now".

/fc

---

From: "Dan O'Reilly" <[email-masked]>
Date: Mon, 04 Feb 2002 21:10:05 -0700

>the user to change the password now".

I would change it to "the client MAY display a warning message...".  In
VMS, for example, a warning message of that nature would be displayed as
part of the normal login sequence.  Taking something like that out of
sequence, regardless of the fact that its sequence would largely be
inconsequential, tends to rile the feathers of many users.

------

---

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 5 Feb 2002 12:46:41 -0700

> >    expire in n days.  Would you like to change

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

---

From: Frank Cusack <[email-masked]>
Date: Tue, 5 Feb 2002 12:17:28 -0800

> 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

>    without the server asking for it.

I like it.

/fc

---

From: "Andersson, Mats" <[email-masked]>
Date: Wed, 6 Feb 2002 09:50:55 +0100 (CET)

> > > 2. Add a message like SSH_MSG_USERAUTH_PASSWD_EXPIRING

I don't see the reason to start doing this change NOW? The
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ as it stands in the draft might not be
perfect but it describes an easy way to handle password change requests
(and it's what is deployed). If one wants to refine this process, one can
either use keyboard-interactive authentication (which is superior in most
ways anyway!) OR one can add this new request at a later stage (it's not
something that has been implemented so why should it come into this set of
drafts?).

About the x509 "problem"; it is really solved with some small
clarifications (see my earlier mails on this). It can easily be moved to a
separate draft which at this stage might be better since there are no
"compliant" implementations anyway).

However, personally I'm happy with just the small clarifications on
signature formats, after all the "x509v3-sign-rsa" and "x509v3-sign-dss"
do REFER to rfc2459 (which in its turn refers PKCS#1), are those documents
underspecified or what are we suggesting here?!?

Also, if the x509 stuff isn't enough specified in the draft, mustn't we
remove ALL other public key formats (i.e. spki and pgp) too? (or are there
something which is clearer with those in the draft, in which case I must
be missing something?).

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Wed, 6 Feb 2002 10:08:10 +0100

On Wed, Feb 06, 2002 at 09:50:55AM +0100, Andersson, Mats wrote:
> I don't see the reason to start doing this change NOW?

Nor do I.

If you want to do fancy things, you can use kbd-interactive.