New Section 11.2.4 Man-in-the-middle

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

Hi,

(Meetings are great places to get work done. :-)

I've made some modifications to the MITM section to separate the attacks
into 3 cases (rather than subsets of 2):
- getting incorrect host keys during the first session attempt
- noting the case where an attacker may usurp secure key distribution
- attempts at modifying packets after the session has been established

Please review this and provide feedback.  The "diffs" are at
  http://www.employees.org/~lonvick/newssh9.html

Thanks,
Chris


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

11.1.4 Man-in-the-middle

   This protocol makes no assumptions nor provisions for an
   infrastructure or means for distributing the public keys of hosts.  It
   is expected that this protocol will sometimes be used without first
   verifying the association between the server host key and the server
   host name.  Such usage is vulnerable to man-in-the-middle attacks.
   This section describes this and encourages administrators and users to
   understand the importance of verifying this association before any
   session is initiated.

   There are three cases of man-in-the-middle attacks to consider.  The
   first is where an attacker places a device between the client and the
   server before the session is initiated.  In this case, the attack
   device is trying to mimic the legitimate server and will offer its
   public key to the client when the client initiates a session.  If it
   were to offer the public key of the server, then it would not be able
   to decrypt or sign the transmissions between the legitimate server and
   the client unless it also had access to the private-key of the host.
   The attack device will also, simultaneously to this, initiate a
   session to the legitimate server masquerading itself as the client.
   If the public key of the server had been securely distributed to the
   client prior to that session initiation, the key offered to the client
   by the attack device will not match the key stored on the client.  In
   that case, the user SHOULD be given a warning that the offered host
   key does not match the host key cached on the client.  As described in
   Section 3.1 of [ARCH], the user may be free to accept the new key and
   continue the session.  It is RECOMMENDED that the warning provide
   sufficient information to the user of the client device so they may
   make an informed decision.  If the user chooses to continue the
   session with the stored public-key of the server (not the public-key
   offered at the start of the session), then 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.

   The second case that should be considered is similar to the first case
   in that it also happens at the time of connection but this case points
   out the need for the secure distribution of server public keys.  If the
   server public keys are not securely distributed then the client cannot
   know if it is talking to the intended server.  An attacker may use
   social engineering techniques to pass off server keys to unsuspecting
   users and may then place a man-in-the-middle attack device between the
   legitimate server and the clients.  If this is allowed to happen then
   the clients will form client-to-attacker sessions and the attacker
   will form attacker-to-server sessions and will be able to monitor and
   manipulate all of the traffic between the clients and the legitimate
   servers.  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 are discussed in Section 3.1 of [SSH-ARCH] and may also
   include secured Web pages, physical pieces of paper, etc.
   Implementors SHOULD provide recommendations on how best to do this
   with their implementation.  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, making the host key fingerprint available through a secure
   DNS lookup, or using kerberos over gssapi during key exchange to
   authenticate the server are possibilities.

   In the third man-in-the-middle case, attackers may attempt to
   manipulate packets in transit between peers after the session has been
   established.  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 yield 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.  In either of those cases,
   an attacker could construct a packet or packets 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.

   In summary, the 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.