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