Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)

mbaushke.ietf@gmail.com

Security CURDLE 3DES AES Advanced Encryption Standard Curve25519 Curve448 DH Diffie-Hellman Digital Encryption Standard ECC ECDH Elliptic Curve Cryptography Elliptic Curve Diffie-Hellman FFC Finite Field Cryptography IFC Integer Factorization Cryptography MODP MTI Mandatory to Implement Modular Exponential Modular Exponentiation Public Key Exchange RSA SHA-2 Secure Shell Key Exchange Secure Shell Security Strength Triple-DES sha1 sha256 sha384 sha512 SHA-1 This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462.

Status of This Memo 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

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 () 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

. Overview and Rationale
- . Selecting an Appropriate Hashing Algorithm
- . Selecting an Appropriate Public Key Algorithm
  - . Elliptic Curve Cryptography (ECC)
  - . Finite Field Cryptography (FFC)
  - . Integer Factorization Cryptography (IFC)
. Requirements Language
. Key Exchange Methods
- . Elliptic Curve Cryptography (ECC)
  - . curve25519-sha256 and gss-curve25519-sha256-*
  - . curve448-sha512 and gss-curve448-sha512-*
  - . ecdh-*, ecmqv-sha2, and gss-nistp*
- . Finite Field Cryptography (FFC)
  - . FFC Diffie-Hellman Using Generated MODP Groups
  - . FFC Diffie-Hellman Using Named MODP Groups
- . Integer Factorization Cryptography (IFC)
- . KDFs and Integrity Hashing
- . Secure Shell Extension Negotiation
. Summary Guidance for Implementation of Key Exchange Method Names
. Security Considerations
. IANA Considerations
. References
- . Normative References
- . Informative References
Acknowledgements
Author's Address

Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. In , SSH originally defined two Key Exchange (KEX) Method Names that MUST be implemented. Over time, what was once considered secure is no longer considered secure. The purpose of this RFC is to recommend that some published key exchanges be deprecated or disallowed as well as to recommend some that SHOULD and one that MUST be adopted. This document updates , , , and by changing the requirement level ("MUST" moving to "SHOULD", "MAY", or "SHOULD NOT", and "MAY" moving to "MUST", "SHOULD", "SHOULD NOT", or "MUST NOT") of various key exchange mechanisms. Some recommendations will be unchanged but are included for completeness. says the following:

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 security strength of the public key exchange algorithm and the hash used in the Key Derivation Function (KDF) both impact the security of the shared secret K being used. The hashing algorithms used by key exchange methods described in this document are: sha1, sha256, sha384, and sha512. In many cases, the hash name is explicitly appended to the public key exchange algorithm name. However, some of them are implicit and defined in the RFC that defines the key exchange algorithm name. Various RFCs use different spellings and capitalizations for the hashing function and encryption function names. For the purpose of this document, the following are equivalent names: 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 the purpose of this document, the following are equivalent: aes128, AES128, 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 many possible symmetric ciphers available with multiple modes. The list in is intended as a representative sample of those that appear to be present in most SSH implementations. The security strength estimates are generally available in for triple-DES and AES, as well as Section 5.6.1.1 of . Symmetric Cipher Security Strengths

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

The following subsections describe how to select each component of the key exchange.

Selecting an Appropriate Hashing Algorithm The SHA-1 hash is in the process of being deprecated for many reasons. There have been attacks against SHA-1, and it is no longer strong enough for SSH security requirements. Therefore, it is desirable to move away from using it before attacks become more serious. The SHA-1 hash provides for approximately 80 bits of security strength. This means that the shared key being used has at most 80 bits of security strength, which may not be sufficient for most users. For purposes of key exchange methods, attacks against SHA-1 are collision attacks that usually rely on human help rather than a pre-image attack. The SHA-1 hash resistance against a second pre-image is still at 160 bits, but SSH does not depend on second pre-image resistance but rather on chosen-prefix collision resistance. Transcript Collision attacks are documented in . This paper shows that an on-path attacker does not tamper with the Diffie-Hellman values and does not know the connection keys. The attack could be used to tamper with both I_C and I_S (as defined in ) and might potentially be able to downgrade the negotiated ciphersuite to a weak cryptographic algorithm that the attacker knows how to break. These attacks are still computationally very difficult to perform, but it is desirable that any key exchange using SHA-1 be phased out as soon as possible. If there is a need for using SHA-1 in a key exchange for compatibility, it would be desirable to list it last in the preference list of key exchanges. Use of the SHA-2 family of hashes found in rather than the SHA-1 hash is strongly advised. When it comes to the SHA-2 family of secure hashing functions, SHA2-256 has 128 bits of security strength; SHA2-384 has 192 bits of security strength; and SHA2-512 has 256 bits of security strength. It is suggested that the minimum secure hashing function used 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 of security strength, but none are as yet defined in any RFC for use in a KEX for SSH. To avoid combinatorial explosion of key exchange names, newer key exchanges 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) defined in for the hash algorithm. provides a summary of security strength for hashing functions for collision resistance. You may consult for more information on hash algorithm security strength. Hashing Function Security Strengths

