[Nmailserver-commits] SF.net SVN: nmailserver: [106] NMail/trunk/doc/RFC
Brought to you by:
dframpton-oss,
tmyroadctfig
Menu
▾
▴
[Nmailserver-commits] SF.net SVN: nmailserver: [106] NMail/trunk/doc/RFC
|
From: <tmy...@us...> - 2007-01-02 12:56:33
|
Revision: 106
http://svn.sourceforge.net/nmailserver/?rev=106&view=rev
Author: tmyroadctfig
Date: 2007-01-02 04:56:34 -0800 (Tue, 02 Jan 2007)
Log Message:
-----------
Added some SSH RFCs.
Added Paths:
-----------
NMail/trunk/doc/RFC/SSH/
NMail/trunk/doc/RFC/SSH/rfc4251_protocol_architecture.txt
NMail/trunk/doc/RFC/SSH/rfc4252_auth_protocol.txt
NMail/trunk/doc/RFC/SSH/rfc4253_transport_layer_protocol.txt
NMail/trunk/doc/RFC/SSH/rfc4254_connection_protocol.txt
NMail/trunk/doc/RFC/SSH/rfc4256.txt
Added: NMail/trunk/doc/RFC/SSH/rfc4251_protocol_architecture.txt
===================================================================
--- NMail/trunk/doc/RFC/SSH/rfc4251_protocol_architecture.txt (rev 0)
+++ NMail/trunk/doc/RFC/SSH/rfc4251_protocol_architecture.txt 2007-01-02 12:56:34 UTC (rev 106)
@@ -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., "our...@ex...".
+ 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
+ ...
[truncated message content] |
