userauth and multiple simultaneous requests...

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

Just before the meeting in SLC,
I discovered a flaw in the userauth
protocol while reviewing outstanding
issues for the gss draft, and we
spent some time discussing this
at the meeting.

I was asked to summarize the problem
for the list -- I've since reread the
userauth draft and am not sure if the
problem really exists.

So, here goes --

The problem, as discussed in the meeting,
is that the client is allowed to send
multiple outstanding requests.

So, lets say there is an authentication
method "x", which requires multiple
messages to be sent, and uses message
number 61 for the server to request
additional information from the client,
which is sent by the client using
message number 62.

Let's also say there is a different
method, "y", which also uses message
number 61 for the server to request
additional information from the client,
and message number 62 for the client
to send that information.

So, if the client sends "x" and then "y",
the server will respond to "x" with
a message 61 and than to y with a
packet type 61.

Now the client sends a packet 62 to
the server.  However, the server
has no way to determine if packet
62 goes with request "x" or request
"y".

----
Now, for the relevant texts from the draft,
that make this impossible, and make the
problem (mostly) go away:

The userauth draft contains the following text
in section 2.1:

   An authentication request MAY result in a further exchange of
   messages.  All such messages depend on the authentication method
   used, and the client MAY at any time continue with a new
   SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
   abandon the previous authentication attempt and continue with the new
   one.

and in 2.2:

   The client MAY send several authentication requests without waiting
   for responses from previous requests.  The server MUST acknowledge
   any failed requests with a SSH_MSG_USERAUTH_FAILURE message.
   However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once
   SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
   requests received after that SHOULD be silently ignored.

So as soon as the client sends "y", the server
discards "x".

---
The only real problem is that it is unclear
what should happen in the event that a implementation
receives "y" before it has finished processing
"x" -- in most unix implementations this isn't
possible, but in a NT implementation it is
much more likely (to be possible.)

Should the server discard (and fail) "x", aborting
any processing being done on it, or, should
it finish processing "x" and then only process
"y" if "x" wasn't sufficient to authenticate
the user?

I would suggest the following wording change for
section 2.2:

   The client MAY send several authentication requests
   without waiting for responses from previous requests.
   The server MUST process each request completely and
   acknowledge any failed requests with a
   SSH_MSG_USERAUTH_FAILURE message before processing the
   next request.

   A request that results in further exchange of messages
   will be aborted by second request, so it is not possible
   to send a second request without waiting for a response
   from the server, if the first request will result in
   further exchange of messages.  No SSH_MSG_USERAUTH_FAILURE
   message will be sent for the aborted method.

   SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once
   SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
   requests received after that SHOULD be silently ignored.

This clarifies that the SSH_MSG_USERAUTH_REQUEST 
packet must be completely processed before considering
further requests (which might abort the method
started by the SSH_MSG_USERAUTH_REQUEST packet.)

And that if a method is abandoned due to a
new SSH_MSG_USERAUTH_REQUEST being received,
there is no notification of such to the client.

- Joseph