Subject: Pulling it all together - New Section 11 on Security Considerations

From: Chris Lonvick <[email-masked]>
Date: Wed, 21 May 2003 12:36:49 -0700 (PDT)

Hi Folks,

Below is the latest version of the Security Considerations section.  This
reflects all of the discussions on the lists on the various parts of this
over the past few weeks.  I appreciate all of the feedback and help.

I've also put together an html document of the changes from the previous
version; red strike outs for deletions and green text for insertions.
I'll put it on a web server and send around a pointer rsn.  [The server
isn't doing so well today but I think it will be fixed in the next day
or so.]  If you'd like to see that sooner rather than later, please email
me directly and I'll send it to you.

If you would like to suggest any changes, please call out the relevent
section in the Subject line of your email.  Also, please remove the
non-related sections from your reply as this thing is getting a bit long.

Thanks,
Chris

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

11. Security Considerations

   In order to make the entire body of Security Considerations more
   accessible, Security Considerations for the transport, authentication,
   and connection documents have been gathered here.

   The transport protocol [SSH-TRANS] provides a confidential channel
   over an insecure network.  It performs server host authentication, key
   exchange, encryption, and integrity protection.  It also derives a
   unique session id that may be used by higher-level protocols.

   The authentication protocol [SSH-USERAUTH] provides a suite of
   mechanisms which can be used to authenticatethe client user to the
   server.  Individual mechanisms specified in the in authentication
   protocol use the session id provided by the transport protocol and/or
   depend on the security and integrity guarantees of the transport
   protocol.

   The connection protocol [SSH-CONNECT] specifies a mechanism to
   multiplex multiple streams (channels) of data over the confidential
   and authenticated transport. It also specifies channels for accessing
   an interactive shell, for 'proxy-forwarding' various external
   protocols over the secure transport (including arbitrary TCP/IP
   protocols), and for accessing secure 'subsystems' on the server host.

11.1 PRNG

   This protocol binds each session key to the session by including
   random, session specific data in the hash used to produce session
   keys.  Special care should be taken to ensure that all of the random
   numbers are of good quality.  If the random data here (e.g., DH
   parameters) are pseudo-random then the pseudo-random number generator
   should be cryptographically secure (i.e., its next output not easily
   guessed even when knowing all previous outputs) and, furthermore,
   proper entropy needs to be added to the pseudo-random number
   generator.  RFC 1750 [RFC1750] offers suggestions for sources of
   random numbers and entropy.  Implementors should note the importance
   of entropy and the well-meant, anecdotal warning about the difficulty
   in properly implementing pseudo-random number generating functions.

   The amount of entropy available to a given client or server may
   sometimes be less than what is required.  In this case one must either
   resort to pseudo-random number generation regardless of insufficient
   entropy or refuse to run the protocol.  The latter is preferable.

11.2 Transport

