]>
Key Exchange (KEX) Method Updates and Recommendations for Secure
Shell (SSH)
Juniper Networks, Inc.
mdb@juniper.net
Internet Engineering Task Force
This document is intended to update the recommended set of key
exchange methods for use in the Secure Shell (SSH) protocol to
meet evolving needs for stronger security. This document
updates RFC 4250.
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 .
New key exchange methods will use the SHA-2 family of hashes
found in rather than the SHA-1 hash
which is in the process of being deprecated for many purposes
as no longer providing enough security.
SSH uses multiple mathematically hard problems for doing Key
Exchange. Finite Field Cryptography (FFC) with "safe primes"
for diffie-hellman (DH) key exchange. Elliptic Curve
Cryptography (ECC) using NIST prime curves with Elliptic Curve
Diffie-Hellman (ECDH) and the similar Curve25519 and Curve448
key exchanges.
For FFC, many experts have suggested that a prime field of
2048-bits is the minimum (2048-bits is said to have 112 bits
of security and 3072-bits is said to have 128 bits of
security) allowed and larger sizes up to 8192 bits are
considered to be much stronger. The minimum MODP group that
MAY be used is the 2048-bit MODP group14.
For ECC, many experts have suggested that a 256-bits curve is
the minimum allowed (256-bits is said to have 128 bits of
security) and larger sizes up to 521-bits are considered to be
much stronger (521-bits are considered to have around 256-bits
of security).
When it comes to Secure Hashing functions, SHA2-256 is said to
have 128-bits of security SHA2-384 to have 192-bits of
security, and SHA2-512 to have 256-bits of security. The older
SHA-1 hash is supposed to have about 80-bits of security. The
minimum secure hashing function that should be used is
SHA2-256 in the year of this RFC.
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.
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 one of MAY, SHOULD NOT, or MUST NOT. Or, when
newer methods have been analyzed and found to be secure with
wide enough adoption, upgrade their recommendation from MAY to
SHOULD or MUST.
Curve25519 is efficient on a wide range of architectures
with properties that allow higher performance
implementations compared to traditional elliptic curves. The
use of SHA2-256 (also known as SHA-256 and sha256) as
defined in for integrity is a
reasonable one for this method. This Key Exchange Method is
described in and is similar to the
IKEv2 Key Agreement described in .
This Key Exchange Method has multiple implementations and
SHOULD be implemented in any SSH implementation interested
in using elliptic curve based key exchanges.
The Curve448 requires more work than Curve25519. It uses
SHA2-512 (also known as SHA-512) defined in for integrity. This Key Exchange Method
is described in and is similar to
the IKEv2 Key Agreement described in . This method MAY be implemented.
This random selection from a set of pre-generated moduli for
key exchange uses SHA-1 as defined in . However, SHA-1 has security concerns
provided in , so it would be better
to use a key exchange method which uses a SHA-2 hash as in
for integrity. This key exchange
SHOULD NOT be used.
This random selection from a set of pre-generated moduli for
key exchange uses SHA2-256 as defined in . mandates
implementations avoid any MODP group with less than 2048
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 or the parameter set may leak one
bit of the shared private key leaving the MODP group half as
strong as desired as compared with the number of bits. This
key exchange MAY be used.
This method is decribed in and 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 method is defined in and uses the group14 (a 2048-bit MODP
group) along with a SHA-2 (SHA2-256) hash as in for integrity. This represents the
smallest FFC DH key exchange method considered to be secure.
It is a reasonably simple transition to move from SHA-1 to
SHA-2. This method SHOULD be implemented.
This key exchange method is defined in and uses group15 (a 3072-bit MODP group)
along with a SHA-2 (SHA2-512) hash as in for integrity. This modulus is the
minimum required by . This method
MAY be implemented.
This key exchange method is defined in and uses group16 (a 4096-bit MODP group)
along with a SHA-2 (SHA2-512) hash as in for integrity. 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 method MAY be implemented.
This key exchange method is defined in and uses group17 (a 6144-bit MODP group)
along with a SHA-2 (SHA2-512) hash as in for integrity. 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.
This key exchange method is defined in and uses group18 (a 8192-bit MODP group)
along with a SHA-2 (SHA2-512) hash as in for integrity. 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.
This namespace allows for other curves to be defined for the
elliptic curve Diffie Hellman key exchange. At present,
there are three members of this namespace They appear in
which are covered below. This set
of methods MAY be implemented.
This key exchange method is defined in . ECDH methods are often implemented
because they are smaller and faster than using large FFC
DH parameters. 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 curve for both.
This key exchange method is defined in . This ECDH method should be implemented
because it is smaller and faster than using large FFC
primes with traditional DH. Given , it is considered good enough for
TOP SECRET. However, given , care must be used when using
this algorithm. If traditional ECDH key exchange methods
are implemented, then this method SHOULD be implemented.
Concerns raised in may mean
that this algorithm will need to be downgraded in the
future along the other ECDSA NIST Prime curves.
This key exchange method is defined in . This ECDH method may be implemented
because it is smaller and faster than using large FFC DH
parameters. It is not listed in , so it is not currently appropriate
for TOP SECRET. It is possible that the mismatch between
the 521-bit key and the 512-bit hash could mean that as
many as nine bits of this key could be at risk of leaking
if appropriate padding measures are not taken. This method
MAY be implemented.
This key exchange method is defined in . This method MAY be implemented.
This key exchange method is defined in . This method is not actually a key
exchange, but proivides a method to provide support for
extensions to other Secure Shell negotations. Being able to
extend functionality is desirable, This method SHOULD be
implemented.
This key exchange method is defined in . This method is not actually a key
exchange, but proivides a method to provide support for
extensions to other Secure Shell negotations. Being able to
extend functionality is desirable, This method SHOULD be
implemented.
This family of key exchange methods is defined in and for the
GSS-API key exchange methods. The family of methods MAY be
implemented for those who need GSS-API methods.
This key exchange method is defined in . This set of ephemerally generated key
exchange groups uses SHA-1 which has security concerns
. 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 key exchange method is defined in . 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 key exchange method is defined in . 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.
This key exchange method is defined in . 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. If the GSS-API is to be used, then
this method SHOULD be implemented.
This key exchange method is defined in and uses group15 (a 3072-bit MODP
group) along with a SHA-2 (SHA2-512) hash as in for integrity. This modulus is the
minimum required by . If the
GSS-API is to be used, then this method MAY be
implemented.
This key exchange method is defined in and uses group16 (a 4096-bit MODP
group) along with a SHA-2 (SHA2-512) hash as in for integrity. 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. If the GSS-API is to be used, then this
method MAY be implemented.
This key exchange method is defined in and uses group17 (a 6144-bit MODP group)
along with a SHA-2 (SHA2-512) hash as in for integrity. 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.
This key exchange method is defined in and uses group18 (a 8192-bit MODP
group) along with a SHA-2 (SHA2-512) hash as in for integrity. 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. If the GSS-API is to be used, then
this method MAY be implemented.
This key exchange method is defined in . If the GSS-API is to be used with ECC
algorithms, then this method SHOULD be implemented.
This key exchange method is defined in . 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.
This key exchange method is defined in . If the GSS-API is to be used with ECC
algorithms, then this method MAY be implemented.
This key exchange method is defined in . If the GSS-API is to be used with ECC
algorithms, then this method SHOULD be implemented.
This key exchange method is defined in . If the GSS-API is to be used with ECC
algorithms, then this method MAY be implemented.
This key exchange method is defined in . The security of RSA 1024-bit modulus
keys is not good enough any longer per , an RSA key size should be a
minimum of 2048-bits. This key exchange group uses SHA-1
which has security concerns . This
method MUST NOT be implemented.
This key exchange method is defined in . An RSA 2048-bit modulus key with a
SHA2-256 hash. At the present time, a 2048-bit RSA key is
considered to be suffiently strong in to be permitted. In addition,
the use of a SHA-2 hash as defined in is a good integrity measure. 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, the use of SHA384 also reduces the security
strength to 384 bits instead of being 512 bits. 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-sha256RFC8731SHOULD
curve448-sha512RFC8731MAY
diffie-hellman-group-exchange-sha1RFC4419SHOULD NOT
diffie-hellman-group-exchange-sha256RFC4419MAY
diffie-hellman-group1-sha1RFC4253SHOULD NOT
diffie-hellman-group14-sha1RFC4253SHOULD
diffie-hellman-group14-sha256RFC8268SHOULD
diffie-hellman-group15-sha512RFC8268MAY
diffie-hellman-group16-sha512RFC8268MAY
diffie-hellman-group17-sha512RFC8268MAY
diffie-hellman-group18-sha512RFC8268MAY
ecdh-sha2-*RFC5656MAY
ecdh-sha2-nistp256RFC5656SHOULD
ecdh-sha2-nistp384RFC5656SHOULD
ecdh-sha2-nistp521RFC5656MAY
ecmqv-sha2RFC5656MAY
ext-info-cRFC8308MAY
ext-info-sRFC8308MAY
gss-*RFC4462MAY
gss-curve25519-sha256-*RFC8732SHOULD
gss-curve448-sha512-*RFC8732MAY
gss-gex-sha1-*RFC4462SHOULD NOT
gss-group1-sha1-*RFC4462SHOULD NOT
gss-group14-sha256-*RFC8732SHOULD
gss-group15-sha512-*RFC8732MAY
gss-group16-sha512-*RFC8732MAY
gss-group17-sha512-*RFC8732MAY
gss-group18-sha512-*RFC8732MAY
gss-nistp256-sha256-*RFC8732SHOULD
gss-nistp384-sha384-*RFC8732SHOULD
gss-nistp521-sha512-*RFC8732MAY
rsa1024-sha1RFC4432MUST NOT
rsa2048-sha256RFC4432MAY
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
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.
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.
&RFC2119;
&RFC3526;
&RFC4250;
&RFC4253;
&RFC8031;
&RFC8174;
&RFC8268;
&RFC8270;
&RFC8308;
Commercial National Security Algorithm Suite
"Information Assurance by the National Security Agency"
&RFC6234;
&RFC8731;
&RFC8732;
Secure Shell (SSH) Protocol Parameters:
Key Exchange Method Names
Internet Assigned Numbers Authority (IANA)
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
Univeristy of Michigan
INRIA Paris-Rocquencourt
Univeristy of Michigan
INRIA Nancy-Grand Est, CNRS, and Université de Lorraine
Johns Hopkins
Univeristy of Michigan
University of Pennsylvania
Univeristy of Michigan
INRIA Nancy-Grand Est, CNRS, and Université de Lorraine
University of Pennsylvania
Univeristy of Michigan
Univeristy of Michigan
Microsoft Research
Univeristy of Michigan
CNSA Suite and Quantum Computing FAQ
"National Security Agency/Central Security Service"
Using Bleichenbacher's Solution to the Hidden Number
Problem to Attack Nonce Leaks in 384-Bit ECDSA
Transitions: Recommendation for the Transitioning of
the Use of Cryptographic Algorithms and Key Lengths
&RFC3174;
&RFC4251;
&RFC4419;
&RFC4432;
&RFC4462;
&RFC5656;
&RFC6194;
&RFC7296;
SafeCurves: choosing safe curves for elliptic-curve
cryptography.