You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mina.apache.org by gn...@apache.org on 2008/12/04 19:59:36 UTC
svn commit: r723396 [5/12] - in /mina/sshd/trunk: ./ src/ src/docs/
src/main/ src/main/filtered-resources/ src/main/filtered-resources/org/
src/main/filtered-resources/org/apache/
src/main/filtered-resources/org/apache/sshd/ src/main/java/ src/main/jav...
Added: mina/sshd/trunk/src/docs/rfc4253.txt
URL: http://svn.apache.org/viewvc/mina/sshd/trunk/src/docs/rfc4253.txt?rev=723396&view=auto
==============================================================================
--- mina/sshd/trunk/src/docs/rfc4253.txt (added)
+++ mina/sshd/trunk/src/docs/rfc4253.txt Thu Dec 4 10:59:31 2008
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group T. Ylonen
+Request for Comments: 4253 SSH Communications Security Corp
+Category: Standards Track C. Lonvick, Ed.
+ Cisco Systems, Inc.
+ January 2006
+
+
+ The Secure Shell (SSH) Transport Layer Protocol
+
+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) is a protocol for secure remote login and
+ other secure network services over an insecure network.
+
+ This document describes the SSH transport layer protocol, which
+ typically runs on top of TCP/IP. The protocol can be used as a basis
+ for a number of secure network services. It provides strong
+ encryption, server authentication, and integrity protection. It may
+ also provide compression.
+
+ Key exchange method, public key algorithm, symmetric encryption
+ algorithm, message authentication algorithm, and hash algorithm are
+ all negotiated.
+
+ This document also describes the Diffie-Hellman key exchange method
+ and the minimal set of algorithms that are needed to implement the
+ SSH transport layer protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 1]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Contributors ....................................................3
+ 3. Conventions Used in This Document ...............................3
+ 4. Connection Setup ................................................4
+ 4.1. Use over TCP/IP ............................................4
+ 4.2. Protocol Version Exchange ..................................4
+ 5. Compatibility With Old SSH Versions .............................5
+ 5.1. Old Client, New Server .....................................6
+ 5.2. New Client, Old Server .....................................6
+ 5.3. Packet Size and Overhead ...................................6
+ 6. Binary Packet Protocol ..........................................7
+ 6.1. Maximum Packet Length ......................................8
+ 6.2. Compression ................................................8
+ 6.3. Encryption .................................................9
+ 6.4. Data Integrity ............................................12
+ 6.5. Key Exchange Methods ......................................13
+ 6.6. Public Key Algorithms .....................................13
+ 7. Key Exchange ...................................................15
+ 7.1. Algorithm Negotiation .....................................17
+ 7.2. Output from Key Exchange ..................................20
+ 7.3. Taking Keys Into Use ......................................21
+ 8. Diffie-Hellman Key Exchange ....................................21
+ 8.1. diffie-hellman-group1-sha1 ................................23
+ 8.2. diffie-hellman-group14-sha1 ...............................23
+ 9. Key Re-Exchange ................................................23
+ 10. Service Request ...............................................24
+ 11. Additional Messages ...........................................25
+ 11.1. Disconnection Message ....................................25
+ 11.2. Ignored Data Message .....................................26
+ 11.3. Debug Message ............................................26
+ 11.4. Reserved Messages ........................................27
+ 12. Summary of Message Numbers ....................................27
+ 13. IANA Considerations ...........................................27
+ 14. Security Considerations .......................................28
+ 15. References ....................................................29
+ 15.1. Normative References .....................................29
+ 15.2. Informative References ...................................30
+ Authors' Addresses ................................................31
+ Trademark Notice ..................................................31
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 2]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+1. Introduction
+
+ The SSH transport layer is a secure, low level transport protocol.
+ It provides strong encryption, cryptographic host authentication, and
+ integrity protection.
+
+ Authentication in this protocol level is host-based; this protocol
+ does not perform user authentication. A higher level protocol for
+ user authentication can be designed on top of this protocol.
+
+ The protocol has been designed to be simple and flexible to allow
+ parameter negotiation, and to minimize the number of round-trips.
+ The key exchange method, public key algorithm, symmetric encryption
+ algorithm, message authentication algorithm, and hash algorithm are
+ all negotiated. It is expected that in most environments, only 2
+ round-trips will be needed for full key exchange, server
+ authentication, service request, and acceptance notification of
+ service request. The worst case is 3 round-trips.
+
+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.
+
+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].
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 3]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ 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. Connection Setup
+
+ SSH works over any 8-bit clean, binary-transparent transport. The
+ underlying transport SHOULD protect against transmission errors, as
+ such errors cause the SSH connection to terminate.
+
+ The client initiates the connection.
+
+4.1. Use over TCP/IP
+
+ When used over TCP/IP, the server normally listens for connections on
+ port 22. This port number has been registered with the IANA, and has
+ been officially assigned for SSH.
+
+4.2. Protocol Version Exchange
+
+ When the connection has been established, both sides MUST send an
+ identification string. This identification string MUST be
+
+ SSH-protoversion-softwareversion SP comments CR LF
+
+ Since the protocol being defined in this set of documents is version
+ 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is
+ OPTIONAL. If the 'comments' string is included, a 'space' character
+ (denoted above as SP, ASCII 32) MUST separate the 'softwareversion'
+ and 'comments' strings. The identification MUST be terminated by a
+ single Carriage Return (CR) and a single Line Feed (LF) character
+ (ASCII 13 and 10, respectively). Implementers who wish to maintain
+
+
+
+Ylonen & Lonvick Standards Track [Page 4]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ compatibility with older, undocumented versions of this protocol may
+ want to process the identification string without expecting the
+ presence of the carriage return character for reasons described in
+ Section 5 of this document. The null character MUST NOT be sent.
+ The maximum length of the string is 255 characters, including the
+ Carriage Return and Line Feed.
+
+ The part of the identification string preceding the Carriage Return
+ and Line Feed is used in the Diffie-Hellman key exchange (see Section
+ 8).
+
+ The server MAY send other lines of data before sending the version
+ string. Each line SHOULD be terminated by a Carriage Return and Line
+ Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded
+ in ISO-10646 UTF-8 [RFC3629] (language is not specified). Clients
+ MUST be able to process such lines. Such lines MAY be silently
+ ignored, or MAY be displayed to the client user. If they are
+ displayed, control character filtering, as discussed in [SSH-ARCH],
+ SHOULD be used. The primary use of this feature is to allow TCP-
+ wrappers to display an error message before disconnecting.
+
+ Both the 'protoversion' and 'softwareversion' strings MUST consist of
+ printable US-ASCII characters, with the exception of whitespace
+ characters and the minus sign (-). The 'softwareversion' string is
+ primarily used to trigger compatibility extensions and to indicate
+ the capabilities of an implementation. The 'comments' string SHOULD
+ contain additional information that might be useful in solving user
+ problems. As such, an example of a valid identification string is
+
+ SSH-2.0-billsSSH_3.6.3q3<CR><LF>
+
+ This identification string does not contain the optional 'comments'
+ string and is thus terminated by a CR and LF immediately after the
+ 'softwareversion' string.
+
+ Key exchange will begin immediately after sending this identifier.
+ All packets following the identification string SHALL use the binary
+ packet protocol, which is described in Section 6.
+
+5. Compatibility With Old SSH Versions
+
+ As stated earlier, the 'protoversion' specified for this protocol is
+ "2.0". Earlier versions of this protocol have not been formally
+ documented, but it is widely known that they use 'protoversion' of
+ "1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many
+ implementations of SSH are utilizing protocol version 2.0, but it is
+ known that there are still devices using the previous versions.
+ During the transition period, it is important to be able to work in a
+
+
+
+Ylonen & Lonvick Standards Track [Page 5]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ way that is compatible with the installed SSH clients and servers
+ that use the older version of the protocol. Information in this
+ section is only relevant for implementations supporting compatibility
+ with SSH versions 1.x. For those interested, the only known
+ documentation of the 1.x protocol is contained in README files that
+ are shipped along with the source code [ssh-1.2.30].
+
+5.1. Old Client, New Server
+
+ Server implementations MAY support a configurable compatibility flag
+ that enables compatibility with old versions. When this flag is on,
+ the server SHOULD identify its 'protoversion' as "1.99". Clients
+ using protocol 2.0 MUST be able to identify this as identical to
+ "2.0". In this mode, the server SHOULD NOT send the Carriage Return
+ character (ASCII 13) after the identification string.
+
+ In the compatibility mode, the server SHOULD NOT send any further
+ data after sending its identification string until it has received an
+ identification string from the client. The server can then determine
+ whether the client is using an old protocol, and can revert to the
+ old protocol if required. In the compatibility mode, the server MUST
+ NOT send additional data before the identification string.
+
+ When compatibility with old clients is not needed, the server MAY
+ send its initial key exchange data immediately after the
+ identification string.
+
+5.2. New Client, Old Server
+
+ Since the new client MAY immediately send additional data after its
+ identification string (before receiving the server's identification
+ string), the old protocol may already be corrupt when the client
+ learns that the server is old. When this happens, the client SHOULD
+ close the connection to the server, and reconnect using the old
+ protocol.
+
+5.3. Packet Size and Overhead
+
+ Some readers will worry about the increase in packet size due to new
+ headers, padding, and the Message Authentication Code (MAC). The
+ minimum packet size is in the order of 28 bytes (depending on
+ negotiated algorithms). The increase is negligible for large
+ packets, but very significant for one-byte packets (telnet-type
+ sessions). There are, however, several factors that make this a
+ non-issue in almost all cases:
+
+ o The minimum size of a TCP/IP header is 32 bytes. Thus, the
+ increase is actually from 33 to 51 bytes (roughly).
+
+
+
+Ylonen & Lonvick Standards Track [Page 6]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ o The minimum size of the data field of an Ethernet packet is 46
+ bytes [RFC0894]. Thus, the increase is no more than 5 bytes.
+ When Ethernet headers are considered, the increase is less than 10
+ percent.
+
+ o The total fraction of telnet-type data in the Internet is
+ negligible, even with increased packet sizes.
+
+ The only environment where the packet size increase is likely to have
+ a significant effect is PPP [RFC1661] over slow modem lines (PPP
+ compresses the TCP/IP headers, emphasizing the increase in packet
+ size). However, with modern modems, the time needed to transfer is
+ in the order of 2 milliseconds, which is a lot faster than people can
+ type.
+
+ There are also issues related to the maximum packet size. To
+ minimize delays in screen updates, one does not want excessively
+ large packets for interactive sessions. The maximum packet size is
+ negotiated separately for each channel.
+
+6. Binary Packet Protocol
+
+ Each packet is in the following format:
+
+ uint32 packet_length
+ byte padding_length
+ byte[n1] payload; n1 = packet_length - padding_length - 1
+ byte[n2] random padding; n2 = padding_length
+ byte[m] mac (Message Authentication Code - MAC); m = mac_length
+
+ packet_length
+ The length of the packet in bytes, not including 'mac' or the
+ 'packet_length' field itself.
+
+ padding_length
+ Length of 'random padding' (bytes).
+
+ payload
+ The useful contents of the packet. If compression has been
+ negotiated, this field is compressed. Initially, compression
+ MUST be "none".
+
+ random padding
+ Arbitrary-length padding, such that the total length of
+ (packet_length || padding_length || payload || random padding)
+ is a multiple of the cipher block size or 8, whichever is
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 7]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ larger. There MUST be at least four bytes of padding. The
+ padding SHOULD consist of random bytes. The maximum amount of
+ padding is 255 bytes.
+
+ mac
+ Message Authentication Code. If message authentication has
+ been negotiated, this field contains the MAC bytes. Initially,
+ the MAC algorithm MUST be "none".
+
+ Note that the length of the concatenation of 'packet_length',
+ 'padding_length', 'payload', and 'random padding' MUST be a multiple
+ of the cipher block size or 8, whichever is larger. This constraint
+ MUST be enforced, even when using stream ciphers. Note that the
+ 'packet_length' field is also encrypted, and processing it requires
+ special care when sending or receiving packets. Also note that the
+ insertion of variable amounts of 'random padding' may help thwart
+ traffic analysis.
+
+ The minimum size of a packet is 16 (or the cipher block size,
+ whichever is larger) bytes (plus 'mac'). Implementations SHOULD
+ decrypt the length after receiving the first 8 (or cipher block size,
+ whichever is larger) bytes of a packet.
+
+6.1. Maximum Packet Length
+
+ All implementations MUST be able to process packets with an
+ uncompressed payload length of 32768 bytes or less and a total packet
+ size of 35000 bytes or less (including 'packet_length',
+ 'padding_length', 'payload', 'random padding', and 'mac'). The
+ maximum of 35000 bytes is an arbitrarily chosen value that is larger
+ than the uncompressed length noted above. Implementations SHOULD
+ support longer packets, where they might be needed. For example, if
+ an implementation wants to send a very large number of certificates,
+ the larger packets MAY be sent if the identification string indicates
+ that the other party is able to process them. However,
+ implementations SHOULD check that the packet length is reasonable in
+ order for the implementation to avoid denial of service and/or buffer
+ overflow attacks.
+
+6.2. Compression
+
+ If compression has been negotiated, the 'payload' field (and only it)
+ will be compressed using the negotiated algorithm. The
+ 'packet_length' field and 'mac' will be computed from the compressed
+ payload. Encryption will be done after compression.
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 8]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ Compression MAY be stateful, depending on the method. Compression
+ MUST be independent for each direction, and implementations MUST
+ allow independent choosing of the algorithm for each direction. In
+ practice however, it is RECOMMENDED that the compression method be
+ the same in both directions.
+
+ The following compression methods are currently defined:
+
+ none REQUIRED no compression
+ zlib OPTIONAL ZLIB (LZ77) compression
+
+ The "zlib" compression is described in [RFC1950] and in [RFC1951].
+ The compression context is initialized after each key exchange, and
+ is passed from one packet to the next, with only a partial flush
+ being performed at the end of each packet. A partial flush means
+ that the current compressed block is ended and all data will be
+ output. If the current block is not a stored block, one or more
+ empty blocks are added after the current block to ensure that there
+ are at least 8 bits, counting from the start of the end-of-block code
+ of the current block to the end of the packet payload.
+
+ Additional methods may be defined as specified in [SSH-ARCH] and
+ [SSH-NUMBERS].
+
+6.3. Encryption
+
+ An encryption algorithm and a key will be negotiated during the key
+ exchange. When encryption is in effect, the packet length, padding
+ length, payload, and padding fields of each packet MUST be encrypted
+ with the given algorithm.
+
+ The encrypted data in all packets sent in one direction SHOULD be
+ considered a single data stream. For example, initialization vectors
+ SHOULD be passed from the end of one packet to the beginning of the
+ next packet. All ciphers SHOULD use keys with an effective key
+ length of 128 bits or more.
+
+ The ciphers in each direction MUST run independently of each other.
+ Implementations MUST allow the algorithm for each direction to be
+ independently selected, if multiple algorithms are allowed by local
+ policy. In practice however, it is RECOMMENDED that the same
+ algorithm be used in both directions.
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 9]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ The following ciphers are currently defined:
+
+ 3des-cbc REQUIRED three-key 3DES in CBC mode
+ blowfish-cbc OPTIONAL Blowfish in CBC mode
+ twofish256-cbc OPTIONAL Twofish in CBC mode,
+ with a 256-bit key
+ twofish-cbc OPTIONAL alias for "twofish256-cbc"
+ (this is being retained
+ for historical reasons)
+ twofish192-cbc OPTIONAL Twofish with a 192-bit key
+ twofish128-cbc OPTIONAL Twofish with a 128-bit key
+ aes256-cbc OPTIONAL AES in CBC mode,
+ with a 256-bit key
+ aes192-cbc OPTIONAL AES with a 192-bit key
+ aes128-cbc RECOMMENDED AES with a 128-bit key
+ serpent256-cbc OPTIONAL Serpent in CBC mode, with
+ a 256-bit key
+ serpent192-cbc OPTIONAL Serpent with a 192-bit key
+ serpent128-cbc OPTIONAL Serpent with a 128-bit key
+ arcfour OPTIONAL the ARCFOUR stream cipher
+ with a 128-bit key
+ idea-cbc OPTIONAL IDEA in CBC mode
+ cast128-cbc OPTIONAL CAST-128 in CBC mode
+ none OPTIONAL no encryption; NOT RECOMMENDED
+
+ The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
+ encrypt), where the first 8 bytes of the key are used for the first
+ encryption, the next 8 bytes for the decryption, and the following 8
+ bytes for the final encryption. This requires 24 bytes of key data
+ (of which 168 bits are actually used). To implement CBC mode, outer
+ chaining MUST be used (i.e., there is only one initialization
+ vector). This is a block cipher with 8-byte blocks. This algorithm
+ is defined in [FIPS-46-3]. Note that since this algorithm only has
+ an effective key length of 112 bits ([SCHNEIER]), it does not meet
+ the specifications that SSH encryption algorithms should use keys of
+ 128 bits or more. However, this algorithm is still REQUIRED for
+ historical reasons; essentially, all known implementations at the
+ time of this writing support this algorithm, and it is commonly used
+ because it is the fundamental interoperable algorithm. At some
+ future time, it is expected that another algorithm, one with better
+ strength, will become so prevalent and ubiquitous that the use of
+ "3des-cbc" will be deprecated by another STANDARDS ACTION.
+
+ The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128-bit keys
+ [SCHNEIER]. This is a block cipher with 8-byte blocks.
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 10]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
+ with 256-bit keys as described [TWOFISH]. This is a block cipher
+ with 16-byte blocks.
+
+ The "twofish192-cbc" cipher is the same as above, but with a 192-bit
+ key.
+
+ The "twofish128-cbc" cipher is the same as above, but with a 128-bit
+ key.
+
+ The "aes256-cbc" cipher is AES (Advanced Encryption Standard)
+ [FIPS-197], in CBC mode. This version uses a 256-bit key.
+
+ The "aes192-cbc" cipher is the same as above, but with a 192-bit key.
+
+ The "aes128-cbc" cipher is the same as above, but with a 128-bit key.
+
+ The "serpent256-cbc" cipher in CBC mode, with a 256-bit key as
+ described in the Serpent AES submission.
+
+ The "serpent192-cbc" cipher is the same as above, but with a 192-bit
+ key.
+
+ The "serpent128-cbc" cipher is the same as above, but with a 128-bit
+ key.
+
+ The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
+ The Arcfour cipher is believed to be compatible with the RC4 cipher
+ [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and
+ should be used with caution.
+
+ The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
+
+ The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode with a
+ 128-bit key [RFC2144].
+
+ The "none" algorithm specifies that no encryption is to be done.
+ Note that this method provides no confidentiality protection, and it
+ is NOT RECOMMENDED. Some functionality (e.g., password
+ authentication) may be disabled for security reasons if this cipher
+ is chosen.
+
+ Additional methods may be defined as specified in [SSH-ARCH] and in
+ [SSH-NUMBERS].
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 11]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+6.4. Data Integrity
+
+ Data integrity is protected by including with each packet a MAC that
+ is computed from a shared secret, packet sequence number, and the
+ contents of the packet.
+
+ The message authentication algorithm and key are negotiated during
+ key exchange. Initially, no MAC will be in effect, and its length
+ MUST be zero. After key exchange, the 'mac' for the selected MAC
+ algorithm will be computed before encryption from the concatenation
+ of packet data:
+
+ mac = MAC(key, sequence_number || unencrypted_packet)
+
+ where unencrypted_packet is the entire packet without 'mac' (the
+ length fields, 'payload' and 'random padding'), and sequence_number
+ is an implicit packet sequence number represented as uint32. The
+ sequence_number is initialized to zero for the first packet, and is
+ incremented after every packet (regardless of whether encryption or
+ MAC is in use). It is never reset, even if keys/algorithms are
+ renegotiated later. It wraps around to zero after every 2^32
+ packets. The packet sequence_number itself is not included in the
+ packet sent over the wire.
+
+ The MAC algorithms for each direction MUST run independently, and
+ implementations MUST allow choosing the algorithm independently for
+ both directions. In practice however, it is RECOMMENDED that the
+ same algorithm be used in both directions.
+
+ The value of 'mac' resulting from the MAC algorithm MUST be
+ transmitted without encryption as the last part of the packet. The
+ number of 'mac' bytes depends on the algorithm chosen.
+
+ The following MAC algorithms are currently defined:
+
+ hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key
+ length = 20)
+ hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest
+ length = 12, key length = 20)
+ hmac-md5 OPTIONAL HMAC-MD5 (digest length = key
+ length = 16)
+ hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest
+ length = 12, key length = 16)
+ none OPTIONAL no MAC; NOT RECOMMENDED
+
+ The "hmac-*" algorithms are described in [RFC2104]. The "*-n" MACs
+ use only the first n bits of the resulting value.
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 12]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ SHA-1 is described in [FIPS-180-2] and MD5 is described in [RFC1321].
+
+ Additional methods may be defined, as specified in [SSH-ARCH] and in
+ [SSH-NUMBERS].
+
+6.5. Key Exchange Methods
+
+ The key exchange method specifies how one-time session keys are
+ generated for encryption and for authentication, and how the server
+ authentication is done.
+
+ Two REQUIRED key exchange methods have been defined:
+
+ diffie-hellman-group1-sha1 REQUIRED
+ diffie-hellman-group14-sha1 REQUIRED
+
+ These methods are described in Section 8.
+
+ Additional methods may be defined as specified in [SSH-NUMBERS]. The
+ name "diffie-hellman-group1-sha1" is used for a key exchange method
+ using an Oakley group, as defined in [RFC2409]. SSH maintains its
+ own group identifier space that is logically distinct from Oakley
+ [RFC2412] and IKE; however, for one additional group, the Working
+ Group adopted the number assigned by [RFC3526], using diffie-
+ hellman-group14-sha1 for the name of the second defined group.
+ Implementations should treat these names as opaque identifiers and
+ should not assume any relationship between the groups used by SSH and
+ the groups defined for IKE.
+
+6.6. Public Key Algorithms
+
+ This protocol has been designed to operate with almost any public key
+ format, encoding, and algorithm (signature and/or encryption).
+
+ There are several aspects that define a public key type:
+
+ o Key format: how is the key encoded and how are certificates
+ represented. The key blobs in this protocol MAY contain
+ certificates in addition to keys.
+
+ o Signature and/or encryption algorithms. Some key types may not
+ support both signing and encryption. Key usage may also be
+ restricted by policy statements (e.g., in certificates). In this
+ case, different key types SHOULD be defined for the different
+ policy alternatives.
+
+ o Encoding of signatures and/or encrypted data. This includes but
+ is not limited to padding, byte order, and data formats.
+
+
+
+Ylonen & Lonvick Standards Track [Page 13]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ The following public key and/or certificate formats are currently
+ defined:
+
+ ssh-dss REQUIRED sign Raw DSS Key
+ ssh-rsa RECOMMENDED sign Raw RSA Key
+ pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key)
+ pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key)
+
+ Additional key types may be defined, as specified in [SSH-ARCH] and
+ in [SSH-NUMBERS].
+
+ The key type MUST always be explicitly known (from algorithm
+ negotiation or some other source). It is not normally included in
+ the key blob.
+
+ Certificates and public keys are encoded as follows:
+
+ string certificate or public key format identifier
+ byte[n] key/certificate data
+
+ The certificate part may be a zero length string, but a public key is
+ required. This is the public key that will be used for
+ authentication. The certificate sequence contained in the
+ certificate blob can be used to provide authorization.
+
+ Public key/certificate formats that do not explicitly specify a
+ signature format identifier MUST use the public key/certificate
+ format identifier as the signature identifier.
+
+ Signatures are encoded as follows:
+
+ string signature format identifier (as specified by the
+ public key/certificate format)
+ byte[n] signature blob in format specific encoding.
+
+ The "ssh-dss" key format has the following specific encoding:
+
+ string "ssh-dss"
+ mpint p
+ mpint q
+ mpint g
+ mpint y
+
+ Here, the 'p', 'q', 'g', and 'y' parameters form the signature key
+ blob.
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 14]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ Signing and verifying using this key format is done according to the
+ Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
+ [FIPS-180-2].
+
+ The resulting signature is encoded as follows:
+
+ string "ssh-dss"
+ string dss_signature_blob
+
+ The value for 'dss_signature_blob' is encoded as a string containing
+ r, followed by s (which are 160-bit integers, without lengths or
+ padding, unsigned, and in network byte order).
+
+ The "ssh-rsa" key format has the following specific encoding:
+
+ string "ssh-rsa"
+ mpint e
+ mpint n
+
+ Here the 'e' and 'n' parameters form the signature key blob.
+
+ Signing and verifying using this key format is performed according to
+ the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.
+
+ The resulting signature is encoded as follows:
+
+ string "ssh-rsa"
+ string rsa_signature_blob
+
+ The value for 'rsa_signature_blob' is encoded as a string containing
+ s (which is an integer, without lengths or padding, unsigned, and in
+ network byte order).
+
+ The "pgp-sign-rsa" method indicates the certificates, the public key,
+ and the signature are in OpenPGP compatible binary format
+ ([RFC2440]). This method indicates that the key is an RSA-key.
+
+ The "pgp-sign-dss" is as above, but indicates that the key is a
+ DSS-key.
+
+7. Key Exchange
+
+ Key exchange (kex) begins by each side sending name-lists of
+ supported algorithms. Each side has a preferred algorithm in each
+ category, and it is assumed that most implementations, at any given
+ time, will use the same preferred algorithm. Each side MAY guess
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 15]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ which algorithm the other side is using, and MAY send an initial key
+ exchange packet according to the algorithm, if appropriate for the
+ preferred method.
+
+ The guess is considered wrong if:
+
+ o the kex algorithm and/or the host key algorithm is guessed wrong
+ (server and client have different preferred algorithm), or
+
+ o if any of the other algorithms cannot be agreed upon (the
+ procedure is defined below in Section 7.1).
+
+ Otherwise, the guess is considered to be right, and the
+ optimistically sent packet MUST be handled as the first key exchange
+ packet.
+
+ However, if the guess was wrong, and a packet was optimistically sent
+ by one or both parties, such packets MUST be ignored (even if the
+ error in the guess would not affect the contents of the initial
+ packet(s)), and the appropriate side MUST send the correct initial
+ packet.
+
+ A key exchange method uses explicit server authentication if the key
+ exchange messages include a signature or other proof of the server's
+ authenticity. A key exchange method uses implicit server
+ authentication if, in order to prove its authenticity, the server
+ also has to prove that it knows the shared secret, K, by sending a
+ message and a corresponding MAC that the client can verify.
+
+ The key exchange method defined by this document uses explicit server
+ authentication. However, key exchange methods with implicit server
+ authentication MAY be used with this protocol. After a key exchange
+ with implicit server authentication, the client MUST wait for a
+ response to its service request message before sending any further
+ data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 16]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+7.1. Algorithm Negotiation
+
+ Key exchange begins by each side sending the following packet:
+
+ byte SSH_MSG_KEXINIT
+ byte[16] cookie (random bytes)
+ name-list kex_algorithms
+ name-list server_host_key_algorithms
+ name-list encryption_algorithms_client_to_server
+ name-list encryption_algorithms_server_to_client
+ name-list mac_algorithms_client_to_server
+ name-list mac_algorithms_server_to_client
+ name-list compression_algorithms_client_to_server
+ name-list compression_algorithms_server_to_client
+ name-list languages_client_to_server
+ name-list languages_server_to_client
+ boolean first_kex_packet_follows
+ uint32 0 (reserved for future extension)
+
+ Each of the algorithm name-lists MUST be a comma-separated list of
+ algorithm names (see Algorithm Naming in [SSH-ARCH] and additional
+ information in [SSH-NUMBERS]). Each supported (allowed) algorithm
+ MUST be listed in order of preference, from most to least.
+
+ The first algorithm in each name-list MUST be the preferred (guessed)
+ algorithm. Each name-list MUST contain at least one algorithm name.
+
+ cookie
+ The 'cookie' MUST be a random value generated by the sender.
+ Its purpose is to make it impossible for either side to fully
+ determine the keys and the session identifier.
+
+ kex_algorithms
+ Key exchange algorithms were defined above. The first
+ algorithm MUST be the preferred (and guessed) algorithm. If
+ both sides make the same guess, that algorithm MUST be used.
+ Otherwise, the following algorithm MUST be used to choose a key
+ exchange method: Iterate over client's kex algorithms, one at a
+ time. Choose the first algorithm that satisfies the following
+ conditions:
+
+ + the server also supports the algorithm,
+
+ + if the algorithm requires an encryption-capable host key,
+ there is an encryption-capable algorithm on the server's
+ server_host_key_algorithms that is also supported by the
+ client, and
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 17]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ + if the algorithm requires a signature-capable host key,
+ there is a signature-capable algorithm on the server's
+ server_host_key_algorithms that is also supported by the
+ client.
+
+ If no algorithm satisfying all these conditions can be found, the
+ connection fails, and both sides MUST disconnect.
+
+ server_host_key_algorithms
+ A name-list of the algorithms supported for the server host
+ key. The server lists the algorithms for which it has host
+ keys; the client lists the algorithms that it is willing to
+ accept. There MAY be multiple host keys for a host, possibly
+ with different algorithms.
+
+ Some host keys may not support both signatures and encryption
+ (this can be determined from the algorithm), and thus not all
+ host keys are valid for all key exchange methods.
+
+ Algorithm selection depends on whether the chosen key exchange
+ algorithm requires a signature or an encryption-capable host
+ key. It MUST be possible to determine this from the public key
+ algorithm name. The first algorithm on the client's name-list
+ that satisfies the requirements and is also supported by the
+ server MUST be chosen. If there is no such algorithm, both
+ sides MUST disconnect.
+
+ encryption_algorithms
+ A name-list of acceptable symmetric encryption algorithms (also
+ known as ciphers) in order of preference. The chosen
+ encryption algorithm to each direction MUST be the first
+ algorithm on the client's name-list that is also on the
+ server's name-list. If there is no such algorithm, both sides
+ MUST disconnect.
+
+ Note that "none" must be explicitly listed if it is to be
+ acceptable. The defined algorithm names are listed in Section
+ 6.3.
+
+ mac_algorithms
+ A name-list of acceptable MAC algorithms in order of
+ preference. The chosen MAC algorithm MUST be the first
+ algorithm on the client's name-list that is also on the
+ server's name-list. If there is no such algorithm, both sides
+ MUST disconnect.
+
+ Note that "none" must be explicitly listed if it is to be
+ acceptable. The MAC algorithm names are listed in Section 6.4.
+
+
+
+Ylonen & Lonvick Standards Track [Page 18]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ compression_algorithms
+ A name-list of acceptable compression algorithms in order of
+ preference. The chosen compression algorithm MUST be the first
+ algorithm on the client's name-list that is also on the
+ server's name-list. If there is no such algorithm, both sides
+ MUST disconnect.
+
+ Note that "none" must be explicitly listed if it is to be
+ acceptable. The compression algorithm names are listed in
+ Section 6.2.
+
+ languages
+ This is a name-list of language tags in order of preference
+ [RFC3066]. Both parties MAY ignore this name-list. If there
+ are no language preferences, this name-list SHOULD be empty as
+ defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT
+ be present unless they are known to be needed by the sending
+ party.
+
+ first_kex_packet_follows
+ Indicates whether a guessed key exchange packet follows. If a
+ guessed packet will be sent, this MUST be TRUE. If no guessed
+ packet will be sent, this MUST be FALSE.
+
+ After receiving the SSH_MSG_KEXINIT packet from the other side,
+ each party will know whether their guess was right. If the
+ other party's guess was wrong, and this field was TRUE, the
+ next packet MUST be silently ignored, and both sides MUST then
+ act as determined by the negotiated key exchange method. If
+ the guess was right, key exchange MUST continue using the
+ guessed packet.
+
+ After the SSH_MSG_KEXINIT message exchange, the key exchange
+ algorithm is run. It may involve several packet exchanges, as
+ specified by the key exchange method.
+
+ Once a party has sent a SSH_MSG_KEXINIT message for key exchange or
+ re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section
+ 7.3), it MUST NOT send any messages other than:
+
+ o Transport layer generic messages (1 to 19) (but
+ SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be
+ sent);
+
+ o Algorithm negotiation messages (20 to 29) (but further
+ SSH_MSG_KEXINIT messages MUST NOT be sent);
+
+ o Specific key exchange method messages (30 to 49).
+
+
+
+Ylonen & Lonvick Standards Track [Page 19]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ The provisions of Section 11 apply to unrecognized messages.
+
+ Note, however, that during a key re-exchange, after sending a
+ SSH_MSG_KEXINIT message, each party MUST be prepared to process an
+ arbitrary number of messages that may be in-flight before receiving a
+ SSH_MSG_KEXINIT message from the other party.
+
+7.2. Output from Key Exchange
+
+ The key exchange produces two values: a shared secret K, and an
+ exchange hash H. Encryption and authentication keys are derived from
+ these. The exchange hash H from the first key exchange is
+ additionally used as the session identifier, which is a unique
+ identifier for this connection. It is used by authentication methods
+ as a part of the data that is signed as a proof of possession of a
+ private key. Once computed, the session identifier is not changed,
+ even if keys are later re-exchanged.
+
+ Each key exchange method specifies a hash function that is used in
+ the key exchange. The same hash algorithm MUST be used in key
+ derivation. Here, we'll call it HASH.
+
+ Encryption keys MUST be computed as HASH, of a known value and K, as
+ follows:
+
+ o Initial IV client to server: HASH(K || H || "A" || session_id)
+ (Here K is encoded as mpint and "A" as byte and session_id as raw
+ data. "A" means the single character A, ASCII 65).
+
+ o Initial IV server to client: HASH(K || H || "B" || session_id)
+
+ o Encryption key client to server: HASH(K || H || "C" || session_id)
+
+ o Encryption key server to client: HASH(K || H || "D" || session_id)
+
+ o Integrity key client to server: HASH(K || H || "E" || session_id)
+
+ o Integrity key server to client: HASH(K || H || "F" || session_id)
+
+ Key data MUST be taken from the beginning of the hash output. As
+ many bytes as needed are taken from the beginning of the hash value.
+ If the key length needed is longer than the output of the HASH, the
+ key is extended by computing HASH of the concatenation of K and H and
+ the entire key so far, and appending the resulting bytes (as many as
+ HASH generates) to the key. This process is repeated until enough
+ key material is available; the key is taken from the beginning of
+ this value. In other words:
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 20]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ K1 = HASH(K || H || X || session_id) (X is e.g., "A")
+ K2 = HASH(K || H || K1)
+ K3 = HASH(K || H || K1 || K2)
+ ...
+ key = K1 || K2 || K3 || ...
+
+ This process will lose entropy if the amount of entropy in K is
+ larger than the internal state size of HASH.
+
+7.3. Taking Keys Into Use
+
+ Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
+ This message is sent with the old keys and algorithms. All messages
+ sent after this message MUST use the new keys and algorithms.
+
+ When this message is received, the new keys and algorithms MUST be
+ used for receiving.
+
+ The purpose of this message is to ensure that a party is able to
+ respond with an SSH_MSG_DISCONNECT message that the other party can
+ understand if something goes wrong with the key exchange.
+
+ byte SSH_MSG_NEWKEYS
+
+8. Diffie-Hellman Key Exchange
+
+ The Diffie-Hellman (DH) key exchange provides a shared secret that
+ cannot be determined by either party alone. The key exchange is
+ combined with a signature with the host key to provide host
+ authentication. This key exchange method provides explicit server
+ authentication as defined in Section 7.
+
+ The following steps are used to exchange a key. In this, C is the
+ client; S is the server; p is a large safe prime; g is a generator
+ for a subgroup of GF(p); q is the order of the subgroup; V_S is S's
+ identification string; V_C is C's identification string; K_S is S's
+ public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's
+ SSH_MSG_KEXINIT message that have been exchanged before this part
+ begins.
+
+ 1. C generates a random number x (1 < x < q) and computes
+ e = g^x mod p. C sends e to S.
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 21]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ 2. S generates a random number y (0 < y < q) and computes
+ f = g^y mod p. S receives e. It computes K = e^y mod p,
+ H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)
+ (these elements are encoded according to their types; see below),
+ and signature s on H with its private host key. S sends
+ (K_S || f || s) to C. The signing operation may involve a
+ second hashing operation.
+
+ 3. C verifies that K_S really is the host key for S (e.g., using
+ certificates or a local database). C is also allowed to accept
+ the key without verification; however, doing so will render the
+ protocol insecure against active attacks (but may be desirable for
+ practical reasons in the short term in many environments). C then
+ computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S
+ || e || f || K), and verifies the signature s on H.
+
+ Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be
+ sent or accepted by either side. If this condition is violated, the
+ key exchange fails.
+
+ This is implemented with the following messages. The hash algorithm
+ for computing the exchange hash is defined by the method name, and is
+ called HASH. The public key algorithm for signing is negotiated with
+ the SSH_MSG_KEXINIT messages.
+
+ First, the client sends the following:
+
+ byte SSH_MSG_KEXDH_INIT
+ mpint e
+
+ The server then responds with the following:
+
+ byte SSH_MSG_KEXDH_REPLY
+ string server public host key and certificates (K_S)
+ mpint f
+ string signature of H
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 22]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ The hash H is computed as the HASH hash of the concatenation of the
+ following:
+
+ string V_C, the client's identification string (CR and LF
+ excluded)
+ string V_S, the server's identification string (CR and LF
+ excluded)
+ string I_C, the payload of the client's SSH_MSG_KEXINIT
+ string I_S, the payload of the server's SSH_MSG_KEXINIT
+ string K_S, the host key
+ mpint e, exchange value sent by the client
+ mpint f, exchange value sent by the server
+ mpint K, the shared secret
+
+ This value is called the exchange hash, and it is used to
+ authenticate the key exchange. The exchange hash SHOULD be kept
+ secret.
+
+ The signature algorithm MUST be applied over H, not the original
+ data. Most signature algorithms include hashing and additional
+ padding (e.g., "ssh-dss" specifies SHA-1 hashing). In that case, the
+ data is first hashed with HASH to compute H, and H is then hashed
+ with SHA-1 as part of the signing operation.
+
+8.1. diffie-hellman-group1-sha1
+
+ The "diffie-hellman-group1-sha1" method specifies the Diffie-Hellman
+ key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024-
+ bit MODP Group). This method MUST be supported for interoperability
+ as all of the known implementations currently support it. Note that
+ this method is named using the phrase "group1", even though it
+ specifies the use of Oakley Group 2.
+
+8.2. diffie-hellman-group14-sha1
+
+ The "diffie-hellman-group14-sha1" method specifies a Diffie-Hellman
+ key exchange with SHA-1 as HASH and Oakley Group 14 [RFC3526] (2048-
+ bit MODP Group), and it MUST also be supported.
+
+9. Key Re-Exchange
+
+ Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
+ not already doing a key exchange (as described in Section 7.1). When
+ this message is received, a party MUST respond with its own
+ SSH_MSG_KEXINIT message, except when the received SSH_MSG_KEXINIT
+ already was a reply. Either party MAY initiate the re-exchange, but
+ roles MUST NOT be changed (i.e., the server remains the server, and
+ the client remains the client).
+
+
+
+Ylonen & Lonvick Standards Track [Page 23]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ Key re-exchange is performed using whatever encryption was in effect
+ when the exchange was started. Encryption, compression, and MAC
+ methods are not changed before a new SSH_MSG_NEWKEYS is sent after
+ the key exchange (as in the initial key exchange). Re-exchange is
+ processed identically to the initial key exchange, except for the
+ session identifier that will remain unchanged. It is permissible to
+ change some or all of the algorithms during the re-exchange. Host
+ keys can also change. All keys and initialization vectors are
+ recomputed after the exchange. Compression and encryption contexts
+ are reset.
+
+ It is RECOMMENDED that the keys be changed after each gigabyte of
+ transmitted data or after each hour of connection time, whichever
+ comes sooner. However, since the re-exchange is a public key
+ operation, it requires a fair amount of processing power and should
+ not be performed too often.
+
+ More application data may be sent after the SSH_MSG_NEWKEYS packet
+ has been sent; key exchange does not affect the protocols that lie
+ above the SSH transport layer.
+
+10. Service Request
+
+ After the key exchange, the client requests a service. The service
+ is identified by a name. The format of names and procedures for
+ defining new names are defined in [SSH-ARCH] and [SSH-NUMBERS].
+
+ Currently, the following names have been reserved:
+
+ ssh-userauth
+ ssh-connection
+
+ Similar local naming policy is applied to the service names, as is
+ applied to the algorithm names. A local service should use the
+ PRIVATE USE syntax of "servicename@domain".
+
+ byte SSH_MSG_SERVICE_REQUEST
+ string service name
+
+ If the server rejects the service request, it SHOULD send an
+ appropriate SSH_MSG_DISCONNECT message and MUST disconnect.
+
+ When the service starts, it may have access to the session identifier
+ generated during the key exchange.
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 24]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ If the server supports the service (and permits the client to use
+ it), it MUST respond with the following:
+
+ byte SSH_MSG_SERVICE_ACCEPT
+ string service name
+
+ Message numbers used by services should be in the area reserved for
+ them (see [SSH-ARCH] and [SSH-NUMBERS]). The transport level will
+ continue to process its own messages.
+
+ Note that after a key exchange with implicit server authentication,
+ the client MUST wait for a response to its service request message
+ before sending any further data.
+
+11. Additional Messages
+
+ Either party may send any of the following messages at any time.
+
+11.1. Disconnection Message
+
+ byte SSH_MSG_DISCONNECT
+ uint32 reason code
+ string description in ISO-10646 UTF-8 encoding [RFC3629]
+ string language tag [RFC3066]
+
+ This message causes immediate termination of the connection. All
+ implementations MUST be able to process this message; they SHOULD be
+ able to send this message.
+
+ The sender MUST NOT send or receive any data after this message, and
+ the recipient MUST NOT accept any data after receiving this message.
+ The Disconnection Message 'description' string gives a more specific
+ explanation in a human-readable form. The Disconnection Message
+ 'reason code' gives the reason in a more machine-readable format
+ (suitable for localization), and can have the values as displayed in
+ the table below. Note that the decimal representation is displayed
+ in this table for readability, but the values are actually uint32
+ values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 25]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ Symbolic name reason code
+ ------------- -----------
+ SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1
+ SSH_DISCONNECT_PROTOCOL_ERROR 2
+ SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3
+ SSH_DISCONNECT_RESERVED 4
+ SSH_DISCONNECT_MAC_ERROR 5
+ SSH_DISCONNECT_COMPRESSION_ERROR 6
+ SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7
+ SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8
+ SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9
+ SSH_DISCONNECT_CONNECTION_LOST 10
+ SSH_DISCONNECT_BY_APPLICATION 11
+ SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12
+ SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13
+ SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14
+ SSH_DISCONNECT_ILLEGAL_USER_NAME 15
+
+ If the 'description' string is displayed, the control character
+ filtering discussed in [SSH-ARCH] should be used to avoid attacks by
+ sending terminal control characters.
+
+ Requests for assignments of new Disconnection Message 'reason code'
+ values (and associated 'description' text) in the range of 0x00000010
+ to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
+ described in [RFC2434]. The Disconnection Message 'reason code'
+ values in the range of 0xFE000000 through 0xFFFFFFFF are reserved for
+ PRIVATE USE. As noted, the actual instructions to the IANA are in
+ [SSH-NUMBERS].
+
+11.2. Ignored Data Message
+
+ byte SSH_MSG_IGNORE
+ string data
+
+ All implementations MUST understand (and ignore) this message at any
+ time (after receiving the identification string). No implementation
+ is required to send them. This message can be used as an additional
+ protection measure against advanced traffic analysis techniques.
+
+11.3. Debug Message
+
+ byte SSH_MSG_DEBUG
+ boolean always_display
+ string message in ISO-10646 UTF-8 encoding [RFC3629]
+ string language tag [RFC3066]
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 26]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ All implementations MUST understand this message, but they are
+ allowed to ignore it. This message is used to transmit information
+ that may help debugging. If 'always_display' is TRUE, the message
+ SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless
+ debugging information has been explicitly requested by the user.
+
+ The 'message' doesn't need to contain a newline. It is, however,
+ allowed to consist of multiple lines separated by CRLF (Carriage
+ Return - Line Feed) pairs.
+
+ If the 'message' string is displayed, the terminal control character
+ filtering discussed in [SSH-ARCH] should be used to avoid attacks by
+ sending terminal control characters.
+
+11.4. Reserved Messages
+
+ An implementation MUST respond to all unrecognized messages with an
+ SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
+ received. Such messages MUST be otherwise ignored. Later protocol
+ versions may define other meanings for these message types.
+
+ byte SSH_MSG_UNIMPLEMENTED
+ uint32 packet sequence number of rejected message
+
+12. Summary of Message Numbers
+
+ The following is a summary of messages and their associated message
+ number.
+
+ SSH_MSG_DISCONNECT 1
+ SSH_MSG_IGNORE 2
+ SSH_MSG_UNIMPLEMENTED 3
+ SSH_MSG_DEBUG 4
+ SSH_MSG_SERVICE_REQUEST 5
+ SSH_MSG_SERVICE_ACCEPT 6
+ SSH_MSG_KEXINIT 20
+ SSH_MSG_NEWKEYS 21
+
+ Note that numbers 30-49 are used for kex packets. Different kex
+ methods may reuse message numbers in this range.
+
+13. IANA Considerations
+
+ This document is part of a set. The IANA considerations for the SSH
+ protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and
+ this document, are detailed in [SSH-NUMBERS].
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 27]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+14. Security Considerations
+
+ This protocol provides a secure encrypted channel over an insecure
+ network. It performs server host authentication, key exchange,
+ encryption, and integrity protection. It also derives a unique
+ session ID that may be used by higher-level protocols.
+
+ Full security considerations for this protocol are provided in
+ [SSH-ARCH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 28]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+15. References
+
+15.1. Normative References
+
+ [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
+ (SSH) Protocol Architecture", RFC 4251, 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.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+ 1321, April 1992.
+
+ [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
+ Format Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
+ Specification version 1.3", RFC 1951, May 1996.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
+ 2144, May 1997.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", BCP 26, RFC
+ 2434, October 1998.
+
+ [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
+ Thayer, "OpenPGP Message Format", RFC 2440, November
+ 1998.
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 29]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, RFC 3066, January 2001.
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
+ (MODP) Diffie-Hellman groups for Internet Key Exchange
+ (IKE)", RFC 3526, May 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [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.
+
+ [FIPS-197] US National Institute of Standards and Technology,
+ "Advanced Encryption Standard (AES)", Federal
+ Information Processing Standards Publication 197,
+ November 2001.
+
+ [FIPS-46-3] US National Institute of Standards and Technology,
+ "Data Encryption Standard (DES)", Federal Information
+ Processing Standards Publication 46-3, October 1999.
+
+ [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
+ protocols algorithms and source in code in C", John
+ Wiley and Sons, New York, NY, 1996.
+
+ [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A
+ 128-Bit Block Cipher, 1st Edition", March 1999.
+
+15.2. Informative References
+
+ [RFC0894] Hornig, C., "Standard for the transmission of IP
+ datagrams over Ethernet networks", STD 41, RFC 894,
+ April 1984.
+
+ [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
+ 51, RFC 1661, July 1994.
+
+
+
+
+Ylonen & Lonvick Standards Track [Page 30]
+
+RFC 4253 SSH Transport Layer Protocol January 2006
+
+
+ [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
+ RFC 2412, November 1998.
+
+ [ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed
+ tarball ftp://ftp.funet.fi/pub/unix/security/
+ login/ssh/ssh-1.2.30.tar.gz, November 1995.
+
+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 31]
+
+RFC 4253 SSH Transport Layer Protocol 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 32]
+