11.2.1 Confidentiality

   It is beyond the scope of this document and the Secure Shell Working
   Group to analyze or recommend specific ciphers other than the ones
   which have been established and accepted within the industry.  At the
   time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
   twofish, serpent and blowfish.  AES has been accepted by The US Federal
   Information Processing Standards [FIPS-197] and the cryptographic
   community as being acceptable for this purpose as well.  As always,
   implementors and users should check current literature to ensure that
   no recent vulnerabilities have been found in ciphers used within
   products.  Implementors should also check to see which ciphers are
   considered to be relatively stronger than others and should recommend
   their use to users over relatively weaker ciphers.  It would be
   considered good form for an implementation to politely and
   unobtrusively notify a user that a stronger cipher is available and
   should be used when a weaker one is actively chosen.

   The "none" cipher is provided for debugging and SHOULD NOT be used
   except for that purpose.  It's cryptographic properties are
   sufficiently described in RFC 2410 [RFC2410], which will show that its
   use does not meet the intent of this protocol.

   The relative merits of these and other ciphers may also be found in
   current literature.  Two references that may provide information on the
   subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER].  Both of these
   describe the CBC mode of operation of certain ciphers and the weakness
   of this scheme.  Essentially, this mode is theoretically vulnerable to
   chosen cipher-text attacks because of the high predictability of the
   start of packet sequence.  However, this attack is still deemed
   difficult and not considered fully practicable especially if relatively
   longer block sizes are used.

   Additionally, another CBC mode attack may be mitigated through the
   insertion of packets containing SSH_MSG_IGNORE.  Without this
   technique, a specific attack may be successful.  For this attack
   (commonly known as the Rogaway attack) to work, the attacker would
   need to know the IV of the next block that is going to be encrypted.
   In CBC mode that is the output of the encryption of the previous
   block. If the attacker does not have any way to see the packet yet
   (i.e it is in the internal buffers of the ssh implementation or even
   in the kernel) then this attack will not work. If the last packet has
   been sent out to the network (i.e the attacker has access to it) then
   he can use the attack.

   In the optimal case an implementor would need to add an extra packet
   only if the packet has been sent out onto the network and there are no
   other packets waiting for transmission. Implementors may wish to check
   to see if there are any unsent packets awaiting transmission, but
   unfortunately it is not normally easy to obtain this information from
   the kernel or buffers.  If there are not, then a packet containing
   SSH_MSG_IGNORE SHOULD be sent.  If a new packet is added to the stream
   every time the attacker knows the IV that is supposed to be used for
   the next packet, then the attacker will not be able to guess the
   correct IV, thus the attack will never be successfull.

   As an example, consider the following case:

      Client                                                  Server
      ------                                                  ------
      TCP(seq=x, len=500)            ->
         contains Record 1

                          [500 ms passes, no ACK]

      TCP(seq=x, len=1000)           ->
         contains Records 1,2

                                     <-                        ACK

      (1) The Nagle algorithm + TCP retransmits mean that the two
          records get coalesced into a single TCP segment
      (2) Record 2 is *not* at the beginning of the TCP segment
          and never will be, since it gets ACKed.
      (3) Yet, the attack is possible because Record 1 has already
          been seen.

   As this example indicates, it's totally unsafe to use the existence
   of unflushed data in the TCP buffers proper as a guide to whether
   you need an empty packet, since when you do the second write(),
   the buffers will contain the un-ACKed Record 1.

   On the other hand, it's perfectly safe to have the following
   situation:

      Client                                                  Server
      ------                                                  ------
      TCP(seq=x, len=500)           ->
         contains SSH_MSG_IGNORE

      TCP(seq=y, len=500)           ->
         contains Data

   Provided that the IV for second SSH Record is fixed after the data for
   the Data packet is determined -i.e. you do:
        read from user
        encrypt null packet
        encrypt data packet

11.2.2 Data Integrity

   This protocol does allow the Data Integrity mechanism to be disabled.
   Implementors SHOULD be wary of exposing this feature for any purpose
   other than debugging.  Users and administrators SHOULD be explicitly
   warned anytime the "none" MAC is enabled.

   So long as the "none" MAC is not used, this protocol
   provides data integrity.

   Because MACs use a 32 bit sequence number, they might start to leak
   information after 2**32 packets have been sent.  However, following
   the rekeying recommendations should prevent this attack.  The
   transport protocol [1] recommends rekeying after one gigabyte of data,
   and the smallest possible packet is 16 bytes. Therefore, rekeying
   SHOULD happen after 2**28 packets at the very most.

11.2.3 Replay

   The use of a MAC other than 'none' provides integrity and
   authentication.  In addition, the transport protocol provides a unique
   session identifier (bound in part to pseudo-random data that is part
   of the algorithm and key exchange process) that can be used by higher
   level protocols to bind data to a given session and prevent replay of
   data from prior sessions. For example, the authentication protocol uses
   this to prevent replay of signatures from previous sessions.  Because
   public key authentication exchanges are cryptographically bound to the
   session (i.e., to the initial key exchange) they cannot be successfully
   replayed in other sessions.  Note that the session ID can be made
   public without harming the security of the protocol.

   If two session happen to have the same session ID [hash of key
   exchanges] then packets from one can be replayed against the other.
   It must be stressed that the chances of such an occurrence are,
   needless to say, minimal when using modern cryptographic methods.
   This is all the more so true when specifying larger hash function
   outputs and DH parameters.

   Replay detection using monotonically increasing sequence numbers as
   input to the MAC, or HMAC in some cases, is described in RFC 2085
   [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964],
   RFC 2025 [RFC2025], and RFC 1510 [RFC1510].  The underlying construct
   is discussed in RFC 2104 [RFC2104].  Essentially a different sequence
   number in each packet ensures that at least this one input to the MAC
   function will be unique and will provide a nonrecurring MAC output
   that is not predictable to an attacker.  If the session stays active
   long enough, however, this sequence number will wrap.  This event may
   provide an attacker an opportunity to replay a previously recorded
   packet with an identical sequence number but only if the peers have
   not rekeyed since the transmission of the first packet with that
   sequence number.  If the peers have rekeyed, then the replay will be
   detected as the MAC check will fail.  For this reason, it must be
   emphasized that peers MUST rekey before a wrap of the sequence
   numbers.  Naturally, if an attacker does attempt to replay a captured
   packet before the peers have rekeyed, then the receiver of the
   duplicate packet will not be able to validate the MAC and it will be
   discarded.  The reason that the MAC will fail is because the receiver
   will formulate a MAC based upon the packet contents, the shared
   secret, and the expected sequence number.  Since the replayed packet
   will not be using that expected sequence number (the sequence number
   of the replayed packet will have already been passed by the receiver)
   then the calculated MAC will not match the MAC received with the
   packet.

