doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc4251.txt b/doc/rfc/rfc4251.txt
new file mode 100644
index 0000000..ffc33ea
--- /dev/null
+++ b/doc/rfc/rfc4251.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                          T. Ylonen
+Request for Comments: 4251              SSH Communications Security Corp
+Category: Standards Track                                C. Lonvick, Ed.
+                                                     Cisco Systems, Inc.
+                                                            January 2006
+
+
+              The Secure Shell (SSH) Protocol Architecture
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Secure Shell (SSH) Protocol is a protocol for secure remote login
+   and other secure network services over an insecure network.  This
+   document describes the architecture of the SSH protocol, as well as
+   the notation and terminology used in SSH protocol documents.  It also
+   discusses the SSH algorithm naming system that allows local
+   extensions.  The SSH protocol consists of three major components: The
+   Transport Layer Protocol provides server authentication,
+   confidentiality, and integrity with perfect forward secrecy.  The
+   User Authentication Protocol authenticates the client to the server.
+   The Connection Protocol multiplexes the encrypted tunnel into several
+   logical channels.  Details of these protocols are described in
+   separate documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 1]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Contributors ....................................................3
+   3. Conventions Used in This Document ...............................4
+   4. Architecture ....................................................4
+      4.1. Host Keys ..................................................4
+      4.2. Extensibility ..............................................6
+      4.3. Policy Issues ..............................................6
+      4.4. Security Properties ........................................7
+      4.5. Localization and Character Set Support .....................7
+   5. Data Type Representations Used in the SSH Protocols .............8
+   6. Algorithm and Method Naming ....................................10
+   7. Message Numbers ................................................11
+   8. IANA Considerations ............................................12
+   9. Security Considerations ........................................13
+      9.1. Pseudo-Random Number Generation ...........................13
+      9.2. Control Character Filtering ...............................14
+      9.3. Transport .................................................14
+           9.3.1. Confidentiality ....................................14
+           9.3.2. Data Integrity .....................................16
+           9.3.3. Replay .............................................16
+           9.3.4. Man-in-the-middle ..................................17
+           9.3.5. Denial of Service ..................................19
+           9.3.6. Covert Channels ....................................20
+           9.3.7. Forward Secrecy ....................................20
+           9.3.8. Ordering of Key Exchange Methods ...................20
+           9.3.9. Traffic Analysis ...................................21
+      9.4. Authentication Protocol ...................................21
+           9.4.1. Weak Transport .....................................21
+           9.4.2. Debug Messages .....................................22
+           9.4.3. Local Security Policy ..............................22
+           9.4.4. Public Key Authentication ..........................23
+           9.4.5. Password Authentication ............................23
+           9.4.6. Host-Based Authentication ..........................23
+      9.5. Connection Protocol .......................................24
+           9.5.1. End Point Security .................................24
+           9.5.2. Proxy Forwarding ...................................24
+           9.5.3. X11 Forwarding .....................................24
+   10. References ....................................................26
+      10.1. Normative References .....................................26
+      10.2. Informative References ...................................26
+   Authors' Addresses ................................................29
+   Trademark Notice ..................................................29
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 2]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+1.  Introduction
+
+   Secure Shell (SSH) is a protocol for secure remote login and other
+   secure network services over an insecure network.  It consists of
+   three major components:
+
+   o  The Transport Layer Protocol [SSH-TRANS] provides server
+      authentication, confidentiality, and integrity.  It may optionally
+      also provide compression.  The transport layer will typically be
+      run over a TCP/IP connection, but might also be used on top of any
+      other reliable data stream.
+
+   o  The User Authentication Protocol [SSH-USERAUTH] authenticates the
+      client-side user to the server.  It runs over the transport layer
+      protocol.
+
+   o  The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
+      tunnel into several logical channels.  It runs over the user
+      authentication protocol.
+
+   The client sends a service request once a secure transport layer
+   connection has been established.  A second service request is sent
+   after user authentication is complete.  This allows new protocols to
+   be defined and coexist with the protocols listed above.
+
+   The connection protocol provides channels that can be used for a wide
+   range of purposes.  Standard methods are provided for setting up
+   secure interactive shell sessions and for forwarding ("tunneling")
+   arbitrary TCP/IP ports and X11 connections.
+
+2.  Contributors
+
+   The major original contributors of this set of documents have been:
+   Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
+   Communications Security Corp), and Markku-Juhani O. Saarinen
+   (University of Jyvaskyla).  Darren Moffat was the original editor of
+   this set of documents and also made very substantial contributions.
+
+   Many people contributed to the development of this document over the
+   years.  People who should be acknowledged include Mats Andersson, Ben
+   Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller,
+   Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff
+   Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph
+   Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas
+   Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon
+   Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and
+   Tadayoshi Kohno.  Listing their names here does not mean that they
+   endorse this document, but that they have contributed to it.
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 3]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+3.  Conventions Used in This Document
+
+   All documents related to the SSH protocols shall use the keywords
+   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
+   requirements.  These keywords are to be interpreted as described in
+   [RFC2119].
+
+   The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
+   FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
+   APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
+   this document when used to describe namespace allocation are to be
+   interpreted as described in [RFC2434].
+
+   Protocol fields and possible values to fill them are defined in this
+   set of documents.  Protocol fields will be defined in the message
+   definitions.  As an example, SSH_MSG_CHANNEL_DATA is defined as
+   follows.
+
+      byte      SSH_MSG_CHANNEL_DATA
+      uint32    recipient channel
+      string    data
+
+   Throughout these documents, when the fields are referenced, they will
+   appear within single quotes.  When values to fill those fields are
+   referenced, they will appear within double quotes.  Using the above
+   example, possible values for 'data' are "foo" and "bar".
+
+4.  Architecture
+
+4.1.  Host Keys
+
+   Each server host SHOULD have a host key.  Hosts MAY have multiple
+   host keys using multiple different algorithms.  Multiple hosts MAY
+   share the same host key.  If a host has keys at all, it MUST have at
+   least one key that uses each REQUIRED public key algorithm (DSS
+   [FIPS-186-2]).
+
+   The server host key is used during key exchange to verify that the
+   client is really talking to the correct server.  For this to be
+   possible, the client must have a priori knowledge of the server's
+   public host key.
+
+   Two different trust models can be used:
+
+   o  The client has a local database that associates each host name (as
+      typed by the user) with the corresponding public host key.  This
+      method requires no centrally administered infrastructure, and no
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 4]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+      third-party coordination.  The downside is that the database of
+      name-to-key associations may become burdensome to maintain.
+
+   o  The host name-to-key association is certified by a trusted
+      certification authority (CA).  The client only knows the CA root
+      key, and can verify the validity of all host keys certified by
+      accepted CAs.
+
+   The second alternative eases the maintenance problem, since ideally
+   only a single CA key needs to be securely stored on the client.  On
+   the other hand, each host key must be appropriately certified by a
+   central authority before authorization is possible.  Also, a lot of
+   trust is placed on the central infrastructure.
+
+   The protocol provides the option that the server name - host key
+   association is not checked when connecting to the host for the first
+   time.  This allows communication without prior communication of host
+   keys or certification.  The connection still provides protection
+   against passive listening; however, it becomes vulnerable to active
+   man-in-the-middle attacks.  Implementations SHOULD NOT normally allow
+   such connections by default, as they pose a potential security
+   problem.  However, as there is no widely deployed key infrastructure
+   available on the Internet at the time of this writing, this option
+   makes the protocol much more usable during the transition time until
+   such an infrastructure emerges, while still providing a much higher
+   level of security than that offered by older solutions (e.g., telnet
+   [RFC0854] and rlogin [RFC1282]).
+
+   Implementations SHOULD try to make the best effort to check host
+   keys.  An example of a possible strategy is to only accept a host key
+   without checking the first time a host is connected, save the key in
+   a local database, and compare against that key on all future
+   connections to that host.
+
+   Implementations MAY provide additional methods for verifying the
+   correctness of host keys, e.g., a hexadecimal fingerprint derived
+   from the SHA-1 hash [FIPS-180-2] of the public key.  Such
+   fingerprints can easily be verified by using telephone or other
+   external communication channels.
+
+   All implementations SHOULD provide an option not to accept host keys
+   that cannot be verified.
+
+   The members of this Working Group believe that 'ease of use' is
+   critical to end-user acceptance of security solutions, and no
+   improvement in security is gained if the new solutions are not used.
+   Thus, providing the option not to check the server host key is
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 5]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   believed to improve the overall security of the Internet, even though
+   it reduces the security of the protocol in configurations where it is
+   allowed.
+
+4.2.  Extensibility
+
+   We believe that the protocol will evolve over time, and some
+   organizations will want to use their own encryption, authentication,
+   and/or key exchange methods.  Central registration of all extensions
+   is cumbersome, especially for experimental or classified features.
+   On the other hand, having no central registration leads to conflicts
+   in method identifiers, making interoperability difficult.
+
+   We have chosen to identify algorithms, methods, formats, and
+   extension protocols with textual names that are of a specific format.
+   DNS names are used to create local namespaces where experimental or
+   classified extensions can be defined without fear of conflicts with
+   other implementations.
+
+   One design goal has been to keep the base protocol as simple as
+   possible, and to require as few algorithms as possible.  However, all
+   implementations MUST support a minimal set of algorithms to ensure
+   interoperability (this does not imply that the local policy on all
+   hosts would necessarily allow these algorithms).  The mandatory
+   algorithms are specified in the relevant protocol documents.
+
+   Additional algorithms, methods, formats, and extension protocols can
+   be defined in separate documents.  See Section 6, Algorithm Naming,
+   for more information.
+
+4.3.  Policy Issues
+
+   The protocol allows full negotiation of encryption, integrity, key
+   exchange, compression, and public key algorithms and formats.
+   Encryption, integrity, public key, and compression algorithms can be
+   different for each direction.
+
+   The following policy issues SHOULD be addressed in the configuration
+   mechanisms of each implementation:
+
+   o  Encryption, integrity, and compression algorithms, separately for
+      each direction.  The policy MUST specify which is the preferred
+      algorithm (e.g., the first algorithm listed in each category).
+
+   o  Public key algorithms and key exchange method to be used for host
+      authentication.  The existence of trusted host keys for different
+      public key algorithms also affects this choice.
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 6]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   o  The authentication methods that are to be required by the server
+      for each user.  The server's policy MAY require multiple
+      authentication for some or all users.  The required algorithms MAY
+      depend on the location from where the user is trying to gain
+      access.
+
+   o  The operations that the user is allowed to perform using the
+      connection protocol.  Some issues are related to security; for
+      example, the policy SHOULD NOT allow the server to start sessions
+      or run commands on the client machine, and MUST NOT allow
+      connections to the authentication agent unless forwarding such
+      connections has been requested.  Other issues, such as which
+      TCP/IP ports can be forwarded and by whom, are clearly issues of
+      local policy.  Many of these issues may involve traversing or
+      bypassing firewalls, and are interrelated with the local security
+      policy.
+
+4.4.  Security Properties
+
+   The primary goal of the SSH protocol is to improve security on the
+   Internet.  It attempts to do this in a way that is easy to deploy,
+   even at the cost of absolute security.
+
+   o  All encryption, integrity, and public key algorithms used are
+      well-known, well-established algorithms.
+
+   o  All algorithms are used with cryptographically sound key sizes
+      that are believed to provide protection against even the strongest
+      cryptanalytic attacks for decades.
+
+   o  All algorithms are negotiated, and in case some algorithm is
+      broken, it is easy to switch to some other algorithm without
+      modifying the base protocol.
+
+   Specific concessions were made to make widespread, fast deployment
+   easier.  The particular case where this comes up is verifying that
+   the server host key really belongs to the desired host; the protocol
+   allows the verification to be left out, but this is NOT RECOMMENDED.
+   This is believed to significantly improve usability in the short
+   term, until widespread Internet public key infrastructures emerge.
+
+4.5.  Localization and Character Set Support
+
+   For the most part, the SSH protocols do not directly pass text that
+   would be displayed to the user.  However, there are some places where
+   such data might be passed.  When applicable, the character set for
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 7]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   the data MUST be explicitly specified.  In most places, ISO-10646
+   UTF-8 encoding is used [RFC3629].  When applicable, a field is also
+   provided for a language tag [RFC3066].
+
+   One big issue is the character set of the interactive session.  There
+   is no clear solution, as different applications may display data in
+   different formats.  Different types of terminal emulation may also be
+   employed in the client, and the character set to be used is
+   effectively determined by the terminal emulation.  Thus, no place is
+   provided for directly specifying the character set or encoding for
+   terminal session data.  However, the terminal emulation type (e.g.,
+   "vt100") is transmitted to the remote site, and it implicitly
+   specifies the character set and encoding.  Applications typically use
+   the terminal type to determine what character set they use, or the
+   character set is determined using some external means.  The terminal
+   emulation may also allow configuring the default character set.  In
+   any case, the character set for the terminal session is considered
+   primarily a client local issue.
+
+   Internal names used to identify algorithms or protocols are normally
+   never displayed to users, and must be in US-ASCII.
+
+   The client and server user names are inherently constrained by what
+   the server is prepared to accept.  They might, however, occasionally
+   be displayed in logs, reports, etc.  They MUST be encoded using ISO
+   10646 UTF-8, but other encodings may be required in some cases.  It
+   is up to the server to decide how to map user names to accepted user
+   names.  Straight bit-wise, binary comparison is RECOMMENDED.
+
+   For localization purposes, the protocol attempts to minimize the
+   number of textual messages transmitted.  When present, such messages
+   typically relate to errors, debugging information, or some externally
+   configured data.  For data that is normally displayed, it SHOULD be
+   possible to fetch a localized message instead of the transmitted
+   message by using a numerical code.  The remaining messages SHOULD be
+   configurable.
+
+5.  Data Type Representations Used in the SSH Protocols
+
+   byte
+
+      A byte represents an arbitrary 8-bit value (octet).  Fixed length
+      data is sometimes represented as an array of bytes, written
+      byte[n], where n is the number of bytes in the array.
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 8]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   boolean
+
+      A boolean value is stored as a single byte.  The value 0
+      represents FALSE, and the value 1 represents TRUE.  All non-zero
+      values MUST be interpreted as TRUE; however, applications MUST NOT
+      store values other than 0 and 1.
+
+   uint32
+
+      Represents a 32-bit unsigned integer.  Stored as four bytes in the
+      order of decreasing significance (network byte order).  For
+      example: the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4
+      aa.
+
+   uint64
+
+      Represents a 64-bit unsigned integer.  Stored as eight bytes in
+      the order of decreasing significance (network byte order).
+
+   string
+
+      Arbitrary length binary string.  Strings are allowed to contain
+      arbitrary binary data, including null characters and 8-bit
+      characters.  They are stored as a uint32 containing its length
+      (number of bytes that follow) and zero (= empty string) or more
+      bytes that are the value of the string.  Terminating null
+      characters are not used.
+
+      Strings are also used to store text.  In that case, US-ASCII is
+      used for internal names, and ISO-10646 UTF-8 for text that might
+      be displayed to the user.  The terminating null character SHOULD
+      NOT normally be stored in the string.  For example: the US-ASCII
+      string "testing" is represented as 00 00 00 07 t e s t i n g.  The
+      UTF-8 mapping does not alter the encoding of US-ASCII characters.
+
+   mpint
+
+      Represents multiple precision integers in two's complement format,
+      stored as a string, 8 bits per byte, MSB first.  Negative numbers
+      have the value 1 as the most significant bit of the first byte of
+      the data partition.  If the most significant bit would be set for
+      a positive number, the number MUST be preceded by a zero byte.
+      Unnecessary leading bytes with the value 0 or 255 MUST NOT be
+      included.  The value zero MUST be stored as a string with zero
+      bytes of data.
+
+      By convention, a number that is used in modular computations in
+      Z_n SHOULD be represented in the range 0 <= x < n.
+
+
+
+Ylonen & Lonvick            Standards Track                     [Page 9]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+         Examples:
+
+         value (hex)        representation (hex)
+         -----------        --------------------
+         0                  00 00 00 00
+         9a378f9b2e332a7    00 00 00 08 09 a3 78 f9 b2 e3 32 a7
+         80                 00 00 00 02 00 80
+         -1234              00 00 00 02 ed cc
+         -deadbeef          00 00 00 05 ff 21 52 41 11
+
+   name-list
+
+      A string containing a comma-separated list of names.  A name-list
+      is represented as a uint32 containing its length (number of bytes
+      that follow) followed by a comma-separated list of zero or more
+      names.  A name MUST have a non-zero length, and it MUST NOT
+      contain a comma (",").  As this is a list of names, all of the
+      elements contained are names and MUST be in US-ASCII.  Context may
+      impose additional restrictions on the names.  For example, the
+      names in a name-list may have to be a list of valid algorithm
+      identifiers (see Section 6 below), or a list of [RFC3066] language
+      tags.  The order of the names in a name-list may or may not be
+      significant.  Again, this depends on the context in which the list
+      is used.  Terminating null characters MUST NOT be used, neither
+      for the individual names, nor for the list as a whole.
+
+       Examples:
+
+       value                      representation (hex)
+       -----                      --------------------
+       (), the empty name-list    00 00 00 00
+       ("zlib")                   00 00 00 04 7a 6c 69 62
+       ("zlib,none")              00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
+
+6.  Algorithm and Method Naming
+
+   The SSH protocols refer to particular hash, encryption, integrity,
+   compression, and key exchange algorithms or methods by name.  There
+   are some standard algorithms and methods that all implementations
+   MUST support.  There are also algorithms and methods that are defined
+   in the protocol specification, but are OPTIONAL.  Furthermore, it is
+   expected that some organizations will want to use their own
+   algorithms or methods.
+
+   In this protocol, all algorithm and method identifiers MUST be
+   printable US-ASCII, non-empty strings no longer than 64 characters.
+   Names MUST be case-sensitive.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 10]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   There are two formats for algorithm and method names:
+
+   o  Names that do not contain an at-sign ("@") are reserved to be
+      assigned by IETF CONSENSUS.  Examples include "3des-cbc", "sha-1",
+      "hmac-sha1", and "zlib" (the doublequotes are not part of the
+      name).  Names of this format are only valid if they are first
+      registered with the IANA.  Registered names MUST NOT contain an
+      at-sign ("@"), comma (","), whitespace, control characters (ASCII
+      codes 32 or less), or the ASCII code 127 (DEL).  Names are case-
+      sensitive, and MUST NOT be longer than 64 characters.
+
+   o  Anyone can define additional algorithms or methods by using names
+      in the format name@domainname, e.g., "ourcipher-cbc@example.com".
+      The format of the part preceding the at-sign is not specified;
+      however, these names MUST be printable US-ASCII strings, and MUST
+      NOT contain the comma character (","), whitespace, control
+      characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
+      They MUST have only a single at-sign in them.  The part following
+      the at-sign MUST be a valid, fully qualified domain name [RFC1034]
+      controlled by the person or organization defining the name.  Names
+      are case-sensitive, and MUST NOT be longer than 64 characters.  It
+      is up to each domain how it manages its local namespace.  It
+      should be noted that these names resemble STD 11 [RFC0822] email
+      addresses.  This is purely coincidental and has nothing to do with
+      STD 11 [RFC0822].
+
+7.  Message Numbers
+
+   SSH packets have message numbers in the range 1 to 255.  These
+   numbers have been allocated as follows:
+
+   Transport layer protocol:
+
+      1 to 19    Transport layer generic (e.g., disconnect, ignore,
+                 debug, etc.)
+      20 to 29   Algorithm negotiation
+      30 to 49   Key exchange method specific (numbers can be reused
+                 for different authentication methods)
+
+   User authentication protocol:
+
+      50 to 59   User authentication generic
+      60 to 79   User authentication method specific (numbers can be
+                 reused for different authentication methods)
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 11]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   Connection protocol:
+
+      80 to 89   Connection protocol generic
+      90 to 127  Channel related messages
+
+   Reserved for client protocols:
+
+      128 to 191 Reserved
+
+   Local extensions:
+
+      192 to 255 Local extensions
+
+8.  IANA Considerations
+
+   This document is part of a set.  The instructions for the IANA for
+   the SSH protocol, as defined in this document, [SSH-USERAUTH],
+   [SSH-TRANS], and [SSH-CONNECT], are detailed in [SSH-NUMBERS].  The
+   following is a brief summary for convenience, but note well that
+   [SSH-NUMBERS] contains the actual instructions to the IANA, which may
+   be superseded in the future.
+
+   Allocation of the following types of names in the SSH protocols is
+   assigned by IETF consensus:
+
+   o  Service Names
+      *  Authentication Methods
+      *  Connection Protocol Channel Names
+      *  Connection Protocol Global Request Names
+      *  Connection Protocol Channel Request Names
+
+   o  Key Exchange Method Names
+
+   o  Assigned Algorithm Names
+      *  Encryption Algorithm Names
+      *  MAC Algorithm Names
+      *  Public Key Algorithm Names
+      *  Compression Algorithm Names
+
+   These names MUST be printable US-ASCII strings, and MUST NOT contain
+   the characters at-sign ("@"), comma (","), whitespace, control
+   characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
+   Names are case-sensitive, and MUST NOT be longer than 64 characters.
+
+   Names with the at-sign ("@") are locally defined extensions and are
+   not controlled by the IANA.
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 12]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   Each category of names listed above has a separate namespace.
+   However, using the same name in multiple categories SHOULD be avoided
+   to minimize confusion.
+
+   Message numbers (see Section 7) in the range of 0 to 191 are
+   allocated via IETF CONSENSUS, as described in [RFC2434].  Message
+   numbers in the 192 to 255 range (local extensions) are reserved for
+   PRIVATE USE, also as described in [RFC2434].
+
+9.  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 that can be used to authenticate the client user to the
+   server.  Individual mechanisms specified in the 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.
+
+9.1.  Pseudo-Random Number Generation
+
+   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., Diffie-
+   Hellman (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.  [RFC4086] offers suggestions for sources of
+   random numbers and entropy.  Implementers should note the importance
+   of entropy and the well-meant, anecdotal warning about the difficulty
+   in properly implementing pseudo-random number generating functions.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 13]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   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.
+
+9.2.  Control Character Filtering
+
+   When displaying text to a user, such as error or debug messages, the
+   client software SHOULD replace any control characters (except tab,
+   carriage return, and newline) with safe sequences to avoid attacks by
+   sending terminal control characters.
+
+9.3.  Transport
+
+9.3.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
+   that have been established and accepted within the industry.  At the
+   time of this writing, commonly used ciphers include 3DES, ARCFOUR,
+   twofish, serpent, and blowfish.  AES has been published by The US
+   Federal Information Processing Standards as [FIPS-197], and the
+   cryptographic community has accepted AES as well.  As always,
+   implementers and users should check current literature to ensure that
+   no recent vulnerabilities have been found in ciphers used within
+   products.  Implementers 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.  Its cryptographic properties are
+   sufficiently described in [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].  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 deemed difficult and not
+   considered fully practicable, especially if relatively long block
+   sizes are used.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 14]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   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 [ROGAWAY], [DAI], [BELLARE]) to
+   work, the attacker would need to know the Initialization Vector (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 implementer 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.  Implementers may wish to
+   check if there are any unsent packets awaiting transmission;
+   unfortunately, it is not normally easy to obtain this information
+   from the kernel or buffers.  If there are no unsent packets, 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
+   successful.
+
+   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 because it gets ACKed.
+
+   3. Yet, the attack is possible because Record 1 has already been
+      seen.
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 15]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   As this example indicates, it is unsafe to use the existence of
+   unflushed data in the TCP buffers proper as a guide to whether an
+   empty packet is needed, since when the second write() is performed
+   the buffers will contain the un-ACKed Record 1.
+
+   On the other hand, it is 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 the second SSH Record is fixed after the
+      data for the Data packet is determined, then the following should
+      be performed:
+
+         read from user
+         encrypt null packet
+         encrypt data packet
+
+9.3.2.  Data Integrity
+
+   This protocol does allow the Data Integrity mechanism to be disabled.
+   Implementers 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 [SSH-TRANS] 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.
+
+9.3.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
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 16]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   replay of data from prior sessions.  For example, the authentication
+   protocol ([SSH-USERAUTH]) 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 sessions 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 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 [RFC2085],
+   [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC4120].  The
+   underlying construct is discussed in [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 since 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), the calculated MAC will not match the MAC
+   received with the packet.
+
+9.3.4.  Man-in-the-middle
+
+   This protocol makes no assumptions or 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
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 17]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   and users to understand the importance of verifying this association
+   before any session is initiated.
+
+   There are three cases of man-in-the-middle attacks to consider.  The
+   first is where an attacker places a device between the client and the
+   server before the session is initiated.  In this case, the attack
+   device is trying to mimic the legitimate server and will offer its
+   public key to the client when the client initiates a session.  If it
+   were to offer the public key of the server, then it would not be able
+   to decrypt or sign the transmissions between the legitimate server
+   and the client unless it also had access to the private key of the
+   host.  The attack device will also, simultaneously to this, initiate
+   a session to the legitimate server, masquerading itself as the
+   client.  If the public key of the server had been securely
+   distributed to the client prior to that session initiation, the key
+   offered to the client by the attack device will not match the key
+   stored on the client.  In that case, the user SHOULD be given a
+   warning that the offered host key does not match the host key cached
+   on the client.  As described in Section 4.1, 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 the user may make an informed decision.  If the user
+   chooses to continue the session with the stored public key of the
+   server (not the public key offered at the start of the session), then
+   the session-specific data between the attacker and server will be
+   different between the client-to-attacker session and the attacker-
+   to-server sessions due to the randomness discussed above.  From this,
+   the attacker will not be able to make this attack work since the
+   attacker will not be able to correctly sign packets containing this
+   session-specific data from the server, since he does not have the
+   private key of that server.
+
+   The second case that should be considered is similar to the first
+   case in that it also happens at the time of connection, but this case
+   points out the need for the secure distribution of server public
+   keys.  If the server public keys are not securely distributed, then
+   the client cannot know if it is talking to the intended server.  An
+   attacker may use social engineering techniques to pass off server
+   keys to unsuspecting users and may then place a man-in-the-middle
+   attack device between the legitimate server and the clients.  If this
+   is allowed to happen, then the clients will form client-to-attacker
+   sessions, and the attacker will form attacker-to-server sessions and
+   will be able to monitor and manipulate all of the traffic between the
+   clients and the legitimate servers.  Server administrators are
+   encouraged to make host key fingerprints available for checking by
+   some means whose security does not rely on the integrity of the
+   actual host keys.  Possible mechanisms are discussed in Section 4.1
+   and may also include secured Web pages, physical pieces of paper,
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 18]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   etc.  Implementers 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 ([RFC4120]) over
+   GSS-API ([RFC1964]) during key exchange to authenticate the server
+   are possibilities.
+
+   In the third man-in-the-middle case, attackers may attempt to
+   manipulate packets in transit between peers after the session has
+   been established.  As described in Section 9.3.3, a successful attack
+   of this nature is very improbable.  As in Section 9.3.3, 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
+   [RFC2104].  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 this, implementers
+   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.  However, it may be necessary in
+   non-security-critical environments, and will still provide protection
+   against passive attacks.  Implementers of protocols and applications
+   running on top of this protocol should keep this possibility in mind.
+
+9.3.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.  Implementers SHOULD provide features that make this
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 19]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   more difficult, for example, only allowing connections from a subset
+   of clients known to have valid users.
+
+9.3.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 of verifying whether such
+   information is being sent.
+
+9.3.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].  SSH sessions resulting from a key exchange using
+   the diffie-hellman methods described in the section Diffie-Hellman
+   Key Exchange of [SSH-TRANS] (including "diffie-hellman-group1-sha1"
+   and "diffie-hellman-group14-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, SSH
+   does have PFS.  However, this property is not commuted to any of the
+   applications or protocols using SSH as a transport.  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.
+
+9.3.8.  Ordering of Key Exchange Methods
+
+   As stated in the section on Algorithm Negotiation of [SSH-TRANS],
+   each device will send a list of preferred methods for key exchange.
+   The most-preferred method is the first in the list.  It is
+   RECOMMENDED that the algorithms be sorted by cryptographic strength,
+   strongest first.  Some additional guidance for this is given in
+   [RFC3766].
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 20]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+9.3.9.  Traffic Analysis
+
+   Passive monitoring of any protocol may give an attacker some
+   information about the session, the user, or protocol specific
+   information that they would otherwise not be able to garner.  For
+   example, it has been shown that traffic analysis of an SSH session
+   can yield information about the length of the password - [Openwall]
+   and [USENIX].  Implementers should use the SSH_MSG_IGNORE packet,
+   along with the inclusion of random lengths of padding, to thwart
+   attempts at traffic analysis.  Other methods may also be found and
+   implemented.
+
+9.4.  Authentication Protocol
+
+   The purpose of this protocol is to perform client user
+   authentication.  It assumes 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.
+
+   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.
+
+9.4.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 stated above, that the Authentication Protocol only
+   runs 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-
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 21]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   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.
+
+9.4.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.
+   Administrators of host machines should make all attempts to
+   compartmentalize all event notification messages and protect them
+   from unwarranted observation.  Developers should be aware of the
+   sensitive nature of some of the normal event and debug messages, and
+   may want to provide guidance to administrators on ways to keep this
+   information away from unauthorized people.  Developers should
+   consider minimizing the amount of sensitive information obtainable by
+   users during the authentication phase, in accordance with the local
+   policies.  For this reason, it is RECOMMENDED that debug messages be
+   initially disabled at the time of deployment and require an active
+   decision by an administrator to allow them to be enabled.  It is also
+   RECOMMENDED that a message expressing this concern be presented to
+   the administrator of a system when the action is taken to enable
+   debugging messages.
+
+9.4.3.  Local Security Policy
+
+   The 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, 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.
+
+   Implementers are encouraged to provide a default local policy and
+   make its parameters known to administrators and users.  At the
+   discretion of the implementers, 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
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 22]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   which case, the administrators will have to actively make changes to
+   the initial default parameters 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.
+
+9.4.4  Public Key Authentication
+
+   The use of public key authentication assumes that the client host has
+   not been compromised.  It also assumes that the private key of the
+   server 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 the section on Password Authentication below.)
+
+9.4.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.
+
+9.4.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.
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 23]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+9.5.  Connection Protocol
+
+9.5.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 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.
+   Implementers 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 targeted in port-forwarding operations, which users
+   are allowed to use interactive shell facilities, or which users are
+   allowed to use exposed subsystems.
+
+9.5.2.  Proxy Forwarding
+
+   The SSH connection protocol allows for proxy forwarding of other
+   protocols such as SMTP, 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.  Implementers 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.
+
+9.5.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.  Implementers, administrators,
+   and users who wish to further explore the security mechanisms of X11
+   are invited to read [SCHEIFLER] and analyze previously reported
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 24]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   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 SSH (or other secure protocols), combined with
+   actual and pseudo-displays that accept connections only over local
+   IPC mechanisms authorized by permissions or access control lists
+   (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 allow the display to open only over local
+   IPC.  It is RECOMMENDED that SSH server implementations that support
+   X11 forwarding default to allow the display to open only over local
+   IPC.  On single-user systems, it might be reasonable to default to
+   allow the local display to open over TCP/IP.
+
+   Implementers 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 25]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+10.  References
+
+10.1.  Normative References
+
+   [SSH-TRANS]        Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                      (SSH) Transport Layer Protocol", RFC 4253, January
+                      2006.
+
+   [SSH-USERAUTH]     Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                      (SSH) Authentication Protocol", RFC 4252, January
+                      2006.
+
+   [SSH-CONNECT]      Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+                      (SSH) Connection Protocol", RFC 4254, January
+                      2006.
+
+   [SSH-NUMBERS]      Lehtinen, S. and C. Lonvick, Ed., "The Secure
+                      Shell (SSH) Protocol Assigned Numbers", RFC 4250,
+                      January 2006.
+
+   [RFC2119]          Bradner, S., "Key words for use in RFCs to
+                      Indicate Requirement Levels", BCP 14, RFC 2119,
+                      March 1997.
+
+   [RFC2434]          Narten, T. and H. Alvestrand, "Guidelines for
+                      Writing an IANA Considerations Section in RFCs",
+                      BCP 26, RFC 2434, October 1998.
+
+   [RFC3066]          Alvestrand, H., "Tags for the Identification of
+                      Languages", BCP 47, RFC 3066, January 2001.
+
+   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
+                      ISO 10646", STD 63, RFC 3629, November 2003.
+
+10.2.  Informative References
+
+   [RFC0822]          Crocker, D., "Standard for the format of ARPA
+                      Internet text messages", STD 11, RFC 822, August
+                      1982.
+
+   [RFC0854]          Postel, J. and J. Reynolds, "Telnet Protocol
+                      Specification", STD 8, RFC 854, May 1983.
+
+   [RFC1034]          Mockapetris, P., "Domain names - concepts and
+                      facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 26]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   [RFC1282]          Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
+
+   [RFC4120]          Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
+                      "The Kerberos Network Authentication Service
+                      (V5)", RFC 4120, July 2005.
+
+   [RFC1964]          Linn, J., "The Kerberos Version 5 GSS-API
+                      Mechanism", RFC 1964, June 1996.
+
+   [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]          Dierks, 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.
+
+   [RFC3766]          Orman, H. and P. Hoffman, "Determining Strengths
+                      For Public Keys Used For Exchanging Symmetric
+                      Keys", BCP 86, RFC 3766, April 2004.
+
+   [RFC4086]          Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                      "Randomness Requirements for Security", BCP 106,
+                      RFC 4086, June 2005.
+
+   [FIPS-180-2]       US National Institute of Standards and Technology,
+                      "Secure Hash Standard (SHS)", Federal Information
+                      Processing Standards Publication 180-2, August
+                      2002.
+
+   [FIPS-186-2]       US National Institute of Standards and Technology,
+                      "Digital Signature Standard (DSS)", Federal
+                      Information Processing Standards Publication 186-
+                      2, January 2000.
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 27]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   [FIPS-197]         US National Institute of Standards and Technology,
+                      "Advanced Encryption Standard (AES)", Federal
+                      Information Processing Standards Publication 197,
+                      November 2001.
+
+   [ANSI-T1.523-2001] American National Standards Institute, Inc.,
+                      "Telecom Glossary 2000", ANSI T1.523-2001,
+                      February 2001.
+
+   [SCHNEIER]         Schneier, B., "Applied Cryptography Second
+                      Edition:  protocols algorithms and source in code
+                      in C", John Wiley and Sons, New York, NY, 1996.
+
+   [SCHEIFLER]        Scheifler, R., "X Window System : The Complete
+                      Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
+                      edition.", Digital Press, ISBN 1555580882,
+                      February 1992.
+
+   [KAUFMAN]          Kaufman, C., Perlman, R., and M. Speciner,
+                      "Network Security: PRIVATE Communication in a
+                      PUBLIC World", Prentice Hall Publisher, 1995.
+
+   [CERT]             CERT Coordination Center, The.,
+                      "http://www.cert.org/nav/index_red.html".
+
+   [VENEMA]           Venema, W., "Murphy's Law and Computer Security",
+                      Proceedings of 6th USENIX Security Symposium, San
+                      Jose CA
+                      http://www.usenix.org/publications/library/
+                      proceedings/sec96/venema.html, July 1996.
+
+   [ROGAWAY]          Rogaway, P., "Problems with Proposed IP
+                      Cryptography", Unpublished paper
+                      http://www.cs.ucdavis.edu/~rogaway/ papers/draft-
+                      rogaway-ipsec-comments-00.txt, 1996.
+
+   [DAI]              Dai, W., "An attack against SSH2 protocol", Email
+                      to the SECSH Working Group ietf-ssh@netbsd.org
+                      ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002-
+                      02.mail, Feb 2002.
+
+   [BELLARE]          Bellaire, M., Kohno, T., and C. Namprempre,
+                      "Authenticated Encryption in SSH: Fixing the SSH
+                      Binary Packet Protocol", Proceedings of the 9th
+                      ACM Conference on Computer and Communications
+                      Security, Sept 2002.
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 28]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+   [Openwall]         Solar Designer and D. Song, "SSH Traffic Analysis
+                      Attacks", Presentation given at HAL2001 and
+                      NordU2002 Conferences, Sept 2001.
+
+   [USENIX]           Song, X.D., Wagner, D., and X. Tian, "Timing
+                      Analysis of Keystrokes and SSH Timing Attacks",
+                      Paper given at 10th USENIX Security Symposium,
+                      2001.
+
+Authors' Addresses
+
+   Tatu Ylonen
+   SSH Communications Security Corp
+   Valimotie 17
+   00380 Helsinki
+   Finland
+
+   EMail: ylo@ssh.com
+
+
+   Chris Lonvick (editor)
+   Cisco Systems, Inc.
+   12515 Research Blvd.
+   Austin  78759
+   USA
+
+   EMail: clonvick@cisco.com
+
+Trademark Notice
+
+   "ssh" is a registered trademark in the United States and/or other
+   countries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 29]
+
+RFC 4251               SSH Protocol Architecture            January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Ylonen & Lonvick            Standards Track                    [Page 30]
+