Newer Rev of Section 11 - was: Re: IESG feedback on core drafts.

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

Hi,

I've tried to revise Section 11 per all of the comments and came up with
the following.  There are some questions asked by Ran that still need to
be addressed which are noted.

I've corrected some typo's and will gladly pass this back to Joseph.  :-)

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 [1] 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 [2] provides a suite of mechanism which
   can be used to authenticating the 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 [3] 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 Transport


11.1.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, which will show that its use does
   not meet the intent of this protocol.

[Chris:  While it may be obvious to everyone on this list that "none"
[Chris:  should not be used, it may not be obvious to all readers.  I'd
[Chris:  like to keep this in for completeness.

   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.1.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.1.3 Replay

   This protocol binds each session key to the session
   by including random data that is specific to the
   session in the hash used to produce session keys.

[RJA:  Is it random or pseudo-random ?
[RJA:  Does the difference matter in this case ?

   This session id is used by higher level protocols
   to prevent replay of packets form previous sessions.

   In addition, the use of cipher chaining prevents
   replay of packets within the session.  Cipher chaining
   also prevents the insertion or deletion of packets.

[RJA:  Citations would be pleasant for these claims.

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.  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.

[RJA:  Narrow *which* window ?
[RJA:  Intended meaning is not crystal clear above.


   2. Use an authentication method that is not vulnerable
      to man-in-the-middle.  For example, public-key
      authentication is not vulnerable to man-in-the-middle
      attack, because the signature is made across data
      that is session specific.  The attack can not use
      the signature he receives because the session specific
      data between the attacker and server is different, and
      can not create a valid signature because he does not
      have the private key.

[RJA:  Is this really true and sufficient ?

   However, this does assume that the public-key has
   been distributed to the server host in some secure
   fashion before the first SSH connection can be made.

   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.

   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 reliable association

[RJA:  association of what/whom ?

   is inherently insecure, but may be necessary in
   non-security critical environments, and still
   provides protection against passive attacks.  However,
   implementors of protocols running on top of this
   protocol should keep this possibility in mind.

[RJA:  ???  s/protocols running/applications running/ ???

11.1.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.1.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 Authentication Protocol

   The purpose of this protocol is to perform client user
   authentication.  It assumed that this runs 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.  The transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

[RJA:  "perfect forward secrecy" or "forward secrecy" ?

   The server may go into a "sleep" period after repeated unsuccessful
   authentications to make key search harder.

   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.

11.2.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 MAC protection, requests to change authentication data (e.g.
   password change) SHOULD be disabled to avoid an attacker from
   modifying the ciphertext without being noticed, rendering the new
   authentication data unusable (denial of service).

11.2.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.2.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
   this completely at the time of authentication, because
   the kind of service being requested is not yet clear.

[RJA:  Unclear antecedent "this".

   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, local security policy for the server
   host MUST be applied and enforced correctly.

11.2.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.2.5 Password authentication

   The password mechanism of 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.2.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.3 Connection protocol

11.3.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.3.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.3.3 X11 forwarding

   Another form of proxy forwarding provided by the ssh
   connection protocol is the forwarding of the X11 protocol.

   Implementors of the X11 protocol SHOULD implement the
   magic cookie spoofing, to prevent unauthorized use of
   the proxy.

[RJA:  Add citation for "magic cookie spoofing".

   X11 forwarding relies on end-point security.  If end-point
   security has been compromised, X11 forwarding will allow
   any attack against the X11 server possible locally.

   Users and administrators should, as a matter of course, use
   X11 security mechanism to prevent unauthorized use of
   the X11 server.

[RJA:  Which "X11 security mechanism" is meant ?
[RJA:  Also, please add a citation for that mechanism.


References:

[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

===end===