Ssh "security hole": proposed fix

[Tatu Ylonen <ylo@cs.hut.fi>]

I am thinking about the following solution to the issues pointed out
by David Mazieres.

These changes propose solutions to the following problems:
  - replay of password-authenticated sessions
  - corrupt server can use RSA authentication to log into another server

When the client receives SSH_SMSG_PUBLIC_KEY, it computes a 128 bit
(16 byte) value by converting the modulus of the public key into a
stream of bytes, msb first.  The cookie sent by the server is appended
to this stream.  Both sides compute the MD5 of the resulting stream.
This value will be called the "session id".

In the SSH_CMSG_SESSION_KEY message, the first 16 bytes of the session
key (before encryption) are xored with the 16 bytes of the session id.
This does not reveal plain text from the RSA-encrypted part, but binds
the encrypted session key to a specific cookie and server.  This
should eliminate the possibility of replay, because the cookie is
unique for each connection.

In all SSH_CMSG_AUTH_RSA_RESPONSE messages (used both in user and
client host authentication), append the session id to the decrypted
challenge before computing MD5.  The MD5 is computed from the
resulting 48 bytes.  This makes the response bound to the server
cookie and the server key, and should elinate using the same response
for another server.  (Faking the server key is hard, because the
client verifies that it matches the one stored in its database.)

If a server supports this revision of the protocol, it reports its
protocol version as 1.1.  If the server protocol version is 1.0, the
client displays a warning (recommending to update server software) and
uses the old protocol for compatibility.  The client reports the
protocol version that it will use.  The compatibility code will be
removed in a later release.  (The changes are easy to implement
compatibly.)

I would like to receive comments on this.

    Tatu