Hash Name	Estimated Security Strength
sha1	80 bits (before attacks)
sha256	128 bits
sha384	192 bits
sha512	256 bits

Selecting an Appropriate Public Key Algorithm SSH uses mathematically hard problems for doing key exchanges:

Elliptic Curve Cryptography (ECC) has families of curves for key exchange methods for SSH. NIST prime curves with names and other curves are available using an object identifier (OID) with Elliptic Curve Diffie-Hellman (ECDH) via . Curve25519 and curve448 key exchanges are used with ECDH via .
Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) key exchange with "safe primes" either from a specified list found in or generated dynamically via as updated by .
Integer Factorization Cryptography (IFC) using the RSA algorithm is provided for in .

It is desirable that the security strength of the key exchange be chosen to be comparable with the security strength of the other elements of the SSH handshake. Attackers can target the weakest element of the SSH handshake. It is desirable that a minimum of 112 bits of security strength be selected to match the weakest of the symmetric cipher (3des-cbc) available. Based on implementer security needs, a stronger minimum may be desired. The larger the Modular Exponentiation (MODP) group, the ECC curve size, or the RSA key length, the more computation power will be required to perform the key exchange.

Elliptic Curve Cryptography (ECC) For ECC, across all of the named curves, the minimum security strength is approximately 128 bits. The key exchanges for the named curves use a hashing function with a matching security strength. Likewise, the key exchanges use a hashing function that has more security strength than the curves. The minimum strength will be the security strength of the curve. contains a breakdown of just the ECC security strength by curve name; it does include the hashing algorithm used. The curve25519 and curve488 security-level numbers are in . The nistp256, nistp384, and nistp521 (NIST prime curves) are provided in . The hashing algorithm designated for use with the individual curves have approximately the same number of bits of security as the named curve. ECC Security Strengths

Curve Name	Estimated Security Strength
nistp256	128 bits
nistp384	192 bits
nistp521	512 bits
curve25519	128 bits
curve448	224 bits

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. The security strength of the FFC and the hash together will be the minimum of those two values. This is sufficient to provide a consistent security strength for the 3des-cbc cipher. notes that the Advanced Encryption Standard (AES) cipher, which has more strength, needs stronger groups. For the 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. provides the security strength of the MODP group. When paired with a hashing algorithm, the security strength will be the minimum of the two algorithms. FFC MODP Security Strengths

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

The 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 is sufficient to keep all of the 3des-cbc key, for 112 bits of security. A 3072-bit MODP group when used with a SHA2-256 hash will provide approximately 128 bits of security. This is desirable when using a cipher such as aes128 or chacha20-poly1305 that provides approximately 128 bits of security. The 8192-bit group18 MODP group when used with sha512 provides approximately 200 bits of security, which is sufficient to protect aes192 with 192 bits of security.

Integer Factorization Cryptography (IFC) The only IFC algorithm for key exchange is the RSA algorithm specified in . RSA 1024-bit keys have approximately 80 bits of security strength. RSA 2048-bit keys have approximately 112 bits of security strength. It is worth noting that the IFC types of key exchange do not provide Forward Secrecy, which both FFC and ECC do provide. In order to match the 112 bits of security strength needed for 3des-cbc, an RSA 2048-bit key matches the security strength. The use of a SHA-2 family hash with RSA 2048-bit keys has sufficient security to match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange has approximately 80 bits of security strength and is not desirable. summarizes the security strengths of these key exchanges without including the hashing algorithm strength. Guidance for these strengths can be found in Section 5.6.1.1 of . IFC Security Strengths

Key Exchange Method	Estimated Security Strength
rsa1024-sha1	80 bits
rsa2048-sha256	112 bits

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Key Exchange Methods This document adopts the style and conventions of in specifying how the use of data key exchange is indicated in SSH. This RFC also collects key exchange method names in various existing RFCs (, , , , , , , , and ) and provides a suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT. Any method not explicitly listed MAY be implemented. defines the generation of a shared secret K (really the output of the KDF) and an 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 as it is computed only once. It is noted at the end of that:

