Subject: secsh-userauth

From: Markus Friedl <[email-masked]>
Date: Thu, 15 Mar 2001 18:34:48 +0100

Hi,

what is the rational for the following paragraphs from
draft-ietf-secsh-userauth-09.txt?

> 2.1.  Authentication Requests
> 
> The user name and service are repeated in every new authentication
> attempt, and MAY change.  The server implementation MUST carefully check
> them in every message, and MUST flush any accumulated authentication
> states if they change.  If it is unable to flush some authentication
> state, it MUST disconnect if the user or service name changes.

why does the server have to disconnect if it is unable (or does not
want) to flush the current authentication state?  is this really a MUST?
I'd prefer a SHOULD, especially since one of the next paragraphs say:

> If the requested user does not exist, the server MAY disconnect, or MAY
> send a bogus list of acceptable authentication methods, but never accept
> any.  This makes it possible for the server to avoid disclosing
> information on which accounts exist.  In any case, if the user does not
> exist, the authentication request MUST NOT be accepted.

So would it be reasonable if the server does the same thing if the username
changes during authentication?

-markus

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 15 Mar 2001 21:54:12 +0200 (EET)

> I'd prefer a SHOULD, especially since one of the next paragraphs say:

It is a MUST, because some authentication methods may accumulate implicit
state in global variables.  For example, certain styles of implementing
PAM or Kerberos based authentication may leave tickets or other data in
essentially global data.

If the user name changes, it is critical that all such cached
data/credentials is destroyed before starting to authenticate as another
user.  If we permit leaving such globally stored data/credentials hanging
around when the user name changes, we may end up in a situation where
first trying to (partially) authenticate as one user and then as another
user gives you more rights than directly trying to authenticate as
yourself.

> changes during authentication?

Yes, it would be reasonable to say that the server MUST EITHER disconnect
OR behave as if the user name did not exist.

It is NOT acceptable to just permit login as another user if already
created credentials cannot be removed.

(Note that we are talking about a mostly theoretical situation.
In most cases, one does not create any credentials before the
whole login sequence is completeled.  However, Kerberos and PAM APIs may
leave global credentials in some potentially real cases, and this may
become a real security issue when multiple authentications are required
for access).  This may also be an issue if certain credentials need to be
created before login e.g. to access files (such as .shosts) in the user's
remotely mounted home directory.)

    Tatu

SSH Communications Security           http://www.ssh.com/
SSH IPSEC Toolkit                     http://www.ipsec.com/
SSH Secure Shell                      http://www.ssh.com/products/ssh

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 15 Mar 2001 15:14:15 -0500

> OR behave as if the user name did not exist.

i've added this to the last-call issues list.

suggested reword:

   The user name and service are repeated in every new authentication
   attempt, and MAY change.  The server implementation MUST carefully check
   them in every message, and MUST flush any accumulated authentication
   states if they change.  If it is unable to flush some authentication
   state, it MAY immediately disconnect; if it does not disconnect, it
   MUST NOT accept any future authentication requests (handling the
   client as if it had presented a nonexistant user name, as below).

---

From: Markus Friedl <[email-masked]>
Date: Thu, 15 Mar 2001 21:57:46 +0100

> PAM or Kerberos based authentication may leave tickets or other data in

yes, i understand this, my question was ambiguous: i was not
asking about the 'MUST flush', but the 'MUST disconnect'.

> OR behave as if the user name did not exist.

ok, so this is another issue for the meeting?

-markus

---

From: [email-masked] (Niels M�ller)
Date: 16 Mar 2001 12:12:29 +0100

> user gives you more rights than directly trying to authenticate as

Even if servers are permitted to disconnect, or stop responding
usefully to userauth requests, once the user name changes, I consider
such behaviour abnormal.

The recommended way to deal with user name change ought to be to throw
away any accumulated state and start over trying to authenticate the
new user.

In some cases (like strange PAM or kerberos interfaces you refer to,
or for an implementation that irreversibly changes it uid when
processing the first userauth-request) authenticating a new user may
be difficult or impossible, so I agree that behaviour you and Markus
describe should be allowed. But I don't think the spec should
recommend it.

For an extreme example, consider a userauth request with username ""
and method "none", followed by a request with username "nisse" and
method "password". There may be some odd configuration where the first
request actually succeeds, but except for that, I see no reason for
the server to collect any state that it is hard to throw away.

I view userauth requests processing as a logically stateless process
(at least as long as there are no "partial successes"). The server may
cache user information between requests, but I view that only as an
optimization.

Regards,
/Niels