RE: New Section 11.2.4 Man-in-the-middle

["Richard Wanner" <richard.wanner%cgi.com@localhost>]

Looks great to me!  One minor nit (which you may choose to ignore);  I would
probably switch the order of case 1 and case 2 just because case 2 is the
most likely, and most preventable attack.

Case 1: No keys distributed.
Case 2: Keys distributed, but attack possible due to user intervention.
Case 3: More high-tech attack.

The attacks get more complex as they go.  And the cases follow from each
other.

My opinion.  YMMV



Richard (Rick) Wanner B.Sc. GCFW
Consultant
Security Engineering & Evaluation Group
InfoSec Centre of Expertise (COE)
CGI Information Systems & Management Consultants Inc.
Ottawa, Canada

http://www.infosec.cgi.com/

Email: richard.wanner%cgi.com@localhost
Tel:    (613) 234-2155
Cell:    (613) 220-2045
Fax:    (613) 234-6934
Confidentiality Notice: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.



> -----Original Message-----
> From: ietf-ssh-owner%netbsd.org@localhost [mailto:ietf-ssh-owner%netbsd.org@localhost]On
> Behalf Of Chris Lonvick
> Sent: Wednesday, May 28, 2003 1:51 PM
> To: ietf-ssh%netbsd.org@localhost
> Subject: New Section 11.2.4 Man-in-the-middle
>
>
> 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.
>
>
>
>
>