doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc4253.txt b/doc/rfc/rfc4253.txt
new file mode 100644
index 0000000..20e296e
--- /dev/null
+++ b/doc/rfc/rfc4253.txt
@@ -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]
+