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

Secure Shell (SSH) is a common protocol for secure communication on the Internet. In , SSH originally defined two Key Exchange 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 as well as recommending some that SHOULD and one that MUST be adopted. This document updates . This document adds recommendations for adoption of Key Exchange Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be implemented. New key exchange methods will use the SHA-2 family of hashes and are drawn from these ssh-curves from and new-modp from the and gss-keyex . [TO BE REMOVED: Please send comments on this draft to curdle@ietf.org.]

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This memo 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, SHOULD NOT, and MUST NOT. Any method not explicitly listed, MAY be implemented. This document is intended to provide guidance as to what Key Exchange Algorithms are to be considered for new or updated SSH implementations. This document will be superseded when one or more of the listed algorithms are considered too weak to continue to use securely, in which case they will likely be downgraded to SHOULD NOT or MUST NOT. Or, when newer methods have been analyzed and found to be secure with wide enough adoption to upgrade their recommendation from MAY to SHOULD or MUST.

The Curve25519 provides strong security and is efficient on a wide range of architectures with properties that allow better implementation properties compared to traditional elliptic curves. The use of SHA2-256 for integrity is a reasonable one for this method. This Key Exchange Method has multiple implementations and SHOULD be implemented in any SSH interested in using elliptic curve based key exchanges.

The Curve448 provides very strong security. It is probably stronger and more work than is currently needed. This method MAY be implemented.

This set of ephemerally generated key exchange groups uses SHA-1 as defined in . However, SHA-1 has security concerns provided in . It is recommended that these key exchange groups NOT be used. This key exchange SHOULD NOT be used.

This set of ephemerally generated key exchange groups uses SHA2-256 as defined in . mandates implementations avoid any MODP group with less than 2048 bits. This key exchange MAY be used.

This method uses Oakley Group 2 (a 1024-bit MODP group) and SHA-1 . Due to recent security concerns with SHA-1 and with MODP groups with less than 2048 bits (see and ), this method is considered insecure. This method is being moved from MUST to SHOULD NOT instead of MUST NOT only to allow a transition time to get off of it. There are many old implementations out there that may still need to use this key exchange, it should be removed from server implementations as quickly as possible.

This method uses group14 (a 2048-bit MODP group) which is still a reasonable size. This key exchange group uses SHA-1 which has security concerns . However, this group is still strong enough and is widely deployed. This method is being moved from MUST to SHOULD to aid in transition to stronger SHA-2 based hashes. This method will transition to SHOULD NOT when SHA-2 alternatives are more generally available.

