Implicit server authentication: Proposed clarification

[nisse%lysator.liu.se@localhost (Niels Möller)]

Joseph Galbraith <galb-list%vandyke.com@localhost> writes:

> The only case where you could run into trouble is if the
> client assumes it's service request was going to succeed
> and sent the first userauth packet at the same time.

I think clients are supposed to be able to do exactly that. Peter
complained earlier about the chattyness of the userauth protocol, but
it doesn't have to be chatty. The client can send a password or public
userauth key + signature immediately after the SERVICE_REQUEST packet,
perhaps in the same IP packet. That way, one can connect and login
using a fairly small number of roundtrips, which I believe was one of
the original design goals.

> And if someone ever introduced a different service (which could
> easily be done in an extension draft or even using a proprietary
> @dns.domain extension) such a client would fail to interoperate or
> to fail in a gracefully manner.

Sorry, that's not how the protocol is specified. Section 9 in the
transport draft says clearly

   If the server rejects the service request, it SHOULD send an
   appropriate SSH_MSG_DISCONNECT message and MUST disconnect.

A client will not get a second chance if the service request fails,
because then the server MUST disconnect. [2]

And I also think it's appropriate for a client to expect that if it
sends a service request and a userauth request immediately after each
other, and the server rejects the service request, then the userauth
request will be ignored with no interesting side effects on the
server.

And that's why the "implicit server authentication" is dangerous, if
ever implemented: If you end up in a situation where you share your
session key with the attacker, but not with the server, then you can
end up sending your password in a packet the attacker can read, and
discover too late that you don't share a session key with the server.

I think the simplest resolution of this issue is to keep the current
text, "Note that after a key exchange with implicit server
authentication, the client MUST wait for response to its service
request message before sending any further data.", and clarify the
definition of "implicit server authentication".

So I propose the following change to the final paragraph of section 6,
Key Exchange:

Before:

   Server authentication in the key exchange MAY be implicit.  After a
   key exchange with implicit server authentication, the client MUST
   wait for response to its service request message before sending any
   further data.

After:

   A key exchange method uses "explicit server authentication" if the
   keyexchange messages include a signature or other proof of the
   server's authenticity.  A key exchange method uses "implicit server
   authentication" if, in order to prove its autenticity, the server
   also has to prove that it knows the shared secret K, by sending a
   message and a corresponding MAC which the client can verify. [1]

   All currently defined key exchange methods use explicit server
   authentication.  However, key exchange methods with implicit server
   authentication MAY be used with this protocol.  After a key exchange
   with implicit server authentication, the client MUST wait for
   response to its service request message before sending any further
   data.

I don't feel to strongly about this issue, and the proposal to just
delete all text about implicit server authentication. But I don't
think we really should start to strike out features from the protocol
at this stage. So I hope the above clarification is good enough, or if
not, that somebody else is willing to improve it shortly. Then we can
put this issue at rest.

[1] It seems like the server being able to decrypt and verify the
client's SERVICE_REQUEST message might also be important. Perhaps one
could end up with server and client sharing keys properly in the
server->client direction, but not client->server.

But I don't think this can happen, due to the way session keys are
derived (section 6.2). A proof of knowledge of K should be sufficient
for the client to establish the server's autenticity. If this
verification succeeds, and the client still does not have the right
keys for the client->server direction, then that's a serious security
hole, but it's a hole somewhere in the keyexchange and session key
generation, and I think it's fair to say that it's not server
authentication in particular that is broken.

[2] If you want to try several new fancy services, I think a more
interoperable way to do that is to first ask for the userauth service,
and then try several userauth requests with the "none" method and
varying service names.

Regards,
/Niels