Subject: userauth and multiple simultaneous requests...

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 18 Dec 2001 17:14:48 -0700

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 18 Dec 2001 19:24:08 -0500

A couple comments on the wording:

   A request that results in further exchange of messages
   will be aborted by second request

by "a" 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 

Perhaps "may" here?  Userauth requests could involve variable numbers
of messages (GSSAPI is notorious for this).

   result in

Is there any good reason why the second SHOULD shouldn't be a MUST?
Doesn't seem like it should be hard to get this right..  is there
deployed code which gets this wrong?

					- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 20 Dec 2001 12:27:33 -0700

>    will be aborted by second request

Yep.

> of messages (GSSAPI is notorious for this).

I think the "if" in "if the first" reflect the
conditional nature of this -- I guess I'm not sure
where "may" would be put -- it doesn't really
make sense as in "if the first request may" does
it?

> deployed code which gets this wrong?

Well -- I consider it a bug, but I believe
our implementation currently would probably
send a unimplemented packet, or possible
disconnect.

In fact, a SHOULD at least leaves the door
open for a client / server to refresh expired
credentials by later sending additional USERAUTH
request messages -- though there is currently
no way for the server to notify the client that
this is necessary.

(I'm not actually sure this feature is necessary.)

- Joseph