This key exchange uses the group14 (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered to be secure. It is a reasonably simple transition to move from SHA-1 to SHA-2. This method MUST be implemented.

Note: The use of this 3072-bit MODP group would be equally justified to use SHA2-384 as the hash rather than SHA2-512. However, some small implementations would rather only worry about two rather than three new hashing functions. This group does not really provide much additional head room over the 2048-bit group14 FFC DH and the predominate open source implementations are not adopting it. This method MAY be implemented.

The use of FFC DH is well understood and trusted. Adding larger modulus sizes and protecting with SHA2-512 should give enough head room to be ready for the next scare that someone has pre-computed it. This modulus (4096-bit) is larger than that required by and should be sufficient to inter-operate with more paranoid nation-states. This method SHOULD be implemented.

The use of this 6144-bit MODP group is going to be slower than what may be desirable. It is provided to help those who wish to avoid using ECC algorithms. This method MAY be implemented.

The use of this 8192-bit MODP group is going to be slower than what may be desirable. It is provided to help those who wish to avoid using ECC algorithms. This method MAY be implemented.

Elliptic Curve Diffie-Hellman (ECDH) are often implemented because they are smaller and faster than using large FFC primes with traditional Diffie-Hellman (DH). However, given and , this curve may not be as useful and strong as desired for handling TOP SECRET information for some applications. The SSH development community is divided on this and many implementations do exist. If traditional ECDH key exchange methods are implemented, then this method SHOULD be implemented. It is advisable to match the ECDSA and ECDH algorithms to use the same family of curves.

This ECDH method should be implemented because it is smaller and faster than using large FFC primes with traditional Diffie-Hellman (DH). Given , it is considered good enough for TOP SECRET. If traditional ECDH key exchange methods are implemented, then this method SHOULD be implemented.

This ECDH method may be implemented because it is smaller and faster than using large FFC primes with traditional Diffie-Hellman (DH). It is not listed in , so it is not currently appropriate for TOP SECRET. This method MAY be implemented.

This set of ephemerally generated key exchange groups uses SHA-1 which has security concerns . It is recommended that these key exchange groups NOT be used. This key exchange SHOULD NOT be used. It is intended that it move to MUST NOT as soon as the majority of server implementations no longer offer it. It should be removed from server implementations as quickly as possible.

This method suffers from the same problems of diffie-hellman-group1-sha1. It uses Oakley Group 2 (a 1024-bit MODP group) and SHA-1 . Due to recent security concerns with SHA-1 and with MODP groups with less than 2048 bits (see and ), this method is considered insecure. This method SHOULD NOT be implemented. It is intended that it move to MUST NOT as soon as the majority of server implementations no longer offer it. It should be removed from server implementations as quickly as possible.

This generated key exchange groups uses SHA-1 which has security concerns . If GSS-API key exchange methods are being used, then this one SHOULD be implemented until such time as SHA-2 variants may be implemented and deployed. This method will transition to SHOULD NOT when SHA-2 alternatives are more generally available. No other standard indicated that this method was anything other than optional even though it was implemented in all GSS-API systems. This method MAY be implemented.

The use of this 3072-bit MODP group does not really provide much additional head room over the 2048-bit group14 FFC DH. If the GSS-API is to be used, then this method MAY be implemented.

The use of FFC DH is well understood and trusted. Adding larger modulus sizes and protecting with SHA2-512 should give enough head room to be ready for the next scare that someone has pre-computed. This modulus (4096-bit) is larger than that required by and should be sufficient to inter-operate with more paranoid nation-states. If the GSS-API is to be used, then this method SHOULD be implemented.

The use of this 6144-bit MODP group is going to be slower than what may be desirable. It is provided to help those who wish to avoid using ECC algorithms. If the GSS-API is to be used, then this method MAY be implemented.

The use of this 8192-bit MODP group is going to be slower than what may be desirable. It is provided to help those who prefer to avoid using ECC algorithms. If the GSS-API is to be used, then this method MAY be implemented.

If the GSS-API is to be used with ECC algorithms, then this method SHOULD be implemented.

If the GSS-API is to be used with ECC algorithms, then this method SHOULD be implemented to permit TOP SECRET information to be communicated.

If the GSS-API is to be used with ECC algorithms, then this method MAY be implemented.

If the GSS-API is to be used with ECC algorithms, then this method SHOULD be implemented.

If the GSS-API is to be used with ECC algorithms, then this method MAY be implemented.

The security of RSA 1024-bit modulus keys is not good enough any longer. A key size should be 2048-bits. This generated key exchange groups uses SHA-1 which has security concerns . This method MUST NOT be implemented.

An RSA 2048-bit modulus key with a SHA2-256 hash. This method MAY be implemented.

As may be seen from the above, the Key Exchange Methods area all using either SHA256 or SHA512 with the exception of the ecdh-sha2-nistp384 which uses SHA384. The cited CNSA Suite specifies the use of SHA384 and says that SHA256 is no longer good enough for TOP SECRET. Nothing is said about the use of SHA512. It may be that the internal state of 1024 bits in both SHA384 and SHA512 makes the SHA384 more secure because it does not leak an additional 128 bits of state. Of course, use of SHA384 also reduces the security strength to 192 bits instead of being 256 bits or more. This seems to contradict the desire to double the symmetric key strength in order to try to be safe from Post Quantum Computing (PQC) attacks given a session key derived from the key exchange will be limited to the security strength of the hash being used. The move away from SHA256 to SHA512 for the newer key exchange methods is more to try to slow Grover's algorithm (a PQC attack) slightly. It is also the case that SHA2-512 may, in many modern CPUs, be implemented more efficiently using 64-bit arithmetic than SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs SHA512 is more about reducing the number of code point alternatives to negotiate. There seemed to be consensus in favor of SHA2-512 over SHA2-384 for key exchanges.

The Implement column is the current recommendations of this RFC. Key Exchange Method Names are listed alphabetically. Key Exchange Method Name Reference Implement curve25519-sha256ssh-curvesSHOULD diffie-hellman-group-exchange-sha1RFC4419SHOULD NOT diffie-hellman-group1-sha1RFC4253SHOULD NOT diffie-hellman-group14-sha1RFC4253SHOULD diffie-hellman-group14-sha256new-modpMUST diffie-hellman-group16-sha512new-modpSHOULD ecdh-sha2-nistp256RFC5656SHOULD ecdh-sha2-nistp384RFC5656SHOULD gss-gex-sha1-*RFC4462SHOULD NOT gss-group1-sha1-*RFC4462SHOULD NOT gss-group14-sha256-*gss-keyexSHOULD gss-group16-sha512-*gss-keyexSHOULD gss-nistp256-sha256-*gss-keyexSHOULD gss-nistp384-sha384-*gss-keyexSHOULD gss-curve25519-sha256-*gss-keyexSHOULD rsa1024-sha1RFC4432MUST NOT The full set of official key algorithm method names not otherwise mentioned in this document MAY be implemented. The guidance of this document is that the SHA-1 algorithm hashing SHOULD NOT be used. If it is used in implementations, it should only be provided for backwards compatibility, should not be used in new designs, and should be phased out of existing key exchanges as quickly as possible because of its known weaknesses. Any key exchange using SHA-1 should not be in a default key exchange list if at all possible. If they are needed for backward compatibility, they SHOULD be listed after all of the SHA-2 based key exchanges. The MUST diffie-hellman-group14-sha1 method SHOULD be retained for compatibility with older Secure Shell implementations. It is intended that this key exchange method be phased out as soon as possible. It SHOULD be listed after all possible SHA-2 based key exchanges. It is believed that all current SSH implementations should be able to achieve an implementation of the "diffie-hellman-group14-sha256" method. To that end, this is one method that MUST be implemented. [TO BE REMOVED: This registration should take place at the following location: <http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16>]

Thanks to the following people for review and comments: Denis Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, and Tero Kivinen. Thanks to the following people for code to implement inter-operable exchanges using some of these groups as found in an this draft: Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) and Poderosa implementations also adopting new Diffie-Hellman groups based on this draft.