This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH.

So, care must be taken that the hashing algorithm used is well chosen ("reasonable") for the key exchange algorithms being used. This document provides guidance as to what key exchange algorithms are to be considered for new or updated SSH implementations. In general, key exchange methods that are considered "weak" are being moved to either deprecated ("SHOULD NOT") or disallowed ("MUST NOT"). Methods that are newer or considered to be stronger usually require more device resources than many administrators and/or developers need are to be allowed ("MAY"). (Eventually, some of these methods could be moved by consensus to "SHOULD" to increase interoperability and security.) Methods that are not "weak" and have implementation consensus are encouraged ("SHOULD"). There needs to be at least one consensus method promoted to a status of mandatory to implement (MTI). This should help to provide continued interoperability even with the loss of one of the now disallowed MTI methods. For this document, 112 bits of security strength is the minimum. Use of either or both of SHA-1 and RSA 1024 bits at an approximate 80 bits of security fall below this minimum and should be deprecated and moved to disallowed as quickly as possible in configured deployments of SSH. It seems plausible that this minimum may be increased over time, so authors and administrators may wish to prepare for a switch to algorithms that provide more security strength.

Elliptic Curve Cryptography (ECC) The Elliptic Curve (EC) key exchange algorithms used with SSH include the ECDH and EC Menezes-Qu-Vanstone (ECMQV). The ECC curves defined for the key exchange algorithms above include the following: curve25519, curve448, the NIST prime curves (nistp256, nistp384, and nistp521), as well as other curves allowed for by . There are key exchange mechanisms based on the Generic Security Service Application Program Interface (GSS-API) that use these curves as well that have a "gss-" prefix.

curve25519-sha256 and gss-curve25519-sha256-* Curve25519 is efficient on a wide range of architectures with properties that allow higher-performance implementations compared to the patented elliptic curve parameters purchased by NIST for the general public to use as described in . The corresponding key exchange methods use SHA2-256 (also known as SHA-256) defined in . SHA2-256 is a reasonable hash for use in both the KDF and session integrity. It is reasonable for both gss and non-gss uses of curve25519 key exchange methods. These key exchange methods are described in and and are similar to the IKEv2 key agreement described in . 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. contains a summary of the recommendations for curve25519-based key exchanges. Curve25519 Implementation Guidance

Key Exchange Method Name	Guidance
curve25519-sha256	SHOULD
gss-curve25519-sha256-*	SHOULD

curve448-sha512 and gss-curve448-sha512-* Curve448 provides more security strength than curve25519 at a higher computational and bandwidth cost. The corresponding key exchange methods use SHA2-512 (also known as SHA-512) defined in . SHA2-512 is a reasonable hash for use in both the KDF and session integrity. It is reasonable for both gss and non-gss uses of curve448 key exchange methods. These key exchange methods are described in and and are similar to the IKEv2 key agreement described in . The curve448-sha512 key exchange method MAY be implemented. The gss-curve448-sha512-* key exchange method MAY also be implemented because it shares the same performance and security characteristics as curve448-sha512. contains a summary of the recommendations for curve448-based key exchanges. Curve448 Implementation Guidance

Key Exchange Method Name	Guidance
curve448-sha512	MAY
gss-curve448-sha512-*	MAY

ecdh-*, ecmqv-sha2, and gss-nistp* The ecdh-sha2-* namespace allows for both the named NIST prime curves (nistp256, nistp384, and nistp521) as well as other curves to be defined for the ECDH key exchange. At the time of this writing, there are three named curves in this namespace that SHOULD be supported. They appear in . If implemented, the named curves SHOULD always be enabled unless specifically disabled by local security policy. In , the method to name other ECDH curves using OIDs is specified. These other curves MAY be implemented. The GSS-API namespace with gss-nistp*-sha* mirrors the algorithms used by ecdh-sha2-* names. They are described in . ECDH reduces bandwidth of key exchanges compared to FFC DH at a similar security strength. lists algorithms as "SHOULD" where implementations may be more efficient or widely deployed. The items listed as "MAY" in are potentially less efficient. ECDH Implementation Guidance

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

It is advisable to match the Elliptic Curve Digital Signature Algorithm (ECDSA) and ECDH algorithm to use the same curve for both to maintain the same security strength in the connection.

Finite Field Cryptography (FFC)

