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 the Key Exchange Method Name diffie-hellman-group1-sha1 which 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 implementer and users request support for larger MODP group sizes with data integrity verification using the SHA-2 family of secure hash algorithms as well as MODP groups providing more security. 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. It is for this reason that this draft moves ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange method. This is the same reason that the stronger MODP groups being adopted. As the MODP group14 is already present in most 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 RFC 3526 is explicitly mentioned as the minimum modulus to protect Top Secret communications. It has been observed in that the NIST recommended 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 marked as a MUST 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. 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 .

This memo adopts the style and conventions of in specifying how the use of new data key exchange is indicated in SSH. A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The curve25519-sha256 MUST be adopted where possible. As a hedge against uncertainty raised by the NSA IAD FAQ publication, new MODP Diffie-Hellman based key exchanges are proposed for inclusion in the set of key exchange method names as well as the curve448-sha512 curve. The following new key exchange algorithms are defined: Key Exchange Method NameNote curve25519-sha256MUST/REQUIRED curve448-sha512MAY/OPTIONAL diffie-hellman-group14-sha256MUST/REQUIRED diffie-hellman-group15-sha512MAY/OPTIONAL diffie-hellman-group16-sha512SHOULD/RECOMMENDED diffie-hellman-group17-sha512MAY/OPTIONAL diffie-hellman-group18-sha512MAY/OPTIONAL gss-group14-sha256-*SHOULD/RECOMMENDED gss-group15-sha512-*MAY/OPTIONAL gss-group16-sha512-*SHOULD/RECOMMENDED gss-group17-sha512-*MAY/OPTIONAL gss-group18-sha512-*MAY/OPTIONAL The SHA-2 family of secure hash algorithms are defined in .

This RFC augments the Key Exchange Method Names in . It downgrades the use of SHA-1 hashing for key exchange methods in , , and . It also moves from MUST to SHOULD the ecdh-sha2-nistp256 given in . It adds a new set of named "gss-*" methods to with a MAY recommendation. It is desirable to also include the new-modp from the in this list. It is desirable to also include the ssh-curves from the in this list. The "curve25519-sha256" is currently available in some Secure Shell implementations under the name "curve25519-sha256@libssh.org" and is the best candidate for a fast, safe, and secure key exchange method. IANA is requested to update the SSH algorithm registry to ensure that all of the listed Key Exchange Method Name and References exist in the following table. However, the Implement column is just the current recommendations of this RFC. Key Exchange Method NameReferenceImplement curve25519-sha256ssh-curvesMUST curve448-sha512ssh-curvesMAY diffie-hellman-group-exchange-sha1RFC4419SHOULD NOT diffie-hellman-group-exchange-sha256RFC4419MAY diffie-hellman-group1-sha1RFC4253SHOULD NOT diffie-hellman-group14-sha1RFC4253SHOULD diffie-hellman-group14-sha256new-modpMUST diffie-hellman-group15-sha512new-modpMAY diffie-hellman-group16-sha512new-modpSHOULD diffie-hellman-group17-sha512new-modpMAY diffie-hellman-group18-sha512new-modpMAY ecdh-sha2-nistp256RFC5656SHOULD ecdh-sha2-nistp384RFC5656SHOULD ecdh-sha2-nistp521RFC5656SHOULD ecdh-sha2-*RFC5656MAY ecmqv-sha2RFC5656SHOULD NOT gss-gex-sha1-*RFC4462SHOULD NOT gss-group1-sha1-*RFC4462SHOULD NOT gss-group14-sha1-*RFC4462SHOULD gss-group14-sha256-*new-modpSHOULD gss-group15-sha512-*new-modpMAY gss-group16-sha512-*new-modpSHOULD gss-group17-sha512-*new-modpMAY gss-group18-sha512-*new-modpMAY gss-*RFC4462MAY rsa1024-sha1RFC4432SHOULD NOT rsa2048-sha256RFC4432MAY The Implement column in the above table is a suggestion/recommendation for the listed key exchange method to be implemented in the default list of key exchange methods. It is up to the end-user as to what algorithms they choose to be able to negotiate, so the KEX algorithms should be configurable by the administrator of the server as well as the user of the client. This RFC is intended to provide IANA defined names for these groups for interoperability. The Note column of the IANA table should probably continue to point to the implementation detail sections of the Reference RFCs where appropriate. The guidance of his RFC is that the SHA-1 algorithm hashing SHOULD NOT be used. If it is used, 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 RFC4253 REQUIRED 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 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. If GSS-API methods are available, then the RFC4462 REQUIRED gss-group14-sha1-* method SHOULD be retained for compatibility with older Secure Shell implementations and the gss-groups14-sha256-* method SHOULD be added as for "sha1". [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. Thanks to the following people for code to implement interoperable 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.

The security considerations of apply to this RFC. The security considerations of suggest that these MODP groups have security strengths given in this table. They are based on Determining Strengths For Public Keys Used For Exchanging Symmetric Keys.

Group modulus security strength estimates (RFC3526) +--------+----------+---------------------+---------------------+ | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | | | +----------+----------+----------+----------+ | | | | exponent | | exponent | | | | in bits | size | in bits | size | +--------+----------+----------+----------+----------+----------+ | 14 | 2048-bit | 110 | 220- | 160 | 320- | | 15 | 3072-bit | 130 | 260- | 210 | 420- | | 16 | 4096-bit | 150 | 300- | 240 | 480- | | 17 | 6144-bit | 170 | 340- | 270 | 540- | | 18 | 8192-bit | 190 | 380- | 310 | 620- | +--------+----------+---------------------+---------------------+ Many users seem to be interested in the perceived safety of using larger MODP groups and hashing with SHA2-based algorithms.