11.2.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 two 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 [SSH-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.

   Insecure distribution of server public keys allows a second type of
   man-in-the-middle attack that should also be considered in this case;
   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.  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.

   As a second 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.

11.2.5 Denial-of-service

   This protocol is designed to be used over a reliable transport.  If
   transmission errors or message manipulation occur, the connection is
   closed.  The connection SHOULD be re-established if this occurs.
   Denial of service attacks of this type ("wire cutter") are almost
   impossible to avoid.

   In addition, this protocol is vulnerable to Denial of Service
   attacks because an attacker can force the server to go through
   the CPU and memory intensive tasks of connection setup and
   key exchange without authenticating.  Implementors SHOULD provide
   features that make this more difficult.  For example, only allowing
   connections from a subset of IPs known to have valid users.

11.2.6 Covert Channels

   The protocol was not designed to eliminate covert channels.  For
   example, the padding, SSH_MSG_IGNORE messages, and several other
   places in the protocol can be used to pass covert information, and
   the recipient has no reliable way to verify whether such information
   is being sent.

11.2.7  Forward Secrecy

   It should be noted that the Diffie-Hellman key exchanges may provide
   perfect forward secrecy (PFS).  PFS is essentially defined as the
   cryptographic property of a key-establishment protocol in which the
   compromise of a session key or long-term private key after a given
   session does not cause the compromise of any earlier session.
   [ANSI T1.523-2001]  SSHv2 sessions resulting from a key exchange using
   diffie-hellman-group1-sha1 are secure even if private
   keying/authentication material is later revealed, but not if the
   session keys are revealed. So, given this definition of PFS, SSHv2
   does have PFS.  It is hoped that all other key exchange mechanisms
   proposed and used in the future will also provide PFS.  This property
   is not commuted to any of the applications or protocols using SSH as a
   transport however.  The transport layer of SSH provides
   confidentiality for password authentication and other methods that
   rely on secret data.

   Of course, if the DH private parameters for the client and server are
   revealed then the session key is revealed, but these items can be
   thrown away after the key exchange completes.  It's worth pointing out
   that these items should not be allowed to end up on swap space and
   that they should be erased from memory as soon as the key exchange
   completes.

11.3 Authentication Protocol

   The purpose of this protocol is to perform client user authentication.
   It assumes that this run over a secure transport layer protocol, which
   has already authenticated the server machine, established an encrypted
   communications channel, and computed a unique session identifier for
   this session.

   Several authentication methods with different security characteristics
   are allowed.  It is up to the server's local policy to decide which
   methods (or combinations of methods) it is willing to accept for each
   user.  Authentication is no stronger than the weakest combination
   allowed.

   The server may go into a "sleep" period after repeated unsuccessful
   authentication attempts to make key search more difficult for
   attackers.  Care should be taken so that this doesn't become a
   self-denial of service vector.

11.3.1 Weak Transport

   If the transport layer does not provide confidentiality,
   authentication methods that rely on secret data SHOULD be disabled.
   If it does not provide strong integrity protection, requests to change
   authentication data (e.g. a password change) SHOULD be disabled to
   prevent an attacker from  modifying the ciphertext without being
   noticed, or rendering the new authentication data unusable (denial
   of service).

   The assumption as stated above that the Authentication Protocol only
   run over a secure transport that has previously authenticated the
   server is very important to note.  People deploying SSH are reminded
   of the consequences of man-in-the-middle attacks if the client does
   not have a very strong a priori association of the server with the
   host key of that server.  Specifically for the case of the
   Authentication Protocol the client may form a session to a
   man-in-the-middle attack device and divulge user credentials such as
   their username and password.  Even in the cases of authentication
   where no user credentials are divulged, an attacker may still gain
   information they shouldn't have by capturing key-strokes in much the
   same way that a honeypot works.

11.3.2 Debug messages

   Special care should be taken when designing debug messages.  These
   messages may reveal surprising amounts of information about the host
   if not properly designed.  Debug messages can be disabled (during
   user authentication phase) if high security is required.

11.3.3 Local security policy

   Implementer MUST ensure that the credentials provided validate the
   professed user and also MUST ensure that the local policy of the
   server permits the user the access requested.  In particular,
   because of the flexible nature of the SSH connection protocol, it may
   not be possible to determine the local security policy, if any, that
   should apply at the time of authentication because the kind of service
   being requested is not clear at that instant. For example, local
   policy might allow a user to access files on the server, but not start
   an interactive shell. However, during the authentication protocol, it
   is not known whether the user will be accessing files or attempting to
   use an interactive shell, or even both.  In any event, where local
   security policy for the server host exists, it MUST be applied and
   enforced correctly.

   Implementors are encouraged to provide a default local policy and
   make its parameters known to administrators and users.  At the
   discretion of the implementors, this default policy may be along the
   lines of 'anything goes' where there are no restrictions placed upon
   users, or it may be along the lines of 'excessively restrictive' in
   which case the administrators will have to actively make changes to
   this policy to meet their needs.  Alternatively, it may be some
   attempt at providing something practical and immediately useful to the
   administrators of the system so they don't have to put in much effort
   to get SSH working.  Whatever choice is made MUST be applied and
   enforced as required above.

11.3.4 Public key authentication

   The use of public-key authentication assumes that the client host has
   not been compromised.

   This risk can be mitigated by the use of passphrases on private keys;
   however, this is not an enforceable policy.  The use of smartcards, or
   other technology to make passphrases an enforceable policy is
   suggested.

   The server could require both password and public-key authentication,
   however, this requires the client to expose its password to the server
   (see section on password authentication below.)

11.3.5 Password authentication

   The password mechanism as specified in the authentication protocol
   assumes that the server has not been compromised.  If the server has
   been compromised, using password authentication will reveal a valid
   username / password combination to the attacker, which may lead to
   further compromises.

   This vulnerability can be mitigated by using an alternative form of
   authentication.  For example, public-key authentication makes no
   assumptions about security on the server.

11.3.6 Host based authentication

   Host based authentication assumes that the client has not been
   compromised.  There are no mitigating strategies, other than to use
   host based authentication in combination with another authentication
   method.

11.4 Connection protocol

11.4.1 End point security

   End point security is assumed by the connection protocol.  If the
   server has been compromised, any terminal sessions, port forwarding,
   or systems accessed on the host are compromised.  There are no
   mitigating factors for this.

   If the client end point has been compromised, and the server fails to
   stop the attacker at the authentication protocol, all services exposed
   (either as subsystems or through forwarding) will be vulnerable to
   attack.  Implementors SHOULD provide mechanisms for administrators to
   control which services are exposed to limit the vulnerability of other
   services.

   These controls might include controlling which machines and ports can
   be target in 'port-forwarding' operations, which users are allowed to
   use interactive shell facilities, or which users are allowed to use
   exposed subsystems.

11.4.2 Proxy forwarding

   The SSH connection protocol allows for proxy forwarding of other
   protocols such as SNMP, POP3, and HTTP.  This may be a concern for
   network administrators who wish to control the access of certain
   applications by users located outside of their physical location.
   Essentially, the forwarding of these protocols may violate site
   specific security policies as they may be undetectably tunneled
   through a firewall.  Implementors SHOULD provide an administrative
   mechanism to control the proxy forwarding functionality so that
   site specific security policies may be upheld.

   In addition, a reverse proxy forwarding functionality
   is available, which again can be used to bypass firewall
   controls.

   As indicated above, end-point security is assumed during
   proxy forwarding operations.  Failure of end-point security
   will compromise all data passed over proxy forwarding.

11.4.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh connection
   protocol is the forwarding of the X11 protocol.  If end-point security
   has been compromised, X11 forwarding may allow attacks against the X11
   server.  Users and administrators should, as a matter of course, use
   appropriate X11 security mechanisms to prevent unauthorized use of the
   X11 server.  Implementors, administrators and users who wish to
   further explore the security mechanisms of X11 are invited to read
   [SCHEIFLER] and analyze previously reported problems with the
   interactions between SSH forwarding and X11 in CERT vulnerabilities
   VU#363181 and VU#118892 [CERT].

   X11 display forwarding with SSH, by itself, is not sufficient to
   correct well known problems with X11 security [VENEMA].  However, X11
   display forwarding in SSHv2 (or other, secure protocols), combined
   with actual and pseudo-displays which accept connections only over
   local IPC mechanisms authorized by permissions or ACLs, does correct
   many X11 security problems as long as the "none" MAC is not used.  It
   is RECOMMENDED that X11 display implementations default to allowing
   display opens only over local IPC.  It is RECOMMENDED that SSHv2
   server implementations that support X11 forwarding default to allowing
   display opens only over local IPC.  On single-user systems it might be
   reasonable to default to allowing local display opens over TCP/IP.

   Implementors of the X11 forwarding protocol SHOULD implement the magic
   cookie access checking spoofing mechanism as described in [ssh-connect]
   as an additional mechanism to prevent unauthorized use of the proxy.

References from this section:

[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
          Service (V5)", RFC 1510, September 1993.

[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
           RFC 1964, June 1996.

[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
          Recommendations for Security", RFC 1750, December 1994.

[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
          (SPKM)", RFC 2025, October 1996.

[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay
          Prevention", RFC 2085, February 1997.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
          Keyed-Hashing for Message Authentication", RFC 2104,
          February 1997.

[RFC2246] Diercks, T. and  C. Allen, "The TLS Protocol Version
          1.0", RFC 2246, January 1999.

[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
          Use With IPsec", RFC 2410, November 1998

[RFC2743] Linn, J., "Generic Security Service Application Program
          Interface Version 2, Update 1", RFC 2743, January 2000.

[SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
          and Sons Publisher, 1996

[KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
          a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner,
          Prentice Hall Publisher, 1995

[FIPS-197]  National Institute of Standards and Technology,
            "Specification for the Advanced Encryption Standard (AES)"
            FIPS 197.  November 26, 2001.

[ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
          Glossary 2000", American National Standards Institute, Inc.,
          Approved February 28, 2001.

[SCHEIFLER]  Scheifler, R., "X Window System : The Complete
          Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
          edition.", Digital Press ISBN 1555580882, Feburary
          1992.

[CERT]    The CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh, PA 15213-3890
          U.S.A.
          ( http://www.cert.org/nav/index_red.html )

[VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings
         of 6th USENIX Security Symposium, San Jose, CA, July 1996.
http://www.usenix.org/publications/library/proceedings/sec96/venema.html

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 21 May 2003 14:07:40 -0700 (PDT)

Hi,

As promised:

  http://www.employees.org/~lonvick/newssh7.html

Thanks,
Chris

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 28 May 2003 08:36:08 -0700

I like it.  But I've one nit about the MITM section: it speaks of two
MITM possibilities, describes a "first" case and *two* "second" cases!

Cheers,

Nico

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 28 May 2003 09:16:22 -0700 (PDT)

Hi Nico,

I agree it's awkward.  It was suppsed to be two "types" within the "first
case".  For those that may not have yet gotten to that section, the first
case is an active mitm with the first type being on the first connection
attempt when the client has not previously seen the key of the host, and
the second type just noting the subversion of the distribution of the host
keys prior to the first connection attempt.

I'll rework it to make it clear and get that back out.

I appreciate the review.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 28 May 2003 10:50:38 -0700 (PDT)

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

   There are three cases of man-in-the-middle attacks to consider.  The
   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

   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

---

From: "Richard Wanner" <[email-masked]>
Date: Wed, 28 May 2003 14:09:36 -0400

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: [email-masked]
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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Chris Lonvick
> Sent: Wednesday, May 28, 2003 1:51 PM
> To: [email-masked]
> Subject: New Section 11.2.4 Man-in-the-middle
>
>
> Hi,
>