RFC 9142
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) 🎀
Okay bestie, here's the title block first, so you know who wrote this and what it touches 🦋
- Request for Comments: 9142
- Author: M. Baushke
- Date: January 2022
- Category: Standards Track
- ISSN: 2070-1721
- Publisher: Internet Engineering Task Force (IETF)
- Updates: 4250, 4253, 4432, 4462
- Obsoletes: nothing listed in the header
Abstract ✨
This doc refreshes the recommended list of key exchange methods for the Secure Shell (SSH) protocol so it keeps up with the need for stronger security 💪 It updates RFCs 4250, 4253, 4432, and 4462.
Status of This Memo 📜
Heads up, this is an Internet Standards Track document 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback on it lives at https://www.rfc-editor.org/info/rfc9142 🔗
Copyright Notice ⚖️
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🗺️
1. Overview and Rationale
1.1. Selecting an Appropriate Hashing Algorithm
1.2. Selecting an Appropriate Public Key Algorithm
1.2.1. Elliptic Curve Cryptography (ECC)
1.2.2. Finite Field Cryptography (FFC)
1.2.3. Integer Factorization Cryptography (IFC)
2. Requirements Language
3. Key Exchange Methods
3.1. Elliptic Curve Cryptography (ECC)
3.1.1. curve25519-sha256 and gss-curve25519-sha256-*
3.1.2. curve448-sha512 and gss-curve448-sha512-*
3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp*
3.2. Finite Field Cryptography (FFC)
3.2.1. FFC Diffie-Hellman Using Generated MODP Groups
3.2.2. FFC Diffie-Hellman Using Named MODP Groups
3.3. Integer Factorization Cryptography (IFC)
3.4. KDFs and Integrity Hashing
3.5. Secure Shell Extension Negotiation
4. Summary Guidance for Implementation of Key Exchange Method
Names
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Author's Address1. Overview and Rationale 🌸
Okay so SSH is basically the go-to protocol for secure communication on the Internet 🔐 In [RFC4253], SSH originally defined two Key Exchange (KEX) Method Names that MUST be implemented 🙌 But here's the tea: what was once considered secure is no longer considered secure 💀 So the point of this RFC is to recommend that some published key exchanges be deprecated or disallowed, and also to recommend some that SHOULD and one that MUST be adopted 🔥
So this doc updates [RFC4250], [RFC4253], [RFC4432], and [RFC4462] by shuffling the requirement level of a bunch of key exchange mechanisms. Things that were "MUST" can move to "SHOULD", "MAY", or "SHOULD NOT", and things that were "MAY" can move to "MUST", "SHOULD", "SHOULD NOT", or "MUST NOT" 🦋 A few recommendations stay the same, but they're listed anyway for completeness.
Section 7.2 of [RFC4253] spills the tea like this:
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.The strength of the public key exchange algorithm AND the hash used in the Key Derivation Function (KDF) both affect how safe the shared secret K is 🔑
The hash algorithms this doc covers are sha1, sha256, sha384, and sha512 🌈 Usually the hash name gets spelled right out at the end of the public key exchange name, but some are implicit and get defined in the RFC that defines that key exchange algorithm name.
Different RFCs spell and capitalize the hashing and encryption function names in different ways. For this doc, these are all equivalent: sha1, SHA1, and SHA-1; sha256, SHA256, SHA-256, and SHA2-256; sha384, SHA384, SHA-384, and SHA2-384; and sha512, SHA512, SHA-512, and SHA2-512.
For this doc, these are equivalent too: aes128, AES128, and AES-128; aes192, AES192, and AES-192; and aes256, AES256, and AES-256.
It is good to try to match the security strength of the public key exchange algorithm with the security strength of the symmetric cipher ⚖️
There are a lot of possible symmetric ciphers, each with multiple modes. The list in Table 1 is a representative sample of the ones that appear to be in most SSH implementations 🧁 The security strength estimates are generally available in [RFC4086] for triple-DES and AES, as well as Section 5.6.1.1 of [NIST.SP.800-57pt1r5].
+========================+=============================+
| Cipher Name (modes) | Estimated Security Strength |
+========================+=============================+
| 3des (cbc) | 112 bits |
+------------------------+-----------------------------+
| aes128 (cbc, ctr, gcm) | 128 bits |
+------------------------+-----------------------------+
| aes192 (cbc, ctr, gcm) | 192 bits |
+------------------------+-----------------------------+
| aes256 (cbc, ctr, gcm) | 256 bits |
+------------------------+-----------------------------+
Table 1: Symmetric Cipher Security StrengthsNext up, the subsections walk you through picking each piece of the key exchange 🧩
1.1. Selecting an Appropriate Hashing Algorithm 🔍
SHA-1 is getting deprecated for a bunch of reasons 💀
Attacks on SHA-1 have happened, and it's no longer strong enough for SSH security requirements 😭 So it's desirable to move away from it before the attacks get even more serious.
SHA-1 gives you roughly 80 bits of security strength 🔢 That means the shared key has at most 80 bits of security strength, which may not be enough for most users.
For key exchange purposes, the attacks on SHA-1 are collision attacks that usually rely on human help, rather than a pre-image attack 🕵️ SHA-1's second pre-image resistance is still at 160 bits, but SSH doesn't depend on second pre-image resistance. It depends on chosen-prefix collision resistance instead.
Transcript Collision attacks are written up in [TRANSCRIPTION] 📖 That paper shows an on-path attacker doesn't tamper with the Diffie-Hellman values and doesn't know the connection keys. But the attack could be used to tamper with both I_C and I_S (as defined in Section 7.3 of [RFC4253]), and it might potentially downgrade the negotiated ciphersuite to a weak cryptographic algorithm the attacker knows how to break 😱
These attacks are still super hard to pull off computationally 🧠 but it's desirable that any key exchange using SHA-1 gets phased out as soon as possible.
If you really need SHA-1 in a key exchange for compatibility, it's desirable to list it last in the preference list of key exchanges 📋
Using the SHA-2 family of hashes from [RFC6234] instead of SHA-1 is strongly advised 🙏
Now the SHA-2 family 👑 SHA2-256 has 128 bits, SHA2-384 has 192 bits, and SHA2-512 has 256 bits of security strength. It's suggested that the minimum secure hashing function for key exchange methods should be SHA2-256, with 128 bits of security strength. Other hashing functions may also have the same number of bits, but none are defined in any RFC for use in a KEX for SSH yet 🤷
To avoid a combinatorial explosion of key exchange names 🧨 newer ones are generally restricted to *-sha256 and *-sha512. The exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which are defined to use SHA2-384 (also known as SHA-384) from [RFC6234] as the hash algorithm.
Table 2 sums up hash security strength for collision resistance 📊 You may consult [NIST.SP.800-107r1] for more info on hash algorithm security strength.
+===========+=============================+
| Hash Name | Estimated Security Strength |
+===========+=============================+
| sha1 | 80 bits (before attacks) |
+-----------+-----------------------------+
| sha256 | 128 bits |
+-----------+-----------------------------+
| sha384 | 192 bits |
+-----------+-----------------------------+
| sha512 | 256 bits |
+-----------+-----------------------------+
Table 2: Hashing Function Security
Strengths1.2. Selecting an Appropriate Public Key Algorithm 🧮
SSH leans on mathematically hard problems for doing key exchanges:
- Elliptic Curve Cryptography (ECC) has families of curves for SSH key exchange methods 🌀 NIST prime curves with names, plus other curves, are available using an object identifier (OID) with Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 and curve448 key exchanges are used with ECDH via [RFC8731].
- Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) key exchange with "safe primes", either from a specified list found in [RFC3526] or generated dynamically via [RFC4419] as updated by [RFC8270].
- Integer Factorization Cryptography (IFC) using the RSA algorithm is provided for in [RFC4432].
It's desirable that the key exchange's security strength be picked to be comparable with the strength of the other parts of the SSH handshake 🤝 Attackers love going after the weakest link 🎯
It's desirable that a minimum of 112 bits of security strength be selected, to match the weakest symmetric cipher available (3des-cbc) 🍓 Based on implementer security needs, a stronger minimum may be desired.
Here's the trade-off 💅 The larger the Modular Exponentiation (MODP) group, the ECC curve size, or the RSA key length, the more computation power it takes to do the key exchange 💻
1.2.1. Elliptic Curve Cryptography (ECC) 🦋
okay bestie, ECC is giving main character energy 💅✨. Across all of the named curves, the minimum security strength is approximately 128 bits 🔥. The [RFC5656] key exchanges for the named curves use a hashing function with a matching security strength. The [RFC8731] key exchanges are a bit extra 💖: they use a hashing function with more security strength than the curve, so the minimum strength is just the security strength of the curve. Table 3 gives you a breakdown of only the ECC security strength by curve name 🌸. It does include the hashing algorithm used, though.
The curve25519 and curve488 security-level numbers are in [RFC7748] 🧚. The nistp256, nistp384, and nistp521 curves (the NIST prime curves) are provided in [RFC5656]. The hashing algorithm designated for each individual curve has approximately the same number of bits of security as the named curve 🎀.
+============+=============================+
| Curve Name | Estimated Security Strength |
+============+=============================+
| nistp256 | 128 bits |
+------------+-----------------------------+
| nistp384 | 192 bits |
+------------+-----------------------------+
| nistp521 | 512 bits |
+------------+-----------------------------+
| curve25519 | 128 bits |
+------------+-----------------------------+
| curve448 | 224 bits |
+------------+-----------------------------+
Table 3: ECC Security Strengths1.2.2. Finite Field Cryptography (FFC) 🌸
for FFC, it is recommended to use a modulus with a minimum of 2048 bits (approximately 112 bits of security strength) with a hash that has at least as many bits of security as the FFC does 🍓. The security strength of the FFC and the hash together will be the minimum of those two values. This is enough for a consistent security strength for the 3des-cbc cipher 💀. [RFC3526] Section 1 notes that the Advanced Encryption Standard (AES) cipher, which has more strength, needs stronger groups. For 128-bit AES, we need about a 3200-bit group. The 192- and 256-bit keys would need groups that are about 8000 and 15400 bits, respectively 😭. Table 4 shows the security strength of the MODP group. When paired with a hashing algorithm, the security strength will be the minimum of the two algorithms 🫶.
+==================+=============================+============+
| Prime Field Size | Estimated Security Strength | Example |
| | | MODP Group |
+==================+=============================+============+
| 2048-bit | 112 bits | group14 |
+------------------+-----------------------------+------------+
| 3072-bit | 128 bits | group15 |
+------------------+-----------------------------+------------+
| 4096-bit | 152 bits | group16 |
+------------------+-----------------------------+------------+
| 6144-bit | 176 bits | group17 |
+------------------+-----------------------------+------------+
| 8192-bit | 200 bits | group18 |
+------------------+-----------------------------+------------+
Table 4: FFC MODP Security StrengthsThe minimum MODP group is the 2048-bit MODP group14 🎀. When used with a SHA-1 hash, this group provides approximately 80 bits of security. When used with a SHA2-256 hash, this group provides approximately 112 bits of security. The 3des-cbc cipher itself provides at most 112 bits of security, so the group14-sha256 key exchanges are enough to protect all of the 3des-cbc key, for 112 bits of security 🦋.
A 3072-bit MODP group used with a SHA2-256 hash will provide approximately 128 bits of security ✨. That's a vibe when you're using a cipher like aes128 or chacha20-poly1305, since those provide approximately 128 bits of security too 💜.
The 8192-bit group18 MODP group used with sha512 provides approximately 200 bits of security, which is enough to protect aes192 with 192 bits of security 👑.
1.2.3. Integer Factorization Cryptography (IFC) 💖
The only IFC algorithm for key exchange is the RSA algorithm specified in [RFC4432] 🌈. RSA 1024-bit keys have approximately 80 bits of security strength, and RSA 2048-bit keys have approximately 112 bits of security strength. It's worth noting that the IFC types of key exchange do not provide Forward Secrecy, which both FFC and ECC do provide 🙈.
To match the 112 bits of security strength needed for 3des-cbc, an RSA 2048-bit key matches the security strength ✨. Using a SHA-2 family hash with RSA 2048-bit keys has enough security to match the 3des-cbc symmetric cipher 🔥. The rsa1024-sha1 key exchange has approximately 80 bits of security strength and is not desirable 💀.
Table 5 summarizes the security strengths of these key exchanges without including the hashing algorithm strength. You can find guidance for these strengths in Section 5.6.1.1 of [NIST.SP.800-57pt1r5] 🧚.
+=====================+=============================+
| Key Exchange Method | Estimated Security Strength |
+=====================+=============================+
| rsa1024-sha1 | 80 bits |
+---------------------+-----------------------------+
| rsa2048-sha256 | 112 bits |
+---------------------+-----------------------------+
Table 5: IFC Security Strengths2. Requirements Language 📜
okay so here's the deal about the key words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174] only when they appear in all capitals, just like here 🫶. Lowercase versions don't count, so no drama 🙈.
3. Key Exchange Methods 🎀
this document copies the style and conventions of [RFC4253] for showing how the use of data key exchange is indicated in SSH 💅.
This RFC also collects key exchange method names from a bunch of existing RFCs ([RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], [RFC8268], [RFC8308], [RFC8731], and [RFC8732]). It also gives a suggested suitability for implementation using MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT 🦋. Any method that isn't explicitly listed MAY be implemented ✨.
Section 7.2 of [RFC4253] defines how the shared secret K gets generated (it's really the output of the KDF) and the exchange key hash H 🧚. Each key exchange method uses a specified HASH function, which must be the same for both key exchange and Key Derivation. H is used for key exchange integrity across the SSH session, and it's computed only once 💜. The end of Section 7.2 of [RFC4253] also says:
This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.
So, you have to be careful that the hashing algorithm you pick is well chosen ("reasonable") for the key exchange algorithms you're using 🌸.
This document gives guidance on which key exchange algorithms should be considered for new or updated SSH implementations 💖.
Basically, key exchange methods that are considered "weak" are getting moved to either deprecated ("SHOULD NOT") or disallowed ("MUST NOT") 😭. Newer or stronger methods usually need more device resources than lots of admins and devs have, so they're allowed ("MAY") 🌈. (Eventually, some of these methods could be moved by consensus to "SHOULD" to boost interoperability and security 👑.) Methods that aren't "weak" and have implementation consensus are encouraged ("SHOULD") 🔥. There needs to be at least one consensus method promoted to mandatory to implement (MTI) status. This should help keep interoperability going even if one of the now disallowed MTI methods drops out 🫶.
For this document, 112 bits of security strength is the minimum 💅. Using SHA-1 or RSA 1024 bits, both at an approximate 80 bits of security, falls below this minimum. They should be deprecated and moved to disallowed as quickly as possible in configured SSH deployments 💀. It seems plausible that this minimum may be increased over time, so authors and administrators may wish to prepare for a switch to algorithms with more security strength ✨.
3.1. Elliptic Curve Cryptography (ECC) 🦋
The Elliptic Curve (EC) key exchange algorithms used with SSH include ECDH and EC Menezes-Qu-Vanstone (ECMQV) 💜.
The ECC curves defined for the key exchange algorithms above include curve25519, curve448, the NIST prime curves (nistp256, nistp384, and nistp521), and other curves allowed for by Section 6 of [RFC5656] 🧚. There are also key exchange mechanisms based on the Generic Security Service Application Program Interface (GSS-API) that use these curves and have a "gss-" prefix 🎀.
3.1.1. curve25519-sha256 and gss-curve25519-sha256-* 💜
Curve25519 is efficient on a wide range of architectures 🌈. Its properties allow higher-performance implementations than the patented elliptic curve parameters that NIST bought for the general public to use, as described in [RFC5656] 🔥. The corresponding key exchange methods use SHA2-256 (also known as SHA-256), which is defined in [RFC6234] 🫶. SHA2-256 is a reasonable hash for both the KDF and session integrity 🌸. It's reasonable for both gss and non-gss uses of curve25519 key exchange methods 💅.
These key exchange methods are described in [RFC8731] and [RFC8732], and they're similar to the IKEv2 key agreement described in [RFC8031] ✨. The curve25519-sha256 key exchange method has multiple implementations and SHOULD be implemented 👑. The gss-curve25519-sha256-* key exchange method SHOULD also be implemented, because it shares the same performance and security characteristics as curve25519-sha256 🦋.
Table 6 has a summary of the recommendations for curve25519-based key exchanges 🧚.
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| curve25519-sha256 | SHOULD |
+--------------------------+----------+
| gss-curve25519-sha256-* | SHOULD |
+--------------------------+----------+
Table 6: Curve25519 Implementation
Guidance3.1.2. curve448-sha512 and gss-curve448-sha512-* ✨
okay bestie, curve448 is the big sister of curve25519 💅 it gives more security strength, but it costs more compute and more bandwidth, so it's a trade-off 😭 the key exchange methods use SHA2-512 (also known as SHA-512), which is defined in [RFC6234]. SHA2-512 is a reasonable hash for the KDF and for session integrity, and it works for both gss and non-gss uses of curve448 key exchange methods 🫶 these are described in [RFC8731] and [RFC8732], and they're kinda similar to the IKEv2 key agreement in [RFC8031]. the curve448-sha512 key exchange method MAY be implemented. the gss-curve448-sha512-* key exchange method MAY also be implemented, because it has the same performance and security vibes as curve448-sha512 🌸
Table 7 is the cheat sheet for curve448 key exchanges:
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| curve448-sha512 | MAY |
+--------------------------+----------+
| gss-curve448-sha512-* | MAY |
+--------------------------+----------+
Table 7: Curve448 Implementation
Guidance3.1.3. ecdh-, ecmqv-sha2, and gss-nistp 🦋
the ecdh-sha2-* namespace lets you use the named NIST prime curves (nistp256, nistp384, and nistp521) and also other curves for ECDH key exchange 💖 at the time of writing, there are three named curves in this namespace that SHOULD be supported. they show up in Section 10.1 of [RFC5656]. if you implement them, the named curves SHOULD always be enabled, unless local security policy specifically disables them 🔥 Section 6.1 of [RFC5656] explains how to name other ECDH curves using OIDs. those other curves MAY be implemented 🧚
the GSS-API namespace with gss-nistp*-sha* mirrors the algorithms used by the ecdh-sha2-* names. they're described in [RFC8732] ✨
ECDH uses less bandwidth for key exchanges than FFC DH at a similar security strength, which is honestly iconic 👑
Table 8 lists algorithms as "SHOULD" where implementations may be more efficient or widely deployed. the items listed as "MAY" in Table 8 are potentially less efficient 🙈
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| ecdh-sha2-* | MAY |
+--------------------------+----------+
| ecdh-sha2-nistp256 | SHOULD |
+--------------------------+----------+
| gss-nistp256-sha256-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp384 | SHOULD |
+--------------------------+----------+
| gss-nistp384-sha384-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp521 | SHOULD |
+--------------------------+----------+
| gss-nistp521-sha512-* | SHOULD |
+--------------------------+----------+
| ecmqv-sha2 | MAY |
+--------------------------+----------+
Table 8: ECDH Implementation Guidanceit's advisable to match the Elliptic Curve Digital Signature Algorithm (ECDSA) and ECDH algorithm to use the same curve for both, so the connection keeps the same security strength 💜
3.2. Finite Field Cryptography (FFC) 🌈
3.2.1. FFC Diffie-Hellman Using Generated MODP Groups 🍓
[RFC4419] defines two key exchange methods that use a random pick from a set of pre-generated moduli: diffie-hellman-group-exchange-sha1 and diffie-hellman-group-exchange-sha256. per [RFC8270], implementations SHOULD use a MODP group whose modulus size is equal to or greater than 2048 bits. MODP groups under 2048 bits are weak, so they MUST NOT be used. no cap, that's a hard no 💀
diffie-hellman-group-exchange-sha1 SHOULD NOT be used. it uses SHA-1, which is being deprecated 😭
diffie-hellman-group-exchange-sha256 MAY be used. it uses SHA2-256, which is reasonable for MODP groups under 4096 bits 🫶
care should be taken when pre-generating the moduli P and generator G, so that the generator gives you a Q-ordered subgroup of P. otherwise, the parameter set may leak one bit of the shared secret 🙈
Table 9 gives you the guidance for these exchanges at a glance:
+======================================+============+
| Key Exchange Method Name | Guidance |
+======================================+============+
| diffie-hellman-group-exchange-sha1 | SHOULD NOT |
+--------------------------------------+------------+
| diffie-hellman-group-exchange-sha256 | MAY |
+--------------------------------------+------------+
Table 9: FFC Generated MODP Group Implementation
Guidance3.2.2. FFC Diffie-Hellman Using Named MODP Groups 💖
the diffie-hellman-group14-sha256 key exchange method is defined in [RFC8268]. it gives you about 112 bits of security strength, which matches the 3des-cbc symmetric cipher 🔥 it's a pretty simple move from SHA-1 to SHA-2. diffie-hellman-group14-sha1 and diffie-hellman-group14-sha256 share a MODP group and only differ in the hash function used for the KDF and integrity, so going from implementing diffie-hellman-group14-sha1 to implementing diffie-hellman-group14-sha256 is just as simple ✨ since diffie-hellman-group14-sha1 is being removed from mandatory to implement (MTI) status, the diffie-hellman-group14-sha256 method MUST be implemented. the rest of the FFC MODP groups from [RFC8268] have more security bits, and they're a good match for symmetric ciphers with a similar number of security bits 👑
Table 10 has the explicit guidance by name:
+===============================+==========+
| Key Exchange Method Name | Guidance |
+===============================+==========+
| diffie-hellman-group14-sha256 | MUST |
+-------------------------------+----------+
| gss-group14-sha256-* | SHOULD |
+-------------------------------+----------+
| diffie-hellman-group15-sha512 | MAY |
+-------------------------------+----------+
| gss-group15-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group16-sha512 | SHOULD |
+-------------------------------+----------+
| gss-group16-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group17-sha512 | MAY |
+-------------------------------+----------+
| gss-group17-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group18-sha512 | MAY |
+-------------------------------+----------+
| gss-group18-sha512-* | MAY |
+-------------------------------+----------+
Table 10: FFC Named Group Implementation
Guidance3.3. Integer Factorization Cryptography (IFC) 🦋
the rsa1024-sha1 key exchange method is defined in [RFC4432]. it uses an RSA 1024-bit modulus with a SHA-1 hash. this key exchange does NOT meet security requirements, so this method MUST NOT be implemented 💀
the rsa2048-sha256 key exchange method is defined in [RFC4432] too. it uses an RSA 2048-bit modulus with a SHA2-256 hash, and it meets 112-bit minimum security strength. this method MAY be implemented 🌸
Table 11 is the summary for IFC key exchanges:
+==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| rsa1024-sha1 | MUST NOT |
+--------------------------+----------+
| rsa2048-sha256 | MAY |
+--------------------------+----------+
Table 11: IFC Implementation Guidance3.4. KDFs and Integrity Hashing 🧚
the SHA-1 and SHA-2 families of hashing algorithms get combined with the FFC, ECC, and IFC algorithms to make up a key exchange method name ✨
the selected hash algorithm is used both in the KDF and for the integrity of the response, so it's doing double duty 🫶
all of the key exchange methods that use the SHA-1 hashing algorithm should be deprecated and phased out, because of the security concerns for SHA-1 documented in [RFC6194] 😭
unconditionally deprecating and/or disallowing SHA-1 everywhere will hasten the day it can simply be removed from implementations completely. leaving partially broken algorithms lying around is not a good look 💅
the SHA-2 family of hashes [RFC6234] is more secure than SHA-1. they've been standardized for use in SSH with many of the currently defined key exchanges 💖
please note that right now, there's no key exchange method for Secure Shell that uses the SHA-3 family of secure hashing functions or the Extendable-Output Functions [NIST.FIPS.202] 🙈
before the changes made by this document, diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie-hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit MODP group) is defined in Section 3 of [RFC3526]. the SSH group1 is defined in Section 8.1 of [RFC4253] as using the Oakley Group 2 provided in Section 6.2 of [RFC2409] (a 1024-bit MODP group). this group1 MODP group, with approximately 80 bits of security, is too weak to keep around 💀 but instead of jumping from MTI status straight to disallowed, lots of implementers suggested it should move to deprecated first and get disallowed later 🌈 the group14 MODP group that uses a SHA-1 hash for the KDF isn't as weak as group1. there are some legacy situations where it still gives administrators value, like small hardware Internet of Things (IOT) devices that don't have enough compute and memory to use larger MODP groups before the session times out 🧸 there was consensus to move from MTI to a requirement status that allows continued use, with the expectation that it'd be deprecated or disallowed in the future. so it's considered reasonable to keep the diffie-hellman-group14-sha1 exchange for interoperability with legacy implementations. the diffie-hellman-group14-sha1 key exchange MAY be implemented, but should be put at the end of the list of negotiated key exchanges 🦋
the diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1 SHOULD NOT be implemented. the gss-group1-sha1-, gss-group14-sha1-, and gss-gex-sha1-* key exchanges are already specified as SHOULD NOT be implemented by [RFC8732] 🫶
3.5. Secure Shell Extension Negotiation 🎀
Okay so 3.5 is all about extensions and it's giving flexibility 🦋 There are two methods, ext-info-c and ext-info-s, defined in [RFC8308]. They give SSH a way to support other SSH negotiations, and being able to extend functionality is sooo desirable 💖 Both ext-info-c and ext-info-s SHOULD be implemented ✨
4. Summary Guidance for Implementation of Key Exchange Method Names ✨
This is the cheat sheet, bestie 📋 Table 12 lists the existing key exchange method names alphabetically. The Implement column holds the current recommendations of this RFC, so look there first 💅
+=======================+============+================+===========+
| Key Exchange Method | Reference | Previous | RFC 9142 |
| Name | | Recommendation | Implement |
+=======================+============+================+===========+
| curve25519-sha256 | [RFC8731] | none | SHOULD |
+-----------------------+------------+----------------+-----------+
| curve448-sha512 | [RFC8731] | none | MAY |
+-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | [RFC4419], | none | SHOULD |
| exchange-sha1 | [RFC8270] | | NOT |
+-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | [RFC4419], | none | MAY |
| exchange-sha256 | [RFC8270] | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC4253] | MUST | SHOULD |
| group1-sha1 | | | NOT |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC4253] | MUST | MAY |
| group14-sha1 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MUST |
| group14-sha256 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group15-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | SHOULD |
| group16-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group17-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| diffie-hellman- | [RFC8268] | none | MAY |
| group18-sha512 | | | |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-* | [RFC5656] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp256 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp384 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp521 | [RFC5656] | MUST | SHOULD |
+-----------------------+------------+----------------+-----------+
| ecmqv-sha2 | [RFC5656] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| ext-info-c | [RFC8308] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| ext-info-s | [RFC8308] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss- | [RFC4462] | reserved | reserved |
+-----------------------+------------+----------------+-----------+
| gss- | [RFC8732] | SHOULD | SHOULD |
| curve25519-sha256-* | | | |
+-----------------------+------------+----------------+-----------+
| gss-curve448-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-gex-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group1-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group14-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | [RFC8732] | | NOT |
+-----------------------+------------+----------------+-----------+
| gss-group14-sha256-* | [RFC8732] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-group15-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group16-sha512-* | [RFC8732] | SHOULD | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group17-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-group18-sha512-* | [RFC8732] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
| gss-nistp256-sha256-* | [RFC8732] | SHOULD | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-nistp384-sha384-* | [RFC8732] | MAY | SHOULD |
+-----------------------+------------+----------------+-----------+
| gss-nistp521-sha512-* | [RFC8732] | MAY | SHOULD |
+-----------------------+------------+----------------+-----------+
| rsa1024-sha1 | [RFC4432] | MAY | MUST NOT |
+-----------------------+------------+----------------+-----------+
| rsa2048-sha256 | [RFC4432] | MAY | MAY |
+-----------------------+------------+----------------+-----------+
Table 12: IANA Guidance for Implementation of Key Exchange
Method NamesThe full set of official [IANA-SSH] "Key Exchange Method Names" not otherwise mentioned in this document MAY be implemented 🌈
5. Security Considerations 💀
Okay, this part is serious, so read it carefully 🙈 This SSH protocol gives you a secure encrypted channel over an insecure network. It does server host authentication, key exchange, encryption, and integrity checks. It also derives a unique session ID that higher-level protocols may use. The key exchange itself generates a shared secret and uses the hash function for both the KDF and integrity.
Full security considerations for this protocol are in [RFC4251], and they still apply, no cap 🔐 On top of that, the security considerations in [RFC4432] apply too. Also, Forward Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key exchanges, so be careful with those 😭
It is desirable to deprecate or disallow key exchange methods that are considered weak, so they aren't still actively in operation when they get broken 💔
A key exchange method is considered weak when its security strength is not enough to match the symmetric cipher, or when the algorithm has been broken.
The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too small for the symmetric ciphers used in SSH. Not it, bestie 🙅♀️
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-sha256 or diffie-hellman-group-exchange-sha1 key exchange method is used, the modulus size of the MODP group used needs to be at least 2048 bits 🎀
At this time, the rsa1024-sha1 key exchange is too small for the symmetric ciphers used in SSH 💀
The use of SHA-1 with any key exchange may not be completely broken yet, but it is time to retire all uses of this algorithm as soon as possible 🏃♀️
The diffie-hellman-group14-sha1 algorithm is not yet completely deprecated. This is to give a practical transition from the MTI algorithms to a new one. However, it would be best to use it only as a last resort in key exchange negotiations. All key exchange methods using the SHA-1 hash are to be considered deprecated 🥀
6. IANA Considerations 📝
Here's what IANA did, bestie 🫶 IANA added a new column to the "Key Exchange Method Names" registry [IANA-SSH] with the heading "OK to Implement". They annotated entries there with the implementation guidance from Section 4, "Summary Guidance for Implementation of Key Exchange Method Names", in this document. IANA also added entries for ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521. They added references to [RFC4462] and [RFC8732] for gss-gex-sha1-*, gss-group1-sha1-*, gss-group14-sha1-*, diffie-hellman-group-exchange-sha1, and diffie-hellman-group-exchange-sha256. A summary is in Table 12 in Section 4. IANA also included this document as an additional registry reference for the suggested implementation guidance in Section 4 of this document, and added this note:
| OK to Implement guidance entries for registrations that pre-date
| [RFC9142] are found in Table 12 in Section 4 of [RFC9142].Registry entries annotated with "MUST NOT" are considered disallowed. Registry entries annotated with "SHOULD NOT" are deprecated and may be disallowed in the future 🚫
7. References 📚
7.1. Normative References ✨
okay bestie, these are the docs this spec literally can't function without 📚 the BCP 14 key words stuff, the SSH trio, the MODP group ones, and the newer curve stuff 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
<https://www.rfc-editor.org/info/rfc8268>.
[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell
Minimum Recommended Diffie-Hellman Modulus Size to 2048
Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,
<https://www.rfc-editor.org/info/rfc8270>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>.7.2. Informative References 🦋
these ones aren't strictly required to read the spec, but they're the background drama, the crypto guidance, and the receipts for where everything came from 🌸 iykyk
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
<https://www.iana.org/assignments/ssh-parameters/>.
[NIST.FIPS.202]
National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", FIPS PUB 202, DOI 10.6028/NIST.FIPS.202,
August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
[NIST.SP.800-107r1]
Dang, Q., "Recommendation for applications using approved
hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August
2012, <https://doi.org/10.6028/NIST.SP.800-107r1>.
[NIST.SP.800-57pt1r5]
Barker, E., "Recommendation for Key Management: Part 1 -
General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003,
<https://www.rfc-editor.org/info/rfc3526>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
<https://www.rfc-editor.org/info/rfc4419>.
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
March 2006, <https://www.rfc-editor.org/info/rfc4432>.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May
2006, <https://www.rfc-editor.org/info/rfc4462>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
Internet Key Exchange Protocol Version 2 (IKEv2) Key
Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
<https://www.rfc-editor.org/info/rfc8031>.
[RFC8732] Sorce, S. and H. Kario, "Generic Security Service
Application Program Interface (GSS-API) Key Exchange with
SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
<https://www.rfc-editor.org/info/rfc8732>.
[TRANSCRIPTION]
Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security Symposium (NDSS),
DOI 10.14722/ndss.2016.23418, February 2016,
<https://doi.org/10.14722/ndss.2016.23418>.Acknowledgements 🫶
huge thank you to everyone who reviewed and commented, you absolutely carried ✨ Denis Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, Tero Kivinen, and Travis Finkenauer 💜
and the people who wrote actual working code so these groups could interoperate in the wild 💻 Darren Tucker for OpenSSH and Matt Johnston for Dropbear 🦋 plus Iwamoto Kouichi again for the info about RLogin, Tera Term (ttssh), and Poderosa, who also adopted the new Diffie-Hellman groups based on this document 🌈
Author's Address 🎀
Mark D. Baushke
Email: mbaushke.ietf@gmail.com
📦 where this page comes from
- ietf: rfc9142 2022-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms