]>
Key Exchange (KEX) Method Updates and Recommendations for Secure
Shell (SSH)
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale
CA
`94089-1228`

US
mdb@juniper.net
http://www.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 .
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 found in and are drawn from
these ssh-curves from and DH MODP primes from the
and gss-keyex .
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 (also known as SHA-256) 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
interested in using elliptic curve based key exchanges.
The Curve448 provides very strong security. It uses SHA2-512
(also known as SHA-256) defined in
for integrity. It is probably stronger and more work than is
currently needed. This Key Exchange Method is described in
and is similar to
the IKEv2 Key Agreement described in . 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 ,
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 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 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 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.
This key exchange method is defined in and uses group15 along with a SHA-2
(SHA2-512) hash as in for integrity.
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.
This key exchange method is defined in and uses group16 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 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.
This key exchange method is defined in and uses group17 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 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 key exchange method is defined in .
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 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
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.
Research into ways of breaking ECDSA continues. Papers such
as as well as concerns
raised in may mean that this
algorithm will need to be downgraded in the future along the
other ECDSA nistp curves.
This key exchange method is defined in .
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. 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, but is not recommended.
This key exchange method is defined in .
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 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 .
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.
This key exchange method is defined in .
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.
This key exchange method is defined in .
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 .
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.
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. 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.
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-sha256ssh-curvesSHOULD
diffie-hellman-group-exchange-sha1RFC4419SHOULD NOT
diffie-hellman-group1-sha1RFC4253SHOULD NOT
diffie-hellman-group14-sha1RFC4253SHOULD
diffie-hellman-group14-sha256RFC8268MUST
diffie-hellman-group16-sha512RFC8268SHOULD
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.
&RFC2119;
&RFC3526;
&RFC4250;
&RFC4253;
&RFC8270;
&RFC8268;
&RFC8031;
Commercial National Security Algorithm Suite
"Information Assurance by the National Security Agency"
&RFC6234;
&SSHCURVES;
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"
&NEWGSSAPI;
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.