Re: IESG feedback on core drafts.

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

All right; here is version two, to be added to 
the architecture draft.

I'd appreciate feedback.

- Joseph

-----
Here is my proposed revision:

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 secure encrypted
   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.  Individual mechanisms specified in the in
   authentication protocol use teh session id provided
   by the transport protocol and/or depend on the security
   and integrity gaurentees of the transport protocol.

   The connection protocol [3] specifies a mechanism
   to multiplex multiple streams [channels] of data over
   the secure 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 

   This protocol does allow the encryption 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" method is enabled.
   
   So long as the "none" cipher is not used, this protocol
   provides confidentiality.  Older, smaller ciphers, such
   as 3des and arcfour MAY be less secure from attack than
   ciphers such as AES.  Implementors SHOULD prefer ciphers
   such as twofish, serpent, or AES over blowfish, 3des and
   arcfour.

   With ciphers operating in CBC mode is theoretically
   vulnerable to choosen cipher-text attacks because of
   the high predicability of the start of packet sequence.
   However, this attack is still relatively hard enough, and
   requires a sufficiently high number of packets, to be safe
   in the short term.  Ciphers with larger block sizes are
   less vulnerable the ciphers with smaller block sizes.
   [Is this true?]

   Effort is underway to standardize the use of CTR mode
   ciphers in the SSH protocol.  When this work is completed,
   implementors SHOULD support it.
   
   In addition, the CBC mode attack can be mitigated by
   ensuring the an SSH_MSG_IGNORE packet preceeds any real
   data at the start of a TCP packet.
   [Is this true?  26 of the 32 length bits can probably
   be reliably guessed to be 0.  One or two of the pad
   length bits are likewise reliably guessed as 0.  The
   packet type is known.  26 of the length field of the
   string in an ignore packet are known. So 26 + 2 + 8 + 16 = 
   52 of the first 64 bits are reliablely known (or 62 of
   the first 128 bits) -- my understanding is hazy-- is
   this applicable to the vulnerability?]

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 may
   start to leak information after 2**32 packets have
   been sent.  However, following the rekeying
   recomendations 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.

   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.

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.

   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.

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

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.

   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 encryption, 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

   Authentication is always a delicate security operation.
   Implementor MUST not only ensure that the credentials
   given validate the professed user, but also that the
   local policy of the server hosts allows 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.

   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 enforcable
   policy.  The use of smartcards, or other technology
   to make passphrases an enforcable 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
   comprimises.

   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 mitaging
   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 comprimised.
   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 proxy forwarding
   of other protocols.  The proxy forwarding functionality
   can be used to circumvent firewall protections.  Implementors
   SHOULD provide a mechanism to disable to administratively
   control the proxy forwarding funcitonality.

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

   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 administors should, as a matter of course, use
   X11 security mechanism to prevent unauthorized use of
   the X11 server.