< draft-ietf-curdle-ssh-kex-sha2-11.txt   draft-ietf-curdle-ssh-kex-sha2-12.txt >
Internet Engineering Task Force M. Baushke Internet Engineering Task Force M. D. Baushke
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 4250 (if approved) July 13, 2020 Updates: 4250 (if approved) 23 November 2020
Intended status: Standards Track Intended status: Standards Track
Expires: January 14, 2021 Expires: 27 May 2021
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH) (SSH)
draft-ietf-curdle-ssh-kex-sha2-11 draft-ietf-curdle-ssh-kex-sha2-12
Abstract Abstract
This document is intended to update the recommended set of key This document is intended to update the recommended set of key
exchange methods for use in the Secure Shell (SSH) protocol to meet exchange methods for use in the Secure Shell (SSH) protocol to meet
evolving needs for stronger security. This document updates RFC evolving needs for stronger security. This document updates RFC
4250. 4250.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on 27 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 1.1. Selecting an appropriate hashing algorithm . . . . . . . 3
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 4 1.2. Selecting an appropriate Public Key Algorithm . . . . . . 3
3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4
3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 4
3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5
3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 5 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 5
3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5 3.1. SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . . 6
3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 3.2. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 6
3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 6 3.2.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 6
3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 6 3.2.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 7
3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 6 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and
3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6 gss-nistp* . . . . . . . . . . . . . . . . . . . . . 7
3.12. ecdh-sha2-* . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 8
3.12.1. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . 6 3.3.1. FFC diffie-hellman using generated MODP groups . . . 8
3.12.2. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . 7 3.3.2. FFC diffie-hellman using named MODP groups . . . . . 8
3.12.3. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . 7 3.4. Integer Factorization Cryptography (IFC) . . . . . . . . 9
3.13. ecmqv-sha2 . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 9
3.14. ext-info-c . . . . . . . . . . . . . . . . . . . . . . . 7 4. Summary Guidance for Key Exchange Method Names
3.15. ext-info-s . . . . . . . . . . . . . . . . . . . . . . . 8 Implementations . . . . . . . . . . . . . . . . . . . . . 9
3.16. gss-* . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
3.16.1. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
3.16.2. gss-group1-sha1-* . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
3.16.3. gss-group14-sha1-* . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.16.4. gss-group14-sha256-* . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
3.16.5. gss-group15-sha512-* . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 13
3.16.6. gss-group16-sha512-* . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
3.16.7. gss-group17-sha512-* . . . . . . . . . . . . . . . . 9
3.16.8. gss-group18-sha512-* . . . . . . . . . . . . . . . . 9
3.16.9. gss-nistp256-sha256-* . . . . . . . . . . . . . . . 10
3.16.10. gss-nistp384-sha384-* . . . . . . . . . . . . . . . 10
3.16.11. gss-nistp521-sha512-* . . . . . . . . . . . . . . . 10
3.16.12. gss-curve25519-sha256-* . . . . . . . . . . . . . . 10
3.16.13. gss-curve448-sha512-* . . . . . . . . . . . . . . . 10
3.17. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 10
3.18. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 10
4. Selecting an appropriate hashing algorithm . . . . . . . . . 11
5. Summary Guidance for Key Exchange Method Names . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Overview and Rationale 1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined two Key Exchange the Internet. In [RFC4253], SSH originally defined two Key Exchange
Method Names that MUST be implemented. Over time, what was once (KEX) Method Names that MUST be implemented. Over time what was once
considered secure is no longer considered secure. The purpose of considered secure is no longer considered secure. The purpose of
this RFC is to recommend that some published key exchanges be this RFC is to recommend that some published key exchanges be
deprecated as well as recommending some that SHOULD and one that MUST deprecated as well as recommending some that SHOULD and one that MUST
be adopted. This document updates [RFC4250]. be adopted. This document updates [RFC4250].
New key exchange methods will use the SHA-2 family of hashes found in A key exchange has two components, a hashing algorithm and a public
[RFC6234] rather than the SHA-1 hash which is in the process of being key algorithm. The following subsections describe how to select each
deprecated for many purposes as no longer providing enough security. component.
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.
2. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Key Exchange Methods
This memo adopts the style and conventions of [RFC4253] 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 [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
[RFC8268], [RFC8731] [RFC8732], and [RFC8308], 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 1.1. Selecting an appropriate hashing algorithm
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.
3.1. curve25519-sha256 The SHA-1 hash is in the process of being deprecated for many
reasons. There have been attacks against SHA-1 that have shown there
are weaknesses in the algorithm. Therefore, it is desirable to move
away from using it before attacks become more serious.
Curve25519 is efficient on a wide range of architectures with At present, the attacks against SHA-1 are collision attacks that rely
properties that allow higher performance implementations compared to on human help rather than a pre-image attack. So, it is still
traditional elliptic curves. The use of SHA2-256 (also known as possible to allow time backward compatibility use of SHA-1 during a
SHA-256 and sha256) as defined in [RFC6234] for integrity is a SSH key-exchange for a transition to stronger hashing. However, any
reasonable one for this method. This Key Exchange Method is such key exchanges should be listed last in the preference list.
described in [RFC8731] and is similar to the IKEv2 Key Agreement
described in [RFC8031]. This Key Exchange Method has multiple
implementations and SHOULD be implemented in any SSH implementation
interested in using elliptic curve based key exchanges.
3.2. curve448-sha512 Use of the SHA-2 family of hashes found in [RFC6234] rather than the
SHA-1 hash is strongly advised.
The Curve448 requires more work than Curve25519. It uses SHA2-512 When it comes to the SHA-2 family of Secure Hashing functions,
(also known as SHA-512) defined in [RFC6234] for integrity. This Key SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of
Exchange Method is described in [RFC8731] and is similar to the IKEv2 security strength; SHA2-384 has 192 bits of security strength; and
Key Agreement described in [RFC8031]. This method MAY be SHA2-512 has 256 bits of security strength. As the same compute
implemented. power is needed for both SHA2-224 and SHA2-256 and currently no KeX
uses SHA2-224, it is suggested that the minimum secure hashing
function that should be used for Key Exchange Methods is SHA2-256.
3.3. diffie-hellman-group-exchange-sha1 To avoid combinatorial explosion of key exchange names, newer key
exchanges are restricting to the use of *-sha256 and *-sha512.
This random selection from a set of pre-generated moduli for key 1.2. Selecting an appropriate Public Key Algorithm
exchange uses SHA-1 as defined in [RFC4419]. However, SHA-1 has
security concerns provided in [RFC6194], so it would be better to use
a key exchange method which uses a SHA-2 hash as in [RFC6234] for
integrity. This key exchange SHOULD NOT be used.
3.4. diffie-hellman-group-exchange-sha256 SSH uses mathematically hard problems for doing Key Exchange:
This random selection from a set of pre-generated moduli for key * Elliptic Curve Cryptography (ECC) has families of curves for Key
exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates Exchange Methods for SSH. NIST prime curves with names and other
implementations avoid any MODP group with less than 2048 bits. Care curves are available using an object identifier (OID) with
should be taken in the pre-generation of the moduli P and generator G Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519
such that the generator provides a Q-ordered subgroup of P or the and Curve448 key exchanges are used with ECDH via [RFC8731].
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.
3.5. diffie-hellman-group1-sha1 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH)
key exchange with "safe primes" either from a specified list found
in [RFC3526] or generated dynamically via [RFC4419] as updated by
[RFC8270].
This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group * Integer Factorization Cryptography (IFC) using the RSA algorithm
2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent is provided for in [RFC4432].
security concerns with SHA-1 [RFC6194] and with MODP groups with less
than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar2]), 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.
3.6. diffie-hellman-group14-sha1 It is desirable for the security strength of the key exchange be
chosen to be comparable with the security strength of the other
elements of the SSH handshake. Attackers can target the weakest
element of the SSH handshake.
This method uses [RFC3526] group14 (a 2048-bit MODP group) which is It is desirable to select a minimum of 112 bits of security strength.
still a reasonable size. This key exchange group uses SHA-1 which Based on implementer security needs, a stronger minimum may be
has security concerns [RFC6194]. However, this group is still strong desired.
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.
3.7. diffie-hellman-group14-sha256 1.2.1. Elliptic Curve Cryptography (ECC)
This key exchange method is defined in [RFC8268] and uses the group14 For ECC, it is recommended to select one with approximately 128 bits
(a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in of security strength.
[RFC6234] 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.
3.8. diffie-hellman-group15-sha512 +============+=============================+
| Curve Name | Estimated Security Strength |
+============+=============================+
| nistp256 | 128 bits |
+------------+-----------------------------+
| nistp384 | 192 bits |
+------------+-----------------------------+
| nistp521 | 512 bits |
+------------+-----------------------------+
| Curve25519 | 128 bits |
+------------+-----------------------------+
| Curve448 | 224 bits |
+------------+-----------------------------+
This key exchange method is defined in [RFC8268] and uses group15 (a Table 1: ECC Security Strengths
3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] for integrity. This modulus is the minimum required by
[CNSA-SUITE]. This method MAY be implemented.
3.9. diffie-hellman-group16-sha512 1.2.2. Finite Field Cryptography (FFC)
This key exchange method is defined in [RFC8268] and uses group16 (a For FFC, a modulus 2048 bits (112 bits of security strength).
4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] 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.
3.10. diffie-hellman-group17-sha512 +==================+=============================+============+
| Prime Field Size | Estimated Security Strength | Example |
| | | MODP Group |
+==================+=============================+============+
| 2048-bit | 112 bits | group14 |
+------------------+-----------------------------+------------+
| 3072-bit | 128 bits | group15 |
+------------------+-----------------------------+------------+
| 4096-bit | 152 bits | group16 |
+------------------+-----------------------------+------------+
| 6144-bit | 176 bits | group17 |
+------------------+-----------------------------+------------+
| 8192-bit | 200 bits | group18 |
+------------------+-----------------------------+------------+
This key exchange method is defined in [RFC8268] and uses group17 (a Table 2: FFC MODP Security Strengths
6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] 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.
3.11. diffie-hellman-group18-sha512 The minimum MODP group that MAY be used is the 2048-bit MODP group14.
Implementations SHOULD support a 3072-bit MODP group or larger.
This key exchange method is defined in [RFC8268] and uses group18 (a 1.2.3. Integer Factorization Cryptography (IFC)
8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] 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.
3.12. ecdh-sha2-* The only IFC algorithm for key exchange is the RSA algorithm via
[RFC4432]. The minimum modulus size is 2048 bits. The use of a
SHA-2 Family hash with RSA 2048-bit keys has sufficient security.
This namespace allows for other curves to be defined for the elliptic +=====================+=============================+
curve Diffie Hellman key exchange. At present, there are three | Key Exchange Method | Estimated Security Strength |
members of this namespace They appear in [RFC5656] which are covered +=====================+=============================+
below. This set of methods MAY be implemented. | rsa1024-sha1 | 80 bits |
+---------------------+-----------------------------+
| rsa2048-sha256 | 112 bits |
+---------------------+-----------------------------+
3.12.1. ecdh-sha2-nistp256 Table 3: IFC Security Strengths
This key exchange method is defined in [RFC5656]. ECDH methods are 2. Requirements Language
often implemented because they are smaller and faster than using
large FFC DH parameters. However, given [CNSA-SUITE] and
[safe-curves], 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
same curve for both. "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3.12.2. ecdh-sha2-nistp384 3. Key Exchange Methods
This key exchange method is defined in [RFC5656]. This ECDH method This memo adopts the style and conventions of [RFC4253] in specifying
should be implemented because it is smaller and faster than using how the use of data key exchange is indicated in SSH.
large FFC primes with traditional DH. Given [CNSA-SUITE], it is
considered good enough for TOP SECRET. However, given
[ECDSA-Nonce-Leak], 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 [safe-curves] may mean that this algorithm will This RFC also collects key exchange method names in various existing
need to be downgraded in the future along the other ECDSA NIST Prime RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
curves. [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a
suggested suitability for implementation of MUST, SHOULD, SHOULD NOT,
and MUST NOT. Any method not explicitly listed MAY be implemented.
3.12.3. ecdh-sha2-nistp521 This document is intended to provide guidance as to what key exchange
algorithms are to be considered for new or updated SSH
implementations.
This key exchange method is defined in [RFC5656]. This ECDH method 3.1. SHA-1 and SHA-2 Hashing
may be implemented because it is smaller and faster than using large
FFC DH parameters. It is not listed in [CNSA-SUITE], 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.
3.13. ecmqv-sha2 All of the key exchanges using the SHA-1 hashing algorithm should be
deprecated and phased out of use because SHA-1 has security concerns
provided in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is the
only one which is more secure than SHA-1 and has been standardized
for use with SSH key exchanges.
This key exchange method is defined in [RFC5656]. This method MAY be diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are
currently mandatory to implement (MTI). diffie-hellman-group14-sha1
is the stronger of the two. Group14 (a 2048-bit MODP group) is
defined in [RFC3526]. It is reasonable to retain the diffie-hellman-
group14-sha1 exchange for interoperability with legacy
implementations. Therefore, diffie-hellman-group14-sha1 SHOULD be
implemented and all other *-sha1 key exchanges SHOULD NOT be
implemented. implemented.
3.14. ext-info-c 3.2. Elliptic Curve Cryptography (ECC)
This key exchange method is defined in [RFC8308]. 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.
3.15. ext-info-s
This key exchange method is defined in [RFC8308]. 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.
3.16. gss-*
This family of key exchange methods is defined in [RFC4462] and
[RFC8732] for the GSS-API key exchange methods. The family of
methods MAY be implemented for those who need GSS-API methods.
3.16.1. gss-gex-sha1-*
This key exchange method is defined in [RFC4462]. This set of
ephemerally generated key exchange groups uses SHA-1 which has
security concerns [RFC6194]. 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.
3.16.2. gss-group1-sha1-*
This key exchange method is defined in [RFC4462]. This method 3.2.1. curve25519-sha256 and gss-curve25519-sha256-*
suffers from the same problems of diffie-hellman-group1-sha1. It
uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1
[RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and
with MODP groups with less than 2048 bits (see [LOGJAM] and
[NIST-SP-800-131Ar2]), 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.
3.16.3. gss-group14-sha1-* 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 [RFC6234] for integrity is a
reasonable one for this method. These key exchange methods are
described in [RFC8731] and [RFC8732] and is similar to the IKEv2 Key
Agreement described in [RFC8031]. The curve25519-sha256 key exchange
method has multiple implementations and SHOULD be implemented. The
gss-curve25519-sha256-* key exchange method SHOULD also be
implemented because it shares the same performance and security
characteristics as curve25519-sha2.
This key exchange method is defined in [RFC4462]. This generated key 3.2.2. curve448-sha512 and gss-curve448-sha512-*
exchange groups uses SHA-1 which has security concerns [RFC6194]. 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.
3.16.4. gss-group14-sha256-* Curve448 provides more security strength than Curve25519 at a higher
computational and bandwidth cost. It uses SHA2-512 (also known as
SHA-512) defined in [RFC6234] for integrity. This Key Exchange
Method is described in [RFC8731] and is similar to the IKEv2 Key
Agreement described in [RFC8031]. This method MAY be implemented.
The gss-curve448-sha512-* key exchange method MAY also be implemented
because it shares the same performance and security characteristics
as curve448-sha512.
This key exchange method is defined in [RFC8732]. This key exchange 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp*
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.
3.16.5. gss-group15-sha512-* The ecdh-sha2-* name-space allows for other curves to be defined for
the elliptic curve Diffie Hellman key exchange. At present, there
are three named curves in this name-space which SHOULD be supported.
They appear in [RFC5656] in section 10.1 Required Curves all of the
NISTP curves named are mandatory to implement if any of this RFC is
implemented. This set of methods MAY be implemented. If
implemented, the named curves SHOULD always be enabled unless
specifically disabled by local security policy. In [RFC5656],
section 6.1, the method to name other ECDH curves using OIDs is
specified. These other curves MAY be implemented.
This key exchange method is defined in [RFC8732] and uses group15 (a The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in used by ecdh-sha2-* names. The table provides guidance for
[RFC6234] for integrity. This modulus is the minimum required by implementation.
[CNSA-SUITE]. If the GSS-API is to be used, then this method MAY be
implemented.
3.16.6. gss-group16-sha512-* ECDH reduces bandwidth of key exchanges compared to FFC DH at a
similar security strength.
This key exchange method is defined in [RFC8732] and uses group16 (a The following table lists algorithms as SHOULD where implementations
4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in may be more efficient or widely deployed. The items listed as MAY
[RFC6234] for integrity. The use of FFC DH is well understood and are potentially less efficient.
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.
3.16.7. gss-group17-sha512-* +==========================+==========+
| Key Exchange Method Name | Guidance |
+==========================+==========+
| ecdh-sha2-* | MAY |
+--------------------------+----------+
| ecdh-sha2-nistp256 | SHOULD |
+--------------------------+----------+
| gss-nistp256-sha256-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp384 | SHOULD |
+--------------------------+----------+
| gss-nistp384-sha384-* | SHOULD |
+--------------------------+----------+
| ecdh-sha2-nistp521 | SHOULD |
+--------------------------+----------+
| gss-nistp521-sha512-* | SHOULD |
+--------------------------+----------+
| ecmqv-sha2 | MAY |
+--------------------------+----------+
This key exchange method is defined in [RFC8732]and uses group17 (a Table 4: ECDH Implementation Guidance
6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] 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.
3.16.8. gss-group18-sha512-* It is advisable to match the ECDSA and ECDH algorithms to use the
same curve for both to maintain the same security strength in the
connection.
This key exchange method is defined in [RFC8732] and uses group18 (a 3.3. Finite Field Cryptography (FFC)
8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
[RFC6234] 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.
3.16.9. gss-nistp256-sha256-* 3.3.1. FFC diffie-hellman using generated MODP groups
This key exchange method is defined in [RFC8732]. If the GSS-API is This random selection from a set of pre-generated moduli for key
to be used with ECC algorithms, then this method SHOULD be exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates
implemented. implementations avoid any MODP group whose modulus size is 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. Otherwise, the parameter set may leak one bit of the
shared secret leaving the MODP group half as strong. This key
exchange MAY be used.
3.16.10. gss-nistp384-sha384-* 3.3.2. FFC diffie-hellman using named MODP groups
This key exchange method is defined in [RFC8732]. If the GSS-API is diffie-hellman-group14-sha256 represents the smallest FFC DH key
to be used with ECC algorithms, then this method SHOULD be exchange method considered to be secure. It is a reasonably simple
implemented to permit TOP SECRET information to be communicated. transition from SHA-1 to SHA-2. diffie-hellman-group14-sha256 method
MUST be implemented. The rest of the FFC MODP groups MAY be
implemented. The table below provides explicit guidance by name.
3.16.11. gss-nistp521-sha512-* +===============================+==========+
| Key Exchange Method Name | Guidance |
+===============================+==========+
| diffie-hellman-group14-sha256 | MUST |
+-------------------------------+----------+
| gss-group14-sha256-* | SHOULD |
+-------------------------------+----------+
| diffie-hellman-group15-sha512 | MAY |
+-------------------------------+----------+
| gss-group15-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group16-sha512 | SHOULD |
+-------------------------------+----------+
| gss-group16-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group17-sha512 | MAY |
+-------------------------------+----------+
| gss-group17-sha512-* | MAY |
+-------------------------------+----------+
| diffie-hellman-group18-sha512 | MAY |
+-------------------------------+----------+
| gss-group18-sha512-* | MAY |
+-------------------------------+----------+
This key exchange method is defined in [RFC8732]. If the GSS-API is Table 5: FFC Implementation Guidance
to be used with ECC algorithms, then this method MAY be implemented.
3.16.12. gss-curve25519-sha256-* 3.4. Integer Factorization Cryptography (IFC)
This key exchange method is defined in [RFC8732]. If the GSS-API is The rsa2048-sha256 key exchange method is defined in [RFC4432]. Uses
to be used with ECC algorithms, then this method SHOULD be an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange
meets 112 bit minimum security strength. This method MAY be
implemented. implemented.
3.16.13. gss-curve448-sha512-* 3.5. Secure Shell Extension Negotiation
This key exchange method is defined in [RFC8732]. If the GSS-API is
to be used with ECC algorithms, then this method MAY be implemented.
3.17. rsa1024-sha1
This key exchange method is defined in [RFC4432]. The security of
RSA 1024-bit modulus keys is not good enough any longer per
[NIST-SP-800-131Ar2], an RSA key size should be a minimum of
2048-bits. This key exchange group uses SHA-1 which has security
concerns [RFC6194]. This method MUST NOT be implemented.
3.18. rsa2048-sha256
This key exchange method is defined in [RFC4432]. An RSA 2048-bit There are two key exchange methods, ext-info-c and ext-info-s,
modulus key with a SHA2-256 hash. At the present time, a 2048-bit defined in [RFC8308] which are not actually key exchanges. They
RSA key is considered to be suffiently strong in [NIST-SP-800-131Ar2] provide a method to support other Secure Shell negotiations. Being
to be permitted. In addition, the use of a SHA-2 hash as defined in able to extend functionality is desirable. This method SHOULD be
[RFC6234] is a good integrity measure. This method MAY be
implemented. implemented.
4. Selecting an appropriate hashing algorithm 4. Summary Guidance for Key Exchange Method Names Implementations
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.
5. Summary Guidance for Key Exchange Method Names
The Implement column is the current recommendations of this RFC. Key The Implement column is the current recommendations of this RFC. Key
Exchange Method Names are listed alphabetically. Exchange Method Names are listed alphabetically.
Key Exchange Method Name Reference Implement +======================================+===========+============+
------------------------------------ --------- ---------- | Key Exchange Method Name | Reference | Implement |
curve25519-sha256 RFC8731 SHOULD +======================================+===========+============+
curve448-sha512 RFC8731 MAY | curve25519-sha256 | RFC8731 | SHOULD |
diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT +--------------------------------------+-----------+------------+
diffie-hellman-group-exchange-sha256 RFC4419 MAY | curve448-sha512 | RFC8731 | MAY |
diffie-hellman-group1-sha1 RFC4253 SHOULD NOT +--------------------------------------+-----------+------------+
diffie-hellman-group14-sha1 RFC4253 SHOULD | diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT |
diffie-hellman-group14-sha256 RFC8268 SHOULD +--------------------------------------+-----------+------------+
diffie-hellman-group15-sha512 RFC8268 MAY | diffie-hellman-group-exchange-sha256 | RFC4419 | MAY |
diffie-hellman-group16-sha512 RFC8268 MAY +--------------------------------------+-----------+------------+
diffie-hellman-group17-sha512 RFC8268 MAY | diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT |
diffie-hellman-group18-sha512 RFC8268 MAY +--------------------------------------+-----------+------------+
ecdh-sha2-* RFC5656 MAY | diffie-hellman-group14-sha1 | RFC4253 | SHOULD |
ecdh-sha2-nistp256 RFC5656 SHOULD +--------------------------------------+-----------+------------+
ecdh-sha2-nistp384 RFC5656 SHOULD | diffie-hellman-group14-sha256 | RFC8268 | MUST |
ecdh-sha2-nistp521 RFC5656 MAY +--------------------------------------+-----------+------------+
ecmqv-sha2 RFC5656 MAY | diffie-hellman-group15-sha512 | RFC8268 | MAY |
ext-info-c RFC8308 MAY +--------------------------------------+-----------+------------+
ext-info-s RFC8308 MAY | diffie-hellman-group16-sha512 | RFC8268 | SHOULD |
gss-* RFC4462 MAY +--------------------------------------+-----------+------------+
gss-curve25519-sha256-* RFC8732 SHOULD | diffie-hellman-group17-sha512 | RFC8268 | MAY |
gss-curve448-sha512-* RFC8732 MAY +--------------------------------------+-----------+------------+
gss-gex-sha1-* RFC4462 SHOULD NOT | diffie-hellman-group18-sha512 | RFC8268 | MAY |
gss-group1-sha1-* RFC4462 SHOULD NOT +--------------------------------------+-----------+------------+
gss-group14-sha256-* RFC8732 SHOULD | ecdh-sha2-* | RFC5656 | MAY |
gss-group15-sha512-* RFC8732 MAY +--------------------------------------+-----------+------------+
gss-group16-sha512-* RFC8732 MAY | ecdh-sha2-nistp256 | RFC5656 | SHOULD |
gss-group17-sha512-* RFC8732 MAY +--------------------------------------+-----------+------------+
gss-group18-sha512-* RFC8732 MAY | ecdh-sha2-nistp384 | RFC5656 | SHOULD |
gss-nistp256-sha256-* RFC8732 SHOULD +--------------------------------------+-----------+------------+
gss-nistp384-sha384-* RFC8732 SHOULD | ecdh-sha2-nistp521 | RFC5656 | SHOULD |
gss-nistp521-sha512-* RFC8732 MAY +--------------------------------------+-----------+------------+
rsa1024-sha1 RFC4432 MUST NOT | ecmqv-sha2 | RFC5656 | MAY |
rsa2048-sha256 RFC4432 MAY +--------------------------------------+-----------+------------+
| ext-info-c | RFC8308 | SHOULD |
+--------------------------------------+-----------+------------+
| ext-info-s | RFC8308 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-* | RFC4462 | MAY |
+--------------------------------------+-----------+------------+
| gss-curve25519-sha256-* | RFC8732 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-curve448-sha512-* | RFC8732 | MAY |
+--------------------------------------+-----------+------------+
| gss-gex-sha1-* | RFC4462 | SHOULD NOT |
+--------------------------------------+-----------+------------+
| gss-group1-sha1-* | RFC4462 | SHOULD NOT |
+--------------------------------------+-----------+------------+
| gss-group14-sha256-* | RFC8732 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-group15-sha512-* | RFC8732 | MAY |
+--------------------------------------+-----------+------------+
| gss-group16-sha512-* | RFC8732 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-group17-sha512-* | RFC8732 | MAY |
+--------------------------------------+-----------+------------+
| gss-group18-sha512-* | RFC8732 | MAY |
+--------------------------------------+-----------+------------+
| gss-nistp256-sha256-* | RFC8732 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-nistp384-sha384-* | RFC8732 | SHOULD |
+--------------------------------------+-----------+------------+
| gss-nistp521-sha512-* | RFC8732 | MAY |
+--------------------------------------+-----------+------------+
| rsa1024-sha1 | RFC4432 | MUST NOT |
+--------------------------------------+-----------+------------+
| rsa2048-sha256 | RFC4432 | MAY |
+--------------------------------------+-----------+------------+
Table 6: IANA guidance for key exchange method name
implementations
The full set of official [IANA-KEX] key algorithm method names not The full set of official [IANA-KEX] key algorithm method names not
otherwise mentioned in this document MAY be implemented. 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 [RFC4253] 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 [TO BE REMOVED: This registration should take place at the following
location: <http://www.iana.org/assignments/ssh-parameters/ssh- location URL: http://www.iana.org/assignments/ssh-parameters/ssh-
parameters.xhtml#ssh-parameters-16>] parameters.xhtml#ssh-parameters-16 ]
6. Acknowledgements 5. Acknowledgements
Thanks to the following people for review and comments: Denis Bider, Thanks to the following people for review and comments: Denis Bider,
Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto
Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston,
and Tero Kivinen. Tero Kivinen, and Travis Finkenauer.
Thanks to the following people for code to implement interoperable Thanks to the following people for code to implement interoperable
exchanges using some of these groups as found in an this draft: exchanges using some of these groups as found in an this draft:
Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks
to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh)
and Poderosa implementations also adopting new Diffie-Hellman groups and Poderosa implementations also adopting new Diffie-Hellman groups
based on this draft. based on this draft.
7. Security Considerations 6. Security Considerations
This SSH protocol provides a secure encrypted channel over an This SSH protocol provides a secure encrypted channel over an
insecure network. It performs server host authentication, key insecure network. It performs server host authentication, key
exchange, encryption, and integrity protection. It also derives a exchange, encryption, and integrity checks. It also derives a unique
unique session ID that may be used by higher-level protocols. session ID that may be used by higher-level protocols.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[RFC4251]. [RFC4251].
It is desirable to deprecate or remove key exchange method name that It is desirable to deprecate or remove key exchange method name that
are considered weak. A key exchange method may be weak because too are considered weak. A key exchange method may be weak because too
few bits are used, or the hashing algorithm is considered too weak. 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. 7. IANA Considerations
This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and
SHA-1 [RFC3174]. Due to recent security concerns with SHA-1
[RFC6194] and with MODP groups with less than 2048 bits
[NIST-SP-800-131Ar2], this method is no longer considered secure.
The United States Information Assurance Directorate (IAD) at the
National Security Agency (NSA) has published a FAQ
[MFQ-U-OO-815099-15] 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)
[CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is
explicitly mentioned as the minimum modulus to protect TOP SECRET
communications.
It has been observed in [safe-curves] 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 [RFC5656] 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.
8. IANA Considerations
IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be
implemented as being deprecated by this document. implemented as being deprecated by this document.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003, RFC 3526, DOI 10.17487/RFC3526, May 2003,
<https://www.rfc-editor.org/info/rfc3526>. <https://www.rfc-editor.org/info/rfc3526>.
skipping to change at page 16, line 5 skipping to change at page 13, line 23
[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell
Minimum Recommended Diffie-Hellman Modulus Size to 2048 Minimum Recommended Diffie-Hellman Modulus Size to 2048
Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,
<https://www.rfc-editor.org/info/rfc8270>. <https://www.rfc-editor.org/info/rfc8270>.
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>. 2018, <https://www.rfc-editor.org/info/rfc8308>.
9.2. Informative References 8.2. Informative References
[CNSA-SUITE]
NSA/IAD, "Commercial National Security Algorithm Suite",
September 2016, <https://apps.nsa.gov/iaarchive/programs/
iad-initiatives/cnsa-suite.cfm>.
[ECDSA-Nonce-Leak]
Mulder, E. D., Hutter, M., Marson, M. E., and P. Pearson,
"Using Bleichenbacher's Solution to the Hidden Number
Problem to Attack Nonce Leaks in 384-Bit ECDSA", IACR
Cryptology ePrint Archive 2013, August 2013,
<https://eprint.iacr.org/2013/346.pdf>.
[IANA-KEX] [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell
Internet Assigned Numbers Authority (IANA), "Secure Shell
(SSH) Protocol Parameters: Key Exchange Method Names", (SSH) Protocol Parameters: Key Exchange Method Names",
July 2020, <http://www.iana.org/assignments/ssh- July 2020, <http://www.iana.org/assignments/ssh-
parameters/ssh-parameters.xhtml#ssh-parameters-16>. parameters/ssh-parameters.xhtml#ssh-parameters-16>.
[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Beguelin, S., and P. Zimmermann, "Imperfect
Forward Secrecy: How Diffie-Hellman Fails in Practice",
ACM Conference on Computer and Communications Security
(CCS) 2015, 2015,
<https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>.
[MFQ-U-OO-815099-15]
NSA/CSS, "CNSA Suite and Quantum Computing FAQ", January
2016, <https://www.iad.gov/iad/library/ia-guidance/ia-
solutions-for-classified/algorithm-guidance/cnsa-suite-
and-quantum-computing-faq.cfm>.
[NIST-SP-800-131Ar2]
Barker, E. and A. Roginsky, "Transitions: Recommendation
for the Transitioning of the Use of Cryptographic
Algorithms and Key Lengths", NIST Special
Publication 800-131A Revision 2, March 2019,
<http://doi.org/10.6028/NIST.SP.800-131Ar2.pdf>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>. January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
<https://www.rfc-editor.org/info/rfc4419>. <https://www.rfc-editor.org/info/rfc4419>.
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
skipping to change at page 17, line 39 skipping to change at page 14, line 15
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>. <https://www.rfc-editor.org/info/rfc8731>.
[RFC8732] Sorce, S. and H. Kario, "Generic Security Service [RFC8732] Sorce, S. and H. Kario, "Generic Security Service
Application Program Interface (GSS-API) Key Exchange with Application Program Interface (GSS-API) Key Exchange with
SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
<https://www.rfc-editor.org/info/rfc8732>. <https://www.rfc-editor.org/info/rfc8732>.
[safe-curves]
Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe
curves for elliptic-curve cryptography.", February 2016,
<https://safecurves.cr.yp.to/>.
Author's Address Author's Address
Mark D. Baushke Mark D. Baushke
Juniper Networks, Inc. Juniper Networks, Inc.
Email: mdb@juniper.net Email: mdb@juniper.net
 End of changes. 84 change blocks. 
542 lines changed or deleted 361 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/