This SSH protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session ID that may be used by higher-level protocols. Full security considerations for this protocol are provided in It is desirable to deprecate or remove key exchange method name that are considered weak. A key exchange method may be weak because too few bits are used, or the hashing algorithm is considered too weak. The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. This method used Oakley Group 2 (a 1024-bit MODP group) and SHA-1 . Due to recent security concerns with SHA-1 and with MODP groups with less than 2048 bits , this method is no longer considered secure. The United States Information Assurance Directorate (IAD) at the National Security Agency (NSA) has published a FAQ suggesting that the use of Elliptic Curve Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes less than SHA2-384 are no longer sufficient for transport of TOP SECRET information. If your systems need to be concerned with TOP SECRET information, then the guidance for supporting lesser security strength key exchanges may be omitted for your implementations. The MODP group14 is already required for SSH implementations and most implementations already have a SHA2-256 implementation, so diffie-hellman-group14-sha256 is provided as an easy to implement and faster to use key exchange. Small embedded applications may find this KEX desirable to use. The NSA Information Assurance Directorate (IAD) has also published the Commercial National Security Algorithm Suite (CNSA Suite) in which the 3072-bit MODP Group 15 in is explicitly mentioned as the minimum modulus to protect TOP SECRET communications. It has been observed in that the NIST Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not the best available for Elliptic Curve Cryptography (ECC) Security. For this reason, none of the curves are mandatory to implement. However, the requirement that "every compliant SSH ECC implementation MUST implement ECDH key exchange" is now taken to mean that if ecdsa-sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be implemented. In a Post-Quantum Computing (PQC) world, it will be desirable to use larger cyclic subgroups. To do this using Elliptic Curve Cryptography will require much larger prime base fields, greatly reducing their efficiency. Finite Field based Cryptography already requires large enough base fields to accommodate larger cyclic subgroups. Until such time as a PQC method of key exchange is developed and adopted, it may be desirable to generate new and larger DH groups to avoid pre-calculation attacks that are provably not backdoored.

IANA is requested to annotate entries in which MUST NOT be implemented as being deprecated by this document.