New Proposal for Section 11.1.4 Man-in-the-middle

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

The section on MITM for your review.

Thanks,
Chris

========================================================================

11.1.4 Man-in-the-middle

   This protocol makes no assumptions nor provisions for an
   infrastructure for distributing public keys.  It is expected that this
   protocol will sometimes be used without insisting on reliable
   association between the server host key and the server host name.
   Such usage is vulnerable to man-in-the-middle attacks.

   This vulnerability to man-in-the-middle attacks can be mitigated in
   several fashions:

   1. Narrow the window during which the client is vulnerable to such a
      man-in-the-middle attack.  If the client ensures that the host key
      for a given server remains consistant, an attacker must execute the
      man-in-the-middle attack on the _first_ connection to a given
      server.

   2. Use an authentication method that is not vulnerable to
      man-in-the-middle attacks.  For example, public-key authentication
      is not vulnerable to man-in-the-middle attack as long as the
      public-key of the server has been securely distributed to the
      clients before the first SSH connection is made.  This is because
      the signature is made across data that is session specific.  The
      session specific data between the attacker and server will be
      different between the client-to-attacker session and the
      attacker-to-server sessions due to the randomness discussed above.
      From this, the attacker will not be able to make this attack work
      since the attacker will not be able to correctly sign packets
      containing this session specific data from the server since he does
      not have the private key of that server.

   3. Because the protocol is extensible, future extensions to the
      protocol may provide better mechanisms for dealing with the need to
      know the server's host key before connecting.  For example, storing
      the hostkey fingerprint in a secure dns database, or using kerberos
      over gssapi during keyexchange to authenticate the server.

   Insecure distribution of server public keys allows a different sort of
   man-in-the-middle: one with suitable but incorrect host keys.  If the
   server public keys are not securely distributed then the client cannot
   know if it is talking to the intended server.  Server administrators
   are encouraged to make host key fingerprints available for checking by
   some means whose security does not rely on the integrity of the actual
   host keys.  Possible mechanisms include secured Web pages, the DNS
   [draft-ietf-secsh-dns], physical pieces of paper, etc.  Implementors
   SHOULD provide recommendations on how best to do this with their
   implementation.

   Use of this protocol without a reliable association of the binding
   between a host and its host keys is inherently insecure and is NOT
   RECOMMENDED.  It may however be necessary in non-security critical
   environments, and will still provide protection against passive
   attacks.  Implementors of protocols and applications running on top of
   this protocol should keep this possibility in mind.

   Attackers may attempt to manipulate packets in transit between peers.
   As described in the Replay part of this section, a successful attack
   of this nature is very improbable.  As in the Replay section, this
   reasoning does assume that the MAC is secure and that it is infeasible
   to construct inputs to a MAC algorithm to give a known output.  This
   is discussed in much greater detail in Section 6 of RFC 2104.  If the
   MAC algorithm has a vulnerability or is weak enough, then the attacker
   may be able to specify certain inputs to yeild a known MAC.  With that
   they may be able to alter the contents of a packet in transit.
   Alternatively the attacker may be able to exploit the algorithm
   vulnerability or weakness to find the shared secret by reviewing
   the MACs from captured packets.  With either of those cases, an
   attacker could construct a packet that could be inserted into an SSH
   stream.  To prevent that, implementors are encouraged to utilize
   commonly accepted MAC algorithms and administrators are encouraged to
   watch current literature and discussions of cryptography to ensure
   that they are not using a MAC algorithm that has a recently found
   vulnerability or weakness.

---Notes---[Chris: These notes revolve around (2) above.]

[RJA:  Is this really true and sufficient ?

--Joseph--vv
Public key authentication is not vulnerable regardless
of whether the server's public key has been securely
distrubuted.

   ---Nico---vv
   Insecure distribution of server public keys allows a different sort of
   MITM: one with suitable host keys.  If the server public keys are not
   securely distributed then the client cannot know if it is talking to a
   legitimate server.

   > Client --> MITM server / MITM client --> Server
   >
   > Client uses robust cryptographic PRNG, and
   > correct implemenations, forcing the Session
   > Identifier for the Client --> MITM Server
   > to be unpredicatable.

   This applies only to a MITM who does not posses host keys.  Obiously,
   any MITM can generate host keys.  The questions is: can a MITM fool a
   client into thinking that it (the MITM) is the server that the client
   intended to connect to.
   ---Nico---^^

Client --> MITM server / MITM client --> Server

Client uses robust cryptographic PRNG, and
correct implemenations, forcing the Session
Identifier for the Client --> MITM Server
to be unpredicatable.

Server also uses robust cryptographic PRNG,
and correct implementations, forcing the Session
Identifier for the MITM Client --> Server Session
to be unpredictable, and most importantly,
different from that of Client --> MITM Server.

   ---Ran---vv
   Seems to me that we ought to note the criticality
   of the quality of the PRNG implementation in the
   Security Considerations section of the document.
   ---Ran---^^


Now, client uses its private key to sign the
Client -> MITM Server session id, and sends
that signature as authentication data.

Becasuse MITM Client can't use the signature it
just received (MITM client --> Server has a different
Session Id to be signed), and it doesn't have access to
the private key, it cannot proceed forward with authentication.

---

Now, of course MITM Client can simply defer completing
authentication with Server, and wait for client to
request Agent forwarding.  Then, using agent, obtain
the signature it needs to complete the authentication
with Server, and quickly bring MITM client --> Server
state up to date with Client --> MITM Server state.

Maybe the whole argument isn't worth including.
--Joseph--^^

   ---Ran---vv
   I'd go with that last sentence, particularly since the robustness
   of the PRNG is very implementation-specific.  It is hard
   to get PRNGs correct in actual code, so it is not unlikely
   that one or more SSH implementations would not get it right.
   ---Ran---^^

   ---Heikki---vv
   I second that.
   ---Heikki---^^

---Heikki---vv
In my opinion, this belongs into the agent spec, not here. [Don't do
agent forwarding for the servers you don't trust.]
---Heikki---^^

   ---Ran---vv
   That would be OK with me.
   ---Ran---^^