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