FFC Diffie-Hellman Using Generated MODP Groups defines two key exchange methods that use a random selection from a set of pre-generated moduli for key exchange: the diffie-hellman-group-exchange-sha1 method and the diffie-hellman-group-exchange-sha256 method. Per , implementations SHOULD use a MODP group whose modulus size is equal to or greater than 2048 bits. MODP groups with a modulus size less than 2048 bits are weak and MUST NOT be used. The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT be used. This method uses SHA-1, which is being deprecated. The diffie-hellman-group-exchange-sha256 key exchange method MAY be used. This method uses SHA2-256, which is reasonable for MODP groups less than 4096 bits. Care should be taken in the pre-generation of the moduli P and generator G such that the generator provides a Q-ordered subgroup of P. Otherwise, the parameter set may leak one bit of the shared secret. provides a summary of the guidance for these exchanges. FFC Generated MODP Group Implementation Guidance

Key Exchange Method Name	Guidance
diffie-hellman-group-exchange-sha1	SHOULD NOT
diffie-hellman-group-exchange-sha256	MAY

FFC Diffie-Hellman Using Named MODP Groups The diffie-hellman-group14-sha256 key exchange method is defined in and represents a key exchange that has approximately 112 bits of security strength that matches 3des-cbc symmetric cipher security strength. It is a reasonably simple transition from SHA-1 to SHA-2, and given that 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, it is a correspondingly simple transition from implementing diffie-hellman-group14-sha1 to implementing diffie-hellman-group14-sha256. Given that 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 group from have a larger number of security bits and are suitable for symmetric ciphers that also have a similar number of security bits. provides explicit guidance by name. FFC Named Group Implementation Guidance

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

Integer Factorization Cryptography (IFC) The rsa1024-sha1 key exchange method is defined in and uses an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does NOT meet security requirements. This method MUST NOT be implemented. The rsa2048-sha256 key exchange method is defined in and uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange meets 112-bit minimum security strength. This method MAY be implemented. provides a summary of the guidance for IFC key exchanges. IFC Implementation Guidance

Key Exchange Method Name	Guidance
rsa1024-sha1	MUST NOT
rsa2048-sha256	MAY

KDFs and Integrity Hashing The SHA-1 and SHA-2 family of hashing algorithms are combined with the FFC, ECC, and IFC algorithms to comprise a key exchange method name. The selected hash algorithm is used both in the KDF as well as for the integrity of the response. All of the key exchange methods using the SHA-1 hashing algorithm should be deprecated and phased out due to security concerns for SHA-1, as documented in . Unconditionally deprecating and/or disallowing SHA-1 everywhere will hasten the day when it may be simply removed from implementations completely. Leaving partially broken algorithms lying around is not a good thing to do. The SHA-2 family of hashes is more secure than SHA-1. They have been standardized for use in SSH with many of the currently defined key exchanges. Please note that at the present time, there is no key exchange method for Secure Shell that uses the SHA-3 family of secure hashing functions or the Extendable-Output Functions . Prior to 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 . The SSH group1 is defined in as using the Oakley Group 2 provided in (a 1024-bit MODP group). This group1 MODP group with approximately 80 bits of security is too weak to be retained. However, rather than jumping from the MTI status to making it disallowed, many implementers suggested that it should transition to deprecated first and be disallowed at a later time. The group14 MODP group using a SHA-1 hash for the KDF is not as weak as the group1 MODP group. There are some legacy situations where it will still provide administrators with value, such as small hardware Internet of Things (IOT) devices that have insufficient compute and memory resources to use larger MODP groups before a timeout of the session occurs. There was consensus to transition from MTI to a requirement status that provides for continued use with the expectation that it would be deprecated or disallowed in the future. Therefore, it is considered reasonable to retain 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 .

Secure Shell Extension Negotiation There are two methods, ext-info-c and ext-info-s, defined in . They provide a mechanism to support other Secure Shell negotiations. Being able to extend functionality is desirable. Both ext-info-c and ext-info-s SHOULD be implemented.

Summary Guidance for Implementation of Key Exchange Method Names provides the existing key exchange method names listed alphabetically. The Implement column contains the current recommendations of this RFC. IANA Guidance for Implementation of Key Exchange Method Names

