]>
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. This
document updates .
This document adds recommendations for adoption of Key Exchange
Methods which MUST, SHOULD+, SHOULD, 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.
When used in the tables in this document, these terms indicate
that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or
MAY be implemented as part of a Secure Shell implementation.
Additional terms used in this document are:
SHOULD+
This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST.
SHOULD-
This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future
version of this document.
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,
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, 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.
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 MUST NOT be used.
This set of ephemerally generated key exchange groups uses
SHA2-256 as defined in .
It is recommended 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 , this method is considered
insecure. This method is being moved from MUST to MUST NOT.
This method uses group14 (a 2048-bit
MODP group) which has no concerns. This generated 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 MUST NOT when
SHA-2 alternatives are more generally available.
This generated key exchange uses a 2048-bit sized 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.
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 is larger than that required
by and should be sufficient to
inter-operate with more paranoid nation-states. This method
SHOULD+ 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. The
SSH development community is divided on this and many
implementations do exist. However, there are good
implementations of this along with a constant-time SHA2-256
implementation. If an implementer does not have a
constant-time SHA2-384 implementation (which helps avoid
side-channel attacks), then this is the correct ECDH to
implement. If traditional ECDH key exchange methods are
implemented, then this method SHOULD- be implemented.
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 for now. This really
needs a constant-time implementation of SHA2-384 to be
useful. If traditional ECDH key exchange methods are
implemented, then this method SHOULD+ 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 MUST NOT be implemented.
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 , this
method is considered insecure. This method MUST NOT be
implemented.
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.
If the GSS-API is to be used, then this method SHOULD be
implemented.
If the GSS-API is to be used, then this method SHOULD+
be implemented.
The security of RSA 1024-bit modulus keys is not good enough
any longer. A minimum bit size should be 2048-bit groups.
This generated key exchange groups uses SHA-1 which has
security concerns . This method
MUST NOT be implemented.
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-sha1RFC4419MUST NOT
diffie-hellman-group1-sha1RFC4253MUST NOT
diffie-hellman-group14-sha1RFC4253SHOULD-
diffie-hellman-group14-sha256new-modpMUST
diffie-hellman-group16-sha512new-modpSHOULD+
ecdh-sha2-nistp256RFC5656SHOULD-
ecdh-sha2-nistp384RFC5656SHOULD+
gss-gex-sha1-*RFC4462MUST NOT
gss-group1-sha1-*RFC4462MUST NOT
gss-group14-sha1-*RFC4462SHOULD-
gss-group14-sha256-*gss-keyexSHOULD
gss-group16-sha512-*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 MUST 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.
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. It is for
this reason that this draft moves ecdh-sha2-nistp256 from a
MUST to MAY 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 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 precalcualtion
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;
Commercial National Security Algorithm Suite
"Information Assurance by the National Security Agency"
&SSHCURVES;
&NEWMODP;
Secure Shell (SSH) Protocol Parameters:
Key Exchange Method Names
Internet Assigned Numbers Authority (IANA)
CNSA Suite and Quantum Computing FAQ
"National Security Agency/Central Security Service"
GSS-API Key Exchange with SHA2
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.