Bryan,
> But if Eve is later challenged to prove her identity (that she must now
> maintain the illusion of being Alice), what prevents Eve from passing
> the challenge on to the real Alice, getting valid results, and then
> passing them back to Bob?

Eve (and Alice) is not challenged in any way. As ssh server (Alice _is_
ssh server and Eve is trying to pretend to be the ssh server) it only
signs the so-called 'exchange hash' that is generated independently by
Alice and Bob in the process of Diffie-Hellman exchange. And this hash
is not transmitted over the wire.

The following should help you to understand the things: an exempt from
RFC4253 (http://www.ietf.org/rfc/rfc4253.txt), section 8:
-----
8.  Diffie-Hellman Key Exchange

   The Diffie-Hellman (DH) key exchange provides a shared secret that
   cannot be determined by either party alone.  The key exchange is
   combined with a signature with the host key to provide host
   authentication.  This key exchange method provides explicit server
   authentication as defined in Section 7.

   The following steps are used to exchange a key.  In this, C is the
   client; S is the server; p is a large safe prime; g is a generator
   for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
   identification string; V_C is C's identification string; K_S is S's
   public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's
   SSH_MSG_KEXINIT message that have been exchanged before this part
   begins.

   1. C generates a random number x (1 < x < q) and computes
      e = g^x mod p.  C sends e to S.

   2. S generates a random number y (0 < y < q) and computes
      f = g^y mod p.  S receives e.  It computes K = e^y mod p,
      H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
      (these elements are encoded according to their types; see below),
      and signature s on H with its private host key.  S sends
      (K_S || f || s) to C.  The signing operation may involve a
      second hashing operation.

   3. C verifies that K_S really is the host key for S (e.g., using
      certificates or a local database).  C is also allowed to accept
      the key without verification; however, doing so will render the
      protocol insecure against active attacks (but may be desirable for
      practical reasons in the short term in many environments).  C then
      computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S
      || e || f || K), and verifies the signature s on H.

   Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be
   sent or accepted by either side.  If this condition is violated, the
   key exchange fails.

   This is implemented with the following messages.  The hash algorithm
   for computing the exchange hash is defined by the method name, and is
   called HASH.  The public key algorithm for signing is negotiated with
   the SSH_MSG_KEXINIT messages.

   First, the client sends the following:

      byte      SSH_MSG_KEXDH_INIT
      mpint     e

   The server then responds with the following:

      byte      SSH_MSG_KEXDH_REPLY
      string    server public host key and certificates (K_S)
      mpint     f
      string    signature of H
      string    V_C, the client's identification string (CR and LF
                excluded)
      string    V_S, the server's identification string (CR and LF
                excluded)
      string    I_C, the payload of the client's SSH_MSG_KEXINIT
      string    I_S, the payload of the server's SSH_MSG_KEXINIT
      string    K_S, the host key
      mpint     e, exchange value sent by the client
      mpint     f, exchange value sent by the server
      mpint     K, the shared secret

   This value is called the exchange hash, and it is used to
   authenticate the key exchange.  The exchange hash SHOULD be kept
   secret.

   The signature algorithm MUST be applied over H, not the original
   data.  Most signature algorithms include hashing and additional
   padding (e.g., "ssh-dss" specifies SHA-1 hashing).  In that case, the
   data is first hashed with HASH to compute H, and H is then hashed
   with SHA-1 as part of the signing operation.
-----

So without the knowledge of either 'x' or 'y' Eve will not get the
shared secret and will be excluded from the encrypted communications.
Surely there is an Eve's option to solve the discrete logarithm problem
for 'e' or 'f', but it is not so easy ;)) The only meaningful way for
ordinary attacker to be the real MITM is to establish two SSH channels:
Alice<->Eve, Eve<->Bob and proxy them.
-- 
Eygene

Reply via email to