Key Exchange Method Name	Reference	Previous Recommendation	RFC 9142 Implement
curve25519-sha256		none	SHOULD
curve448-sha512		none	MAY
diffie-hellman-group-exchange-sha1	,	none	SHOULD NOT
diffie-hellman-group-exchange-sha256	,	none	MAY
diffie-hellman-group1-sha1		MUST	SHOULD NOT
diffie-hellman-group14-sha1		MUST	MAY
diffie-hellman-group14-sha256		none	MUST
diffie-hellman-group15-sha512		none	MAY
diffie-hellman-group16-sha512		none	SHOULD
diffie-hellman-group17-sha512		none	MAY
diffie-hellman-group18-sha512		none	MAY
ecdh-sha2-*		MAY	MAY
ecdh-sha2-nistp256		MUST	SHOULD
ecdh-sha2-nistp384		MUST	SHOULD
ecdh-sha2-nistp521		MUST	SHOULD
ecmqv-sha2		MAY	MAY
ext-info-c		SHOULD	SHOULD
ext-info-s		SHOULD	SHOULD
gss-		reserved	reserved
gss-curve25519-sha256-*		SHOULD	SHOULD
gss-curve448-sha512-*		MAY	MAY
gss-gex-sha1-*	,	SHOULD NOT	SHOULD NOT
gss-group1-sha1-*	,	SHOULD NOT	SHOULD NOT
gss-group14-sha1-*	,	SHOULD NOT	SHOULD NOT
gss-group14-sha256-*		SHOULD	SHOULD
gss-group15-sha512-*		MAY	MAY
gss-group16-sha512-*		SHOULD	MAY
gss-group17-sha512-*		MAY	MAY
gss-group18-sha512-*		MAY	MAY
gss-nistp256-sha256-*		SHOULD	SHOULD
gss-nistp384-sha384-*		MAY	SHOULD
gss-nistp521-sha512-*		MAY	SHOULD
rsa1024-sha1		MAY	MUST NOT
rsa2048-sha256		MAY	MAY

The full set of official "Key Exchange Method Names" not otherwise mentioned in this document MAY be implemented.

Security Considerations This SSH protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity checks. It also derives a unique session ID that may be used by higher-level protocols. 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 provided in and continue to apply. In addition, the security considerations provided in apply. Note that Forward Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key exchanges. It is desirable to deprecate or disallow key exchange methods that are considered weak so they are not still actively in operation when they are broken. A key exchange method is considered weak when the security strength is insufficient to match the symmetric cipher or 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. 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 for use with any key exchange may not yet be completely broken, 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 provide a practical transition from the MTI algorithms to a new one. However, it would be best to only be used as a last resort in key exchange negotiations. All key exchange methods using the SHA-1 hash are to be considered as deprecated.

IANA Considerations IANA has added a new column to the "Key Exchange Method Names" registry with the heading "OK to Implement" and annotated entries therein with the implementation guidance provided in , "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, and added references to and for gss-gex-sha1-*, gss-group1-sha1-*, gss-group14-sha1-*, diffie-hellman-group-exchange-sha1, and diffie-hellman-group-exchange-sha256. A summary may be found in in . IANA has also included this document as an additional registry reference for the suggested implementation guidance provided in of this document and added a note indicating the following:

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.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Secure Shell (SSH) Protocol Assigned Numbers This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK] The Secure Shell (SSH) Transport Layer Protocol 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. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key. Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits. Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updates RFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size. Extension Negotiation in the Secure Shell (SSH) Protocol This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. Informative References Secure Shell (SSH) Protocol Parameters Internet Assigned Numbers Authority SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions National Institute of Standards and Technology FIPS PUB 202 Recommendation for applications using approved hash algorithms National Institute of Standards and Technology (NIST) Recommendation for Key Management: Part 1 - General National Institute of Standards and Technology (NIST) The Internet Key Exchange (IKE) This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK] Randomness Requirements for Security Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Secure Shell (SSH) Protocol Architecture The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK] Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol This memo describes a new key exchange method for the Secure Shell (SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time. [STANDARDS-TRACK] RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. [STANDARDS-TRACK] Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange. [STANDARDS-TRACK] Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK] Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms This document includes security considerations for the SHA-0 and SHA-1 message digest algorithm. This document is not an Internet Standards Track specification; it is published for informational purposes. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Federal Information Processing Standard, FIPS Elliptic Curves for Security This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version 2 (IKEv2). Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges. Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH Network and Distributed System Security Symposium (NDSS)

Acknowledgements Thanks to the following people for review and comments: , , , , , , , , , , , and . Thanks to the following people for code to implement interoperable exchanges using some of these groups as found in this document: for OpenSSH and for Dropbear. And thanks to for information about RLogin, Tera Term (ttssh), and Poderosa implementations also adopting new Diffie-Hellman groups based on this document.

Author's Address

mbaushke.ietf@gmail.com