Re: secsh-userauth

[Tatu Ylonen <ylo%ssh.com@localhost>]

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

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.

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

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