Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
updates
- rfc-4250 — The Secure Shell (SSH) Protocol Assigned Numbers
- rfc-4253 — The Secure Shell (SSH) Transport Layer Protocol
- rfc-4432 — RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
- rfc-4462 — Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
Extracted elements (26)
curve25519 is efficient across a wide range of architectures and allows higher-performance implementations compared to NIST prime curves, which use patented parameters purchased by NIST. This efficiency advantage motivates its SHOULD status over the NIST curves' SHOULD recommendation.
diffie-hellman-group14-sha1 was retained as MAY rather than immediately disallowed to accommodate legacy small hardware IoT devices with insufficient compute and memory to use larger MODP groups before session timeout. The expectation is that it will be deprecated or disallowed in the future.
IFC (RSA) key exchanges do not provide Forward Secrecy, unlike FFC (Diffie-Hellman) and ECC methods. This makes RSA key exchange inherently less secure for long-term session protection despite meeting minimum bit-strength requirements.
The minimum security strength of 112 bits was chosen to match the weakest available symmetric cipher (3des-cbc). Implementers needing higher security may wish to use stronger algorithms, and the minimum may increase over time.
To avoid combinatorial explosion of key exchange names, newer key exchanges are generally restricted to *-sha256 and *-sha512 variants only. The exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which use SHA-384 to match the curve's 192-bit security level.
It is advisable to match the ECDSA host key algorithm and the ECDH key exchange algorithm to use the same elliptic curve for both, in order to maintain a consistent security strength throughout the SSH connection.
This document changes the requirement level of previously MTI methods: diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 both move from MUST to SHOULD NOT and MAY respectively. Implementations relying on these as guaranteed-present methods must be updated.
Both ext-info-c and ext-info-s extension negotiation methods (defined in RFC 8308) SHOULD be implemented to support future SSH capability extensions.
diffie-hellman-group-exchange-sha1 SHOULD NOT be used because it relies on SHA-1, which is being deprecated. diffie-hellman-group1-sha1 SHOULD NOT be implemented for the same reason.
MODP groups with a modulus size less than 2048 bits are weak and MUST NOT be used with diffie-hellman-group-exchange methods.
The curve25519-sha256 and gss-curve25519-sha256-* key exchange methods SHOULD be implemented, as they have multiple implementations and offer good performance and security characteristics.
The diffie-hellman-group14-sha1 key exchange MAY be implemented for legacy compatibility, but should be placed last in the negotiated key exchange preference list.
The diffie-hellman-group14-sha256 key exchange method MUST be implemented. This replaces diffie-hellman-group14-sha1 as the mandatory-to-implement (MTI) method, providing approximately 112 bits of security strength.
The diffie-hellman-group16-sha512 key exchange method SHOULD be implemented, providing approximately 152 bits of security using a 4096-bit MODP group with SHA-512.
The ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521 key exchange methods SHOULD be implemented. If implemented, the named curves SHOULD always be enabled unless specifically disabled by local security policy.
The gss-nistp256-sha256-*, gss-nistp384-sha384-*, and gss-nistp521-sha512-* key exchange methods SHOULD be implemented, mirroring the guidance for their non-GSS counterparts.
The rsa1024-sha1 key exchange method MUST NOT be implemented. It uses an RSA 1024-bit modulus with SHA-1, providing only approximately 80 bits of security, which does not meet minimum requirements.
ECC key exchange methods for SSH include ECDH using curve25519 (128-bit security), curve448 (224-bit security), nistp256 (128-bit), nistp384 (192-bit), and nistp521 (512-bit), as well as ECMQV. GSS-API variants prefixed with 'gss-' are defined for all these curves.
FFC Diffie-Hellman named groups range from group14 (2048-bit, ~112-bit security) through group18 (8192-bit, ~200-bit security). The minimum recommended group size is 2048 bits; group14 paired with SHA2-256 provides 112-bit security matching 3des-cbc.
SSH key exchange produces two values: a shared secret K and an exchange hash H. The hash H from the first key exchange becomes the session identifier — a unique connection identifier used in authentication — and is not changed even if keys are later re-exchanged.
The hash algorithm selected for a key exchange method is used both in the Key Derivation Function (KDF) and for integrity of the exchange response. The same hash function must be used for both purposes within a single key exchange method.
IANA updated the 'Key Exchange Method Names' registry in the SSH Protocol Parameters registry to add an 'OK to Implement' column with implementation guidance (MUST, SHOULD, MAY, SHOULD NOT, MUST NOT) as specified in Table 12 of Section 4. Entries annotated MUST NOT are disallowed; SHOULD NOT entries are deprecated.
112 bits of security strength is the minimum required for SSH key exchange methods in this document. Both SHA-1 (80 bits) and RSA 1024-bit (80 bits) fall below this minimum and should be deprecated and disallowed as quickly as possible.
MODP groups with a modulus size less than 2048 bits are too small for the symmetric ciphers used in SSH. If the diffie-hellman-group-exchange methods are used, the MODP group modulus must be at least 2048 bits.
SHA-1 provides only approximately 80 bits of collision resistance security. Transcript collision attacks (Bhargavan & Leurent, NDSS 2016) show an on-path attacker could tamper with SSH handshake fields to downgrade the negotiated ciphersuite, making SHA-1 use in key exchanges undesirable.
The rsa1024-sha1 and rsa2048-sha256 IFC key exchange methods do NOT provide Forward Secrecy, unlike FFC and ECC methods. This is a significant security distinction when selecting key exchange algorithms.