Subject: Even Newer Section 11 for Your Comments

From: Chris Lonvick <[email-masked]>
Date: Wed, 16 Apr 2003 06:19:48 -0700 (PDT)

Hi Folks,

My thanks to everyone who's been discussing and making comments upon the
proposed Section 11.  Below is a revision based upon the recent email
thread.  Please look that over and provide your further comments.  To make
the task of looking at the revisions easier, I've attached a file with
some html in it.  (Your indulgences, please.)  When viewed in a browser it
displays redline striking to indicate deleted passages and green text to
indicate insertions.  It's not exact but it has markups at or near the
places that have changed which will hopefully allow everyone to review
these changes without having to hunt them down manually.

I've edited some significant changes into Section 11.1.3 "Replay" and have
added a new Section 11.1.7  "Forward Secrecy".  Please look those over
carefully.  I've also tried very hard to keep outstanding questions in
this which still need to be addressed.  These should be findable by
looking for "[xxx: " at the start of lines below.

One comment that was raised was about adding a new section on the security
of the key exchange.  I have not attempted to address that and it is not
noted below.  If that is needed in this section, would someone
(Joseph? :-) please propose text?

Thanks,
Chris

===vvv===  New Proposal for Section 11  ===vvv===

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.

   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.

[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

   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.  If the random data here (e.g., DH parameters)
   are pseudo-random then the PRNG should be cryptographically secure
   (i.e., its next output not easily guessed, even when knowing all
   previous outputs) and, furthermore, the PRNG should be seeded with some
   truly random inputs, or as random as can be available.  In any case,
   the amount of entropy available to a given client or server sometimes
   may be less than what is needed to run the protocol, in which case
   either one must resort to PRNGs anyways or refuse to run the protocol.
   In practice implementors will generally rely on some PRNG.  RFC 1750
   [1750] contains more discussion on this.

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

   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.

[RJA:  I imagine that a sequence number does help preclude replay attacks,
[RJA:  but I was hoping that someone else had actually done some analysis
[RJA:  that we could cite to justify the claim that this MAC combined with
[RJA:  this kind of sequence numbering would actually provide replay
[RJA:  attack prevention.

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.

[RJA:  Is this really true and sufficient ?

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

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

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 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 the local security
   policy that should apply at the time of authentication, because the
   kind of service being requested is not yet clear. 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.

[Nico:  What if no policy is available?

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.  More information
   about the use of the X11 magic cookie may be found in many of the
   available manual references and implementation guides for X11.  For
   example, viewing the manual page for "xauth" in BSD systems may be one
   place to start.

   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.

[JG:  Well, I didn't have a particular one in mind.  The
[JG:  advice is to use any X11 security mechanism.  I'd
[JG:  be willing to remove the paragraph.
[RJA:  I'd like to keep text encouraging folks to use as much
[RJA:  security as they can.  I'm not an expert on the security
[RJA:  properties of X11.  I was thinking that there probably were
[RJA:  some specific security mechanisms (e.g. my vague recollection
[RJA:  of the MIT-magic-cookie hack noted above) that we ought
[RJA:  to mention and cite.

===^^^===  New Proposal for Section 11  ===^^^===

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 28 Apr 2003 08:22:00 -0700 (PDT)

Hi Everyone,

My watchdog timer has gone off so I'm re-sending.  There are comments
below that SHOULD be addressed.  Please take the time to look them over
and comment upon them.

Thanks,
Chris