< draft-ietf-curdle-ssh-kex-sha2-10.txt   draft-ietf-curdle-ssh-kex-sha2-11.txt >
Internet Engineering Task Force M. Baushke Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 4250 (if approved) January 2, 2018 Updates: 4250 (if approved) July 13, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: July 6, 2018 Expires: January 14, 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-10 draft-ietf-curdle-ssh-kex-sha2-11
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 July 6, 2018. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2018 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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 . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 4
3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4
3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4
3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4
3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4 3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 5
3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 5
3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5
3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5
3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 6
3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 6
3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 6
3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6
3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 6 3.12. ecdh-sha2-* . . . . . . . . . . . . . . . . . . . . . . . 6
3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6 3.12.1. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . 6
3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6 3.12.2. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . 7
3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 7 3.12.3. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . 7
3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 7 3.13. ecmqv-sha2 . . . . . . . . . . . . . . . . . . . . . . . 7
3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 7 3.14. ext-info-c . . . . . . . . . . . . . . . . . . . . . . . 7
3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7 3.15. ext-info-s . . . . . . . . . . . . . . . . . . . . . . . 8
3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 8 3.16. gss-* . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 8 3.16.1. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . 8
3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 8 3.16.2. gss-group1-sha1-* . . . . . . . . . . . . . . . . . 8
3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 8 3.16.3. gss-group14-sha1-* . . . . . . . . . . . . . . . . . 8
3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8 3.16.4. gss-group14-sha256-* . . . . . . . . . . . . . . . . 9
3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8 3.16.5. gss-group15-sha512-* . . . . . . . . . . . . . . . . 9
3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 9 3.16.6. gss-group16-sha512-* . . . . . . . . . . . . . . . . 9
3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 9 3.16.7. gss-group17-sha512-* . . . . . . . . . . . . . . . . 9
3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 9 3.16.8. gss-group18-sha512-* . . . . . . . . . . . . . . . . 9
3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 9 3.16.9. gss-nistp256-sha256-* . . . . . . . . . . . . . . . 10
3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 9 3.16.10. gss-nistp384-sha384-* . . . . . . . . . . . . . . . 10
4. Selecting an appropriate hashing algorithm . . . . . . . . . 9 3.16.11. gss-nistp521-sha512-* . . . . . . . . . . . . . . . 10
5. Summary Guidance for Key Exchange Method Names . . . . . . . 10 3.16.12. gss-curve25519-sha256-* . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 3.16.13. gss-curve448-sha512-* . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 3.17. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 3.18. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Selecting an appropriate hashing algorithm . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 5. Summary Guidance for Key Exchange Method Names . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 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 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].
This document adds recommendations for adoption of Key Exchange New key exchange methods will use the SHA-2 family of hashes found in
Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be [RFC6234] rather than the SHA-1 hash which is in the process of being
implemented. New key exchange methods will use the SHA-2 family of deprecated for many purposes as no longer providing enough security.
hashes found in [RFC6234] and are drawn from these ssh-curves from
[I-D.ietf-curdle-ssh-curves] and DH MODP primes from the [RFC8268] SSH uses multiple mathematically hard problems for doing Key
and gss-keyex [I-D.ietf-curdle-gss-keyex-sha2]. 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 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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 3. Key Exchange Methods
This memo adopts the style and conventions of [RFC4253] in specifying This memo adopts the style and conventions of [RFC4253] in specifying
how the use of data key exchange is indicated in SSH. how the use of data key exchange is indicated in SSH.
This RFC also collects Key Exchange Method Names in various existing This RFC also collects Key Exchange Method Names in various existing
RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
[RFC8268], [I-D.ietf-curdle-gss-keyex-sha2], and [RFC8268], [RFC8731] [RFC8732], and [RFC8308], and provides a
[I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for suggested suitability for implementation of MUST, SHOULD, SHOULD NOT,
implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any method and MUST NOT. Any method not explicitly listed MAY be implemented.
not explicitly listed, MAY be implemented.
This document is intended to provide guidance as to what Key Exchange This document is intended to provide guidance as to what Key Exchange
Algorithms are to be considered for new or updated SSH Algorithms are to be considered for new or updated SSH
implementations. This document will be superseded when one or more implementations. This document will be superseded when one or more
of the listed algorithms are considered too weak to continue to use of the listed algorithms are considered too weak to continue to use
securely, in which case they will likely be downgraded to SHOULD NOT securely, in which case they will likely be downgraded to one of MAY,
or MUST NOT. Or, when newer methods have been analyzed and found to SHOULD NOT, or MUST NOT. Or, when newer methods have been analyzed
be secure with wide enough adoption to upgrade their recommendation and found to be secure with wide enough adoption, upgrade their
from MAY to SHOULD or MUST. recommendation from MAY to SHOULD or MUST.
3.1. curve25519-sha256 3.1. curve25519-sha256
The Curve25519 provides strong security and is efficient on a wide Curve25519 is efficient on a wide range of architectures with
range of architectures with properties that allow better properties that allow higher performance implementations compared to
implementation properties compared to traditional elliptic curves. traditional elliptic curves. The use of SHA2-256 (also known as
The use of SHA2-256 (also known as SHA-256) as defined in [RFC6234] SHA-256 and sha256) as defined in [RFC6234] for integrity is a
for integrity is a reasonable one for this method. This Key Exchange reasonable one for this method. This Key Exchange Method is
Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to described in [RFC8731] and is similar to the IKEv2 Key Agreement
the IKEv2 Key Agreement described in [RFC8031]. This Key Exchange described in [RFC8031]. This Key Exchange Method has multiple
Method has multiple implementations and SHOULD be implemented in any implementations and SHOULD be implemented in any SSH implementation
SSH interested in using elliptic curve based key exchanges. interested in using elliptic curve based key exchanges.
3.2. curve448-sha512 3.2. curve448-sha512
The Curve448 provides very strong security. It uses SHA2-512 (also The Curve448 requires more work than Curve25519. It uses SHA2-512
known as SHA-256) defined in [RFC6234] for integrity. It is probably (also known as SHA-512) defined in [RFC6234] for integrity. This Key
stronger and more work than is currently needed. This Key Exchange Exchange Method is described in [RFC8731] and is similar to the IKEv2
Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to Key Agreement described in [RFC8031]. This method MAY be
the IKEv2 Key Agreement described in [RFC8031]. This method MAY be
implemented. implemented.
3.3. diffie-hellman-group-exchange-sha1 3.3. diffie-hellman-group-exchange-sha1
This set of ephemerally generated key exchange groups uses SHA-1 as This random selection from a set of pre-generated moduli for key
defined in [RFC4419]. However, SHA-1 has security concerns provided exchange uses SHA-1 as defined in [RFC4419]. However, SHA-1 has
in [RFC6194], so it would be better to use a key exchange method security concerns provided in [RFC6194], so it would be better to use
which uses a SHA-2 hash as in [RFC6234] for integrity. This key a key exchange method which uses a SHA-2 hash as in [RFC6234] for
exchange SHOULD NOT be used. integrity. This key exchange SHOULD NOT be used.
3.4. diffie-hellman-group-exchange-sha256 3.4. diffie-hellman-group-exchange-sha256
This set of ephemerally generated key exchange groups uses SHA2-256 This random selection from a set of pre-generated moduli for key
as defined in [RFC4419]. [RFC8270] mandates implementations avoid exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates
any MODP group with less than 2048 bits. This key exchange MAY be implementations avoid any MODP group with less than 2048 bits. Care
used. 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.
3.5. diffie-hellman-group1-sha1 3.5. diffie-hellman-group1-sha1
This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group
2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent 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 security concerns with SHA-1 [RFC6194] and with MODP groups with less
than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar1]), this method than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar2]), this method
is considered insecure. This method is being moved from MUST to 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 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 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 still need to use this key exchange; it should be removed from server
implementations as quickly as possible. implementations as quickly as possible.
3.6. diffie-hellman-group14-sha1 3.6. diffie-hellman-group14-sha1
This method uses [RFC3526] group14 (a 2048-bit MODP group) which is This method uses [RFC3526] group14 (a 2048-bit MODP group) which is
still a reasonable size. This key exchange group uses SHA-1 which still a reasonable size. This key exchange group uses SHA-1 which
has security concerns [RFC6194]. However, this group is still strong has security concerns [RFC6194]. However, this group is still strong
enough and is widely deployed. This method is being moved from MUST 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 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 method will transition to SHOULD NOT when SHA-2 alternatives are more
generally available. generally available.
3.7. diffie-hellman-group14-sha256 3.7. diffie-hellman-group14-sha256
This key exchange method is defined in [RFC8268] and uses the group14 This key exchange method is defined in [RFC8268] and uses the group14
(a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in
[RFC6234] for integrity. This represents the smallest Finite Field [RFC6234] for integrity. This represents the smallest FFC DH key
Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered exchange method considered to be secure. It is a reasonably simple
to be secure. It is a reasonably simple transition to move from transition to move from SHA-1 to SHA-2. This method SHOULD be
SHA-1 to SHA-2. This method MUST be implemented. implemented.
3.8. diffie-hellman-group15-sha512 3.8. diffie-hellman-group15-sha512
This key exchange method is defined in [RFC8268] and uses group15 This key exchange method is defined in [RFC8268] and uses group15 (a
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
Note: The use of this 3072-bit MODP group would be equally justified [RFC6234] for integrity. This modulus is the minimum required by
to use SHA2-384 as the hash rather than SHA2-512. However, some [CNSA-SUITE]. This method MAY be implemented.
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.
3.9. diffie-hellman-group16-sha512 3.9. diffie-hellman-group16-sha512
This key exchange method is defined in [RFC8268] and uses group16 This key exchange method is defined in [RFC8268] and uses group16 (a
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
The use of FFC DH is well understood and trusted. Adding larger [RFC6234] for integrity. The use of FFC DH is well understood and
modulus sizes and protecting with SHA2-512 should give enough head trusted. Adding larger modulus sizes and protecting with SHA2-512
room to be ready for the next scare that someone has pre-computed it. should give enough head room to be ready for the next scare that
This modulus (4096-bit) is larger than that required by [CNSA-SUITE] someone has pre-computed it. This method MAY be implemented.
and should be sufficient to inter-operate with more paranoid nation-
states. This method SHOULD be implemented.
3.10. diffie-hellman-group17-sha512 3.10. diffie-hellman-group17-sha512
This key exchange method is defined in [RFC8268] and uses group17 This key exchange method is defined in [RFC8268] and uses group17 (a
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
The use of this 6144-bit MODP group is going to be slower than what [RFC6234] for integrity. The use of this 6144-bit MODP group is
may be desirable. It is provided to help those who wish to avoid going to be slower than what may be desirable. It is provided to
using ECC algorithms. This method MAY be implemented. help those who wish to avoid using ECC algorithms. This method MAY
be implemented.
3.11. diffie-hellman-group18-sha512 3.11. diffie-hellman-group18-sha512
This key exchange method is defined in [RFC8268] and uses group18 This key exchange method is defined in [RFC8268] and uses group18 (a
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
The use of this 8192-bit MODP group is going to be slower than what [RFC6234] for integrity. The use of this 8192-bit MODP group is
may be desirable. It is provided to help those who wish to avoid going to be slower than what may be desirable. It is provided to
using ECC algorithms. This method MAY be implemented. help those who wish to avoid using ECC algorithms. This method MAY
be implemented.
3.12. ecdh-sha2-nistp256 3.12. ecdh-sha2-*
This key exchange method is defined in [RFC5656]. Elliptic Curve This namespace allows for other curves to be defined for the elliptic
Diffie-Hellman (ECDH) are often implemented because they are smaller curve Diffie Hellman key exchange. At present, there are three
and faster than using large FFC primes with traditional Diffie- members of this namespace They appear in [RFC5656] which are covered
Hellman (DH). However, given [CNSA-SUITE] and [safe-curves], this below. This set of methods MAY be implemented.
curve may not be as useful and strong as desired for handling TOP
SECRET information for some applications. The SSH development 3.12.1. ecdh-sha2-nistp256
community is divided on this and many implementations do exist. If
traditional ECDH key exchange methods are implemented, then this This key exchange method is defined in [RFC5656]. ECDH methods are
method SHOULD be implemented. 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 It is advisable to match the ECDSA and ECDH algorithms to use the
same curve for both. same curve for both.
3.13. ecdh-sha2-nistp384 3.12.2. ecdh-sha2-nistp384
This key exchange method is defined in [RFC5656]. This ECDH method This key exchange method is defined in [RFC5656]. This ECDH method
should be implemented because it is smaller and faster than using should be implemented because it is smaller and faster than using
large FFC primes with traditional Diffie-Hellman (DH). Given large FFC primes with traditional DH. Given [CNSA-SUITE], it is
[CNSA-SUITE], it is considered good enough for TOP SECRET. If 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 traditional ECDH key exchange methods are implemented, then this
method SHOULD be implemented. method SHOULD be implemented.
Research into ways of breaking ECDSA continues. Papers such as Concerns raised in [safe-curves] may mean that this algorithm will
[ECDSA-Nonce-Leak] as well as concerns raised in [safe-curves] may need to be downgraded in the future along the other ECDSA NIST Prime
mean that this algorithm will need to be downgraded in the future curves.
along the other ECDSA nistp curves.
3.14. ecdh-sha2-nistp521 3.12.3. ecdh-sha2-nistp521
This key exchange method is defined in [RFC5656]. This ECDH method This key exchange method is defined in [RFC5656]. This ECDH method
may be implemented because it is smaller and faster than using large may be implemented because it is smaller and faster than using large
FFC primes with traditional Diffie-Hellman (DH). It is not listed in FFC DH parameters. It is not listed in [CNSA-SUITE], so it is not
[CNSA-SUITE], so it is not currently appropriate for TOP SECRET. It currently appropriate for TOP SECRET. It is possible that the
is possible that the mismatch between the 521-bit key and the 512-bit mismatch between the 521-bit key and the 512-bit hash could mean that
hash could mean that as many as nine bits of this key could be at as many as nine bits of this key could be at risk of leaking if
risk of leaking if appropriate padding measures are not taken. This appropriate padding measures are not taken. This method MAY be
method MAY be implemented, but is not recommended. implemented.
3.15. gss-gex-sha1-* 3.13. ecmqv-sha2
This key exchange method is defined in [RFC5656]. This method MAY be
implemented.
3.14. ext-info-c
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 This key exchange method is defined in [RFC4462]. This set of
ephemerally generated key exchange groups uses SHA-1 which has ephemerally generated key exchange groups uses SHA-1 which has
security concerns [RFC6194]. It is recommended that these key security concerns [RFC6194]. This key exchange SHOULD NOT be used.
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 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 no longer offer it. It should be removed from
server implementations as quickly as possible. server implementations as quickly as possible.
3.16. gss-group1-sha1-* 3.16.2. gss-group1-sha1-*
This key exchange method is defined in [RFC4462]. This method This key exchange method is defined in [RFC4462]. This method
suffers from the same problems of diffie-hellman-group1-sha1. It suffers from the same problems of diffie-hellman-group1-sha1. It
uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1 uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1
[RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and
with MODP groups with less than 2048 bits (see [LOGJAM] and with MODP groups with less than 2048 bits (see [LOGJAM] and
[NIST-SP-800-131Ar1]), this method is considered insecure. This [NIST-SP-800-131Ar2]), this method is considered insecure. This
method SHOULD NOT be implemented. It is intended that it move to method SHOULD NOT be implemented. It is intended that it move to
MUST NOT as soon as the majority of server implementations no longer MUST NOT as soon as the majority of server implementations no longer
offer it. It should be removed from server implementations as offer it. It should be removed from server implementations as
quickly as possible. quickly as possible.
3.17. gss-group14-sha1-* 3.16.3. gss-group14-sha1-*
This key exchange method is defined in [RFC4462]. This generated key This key exchange method is defined in [RFC4462]. This generated key
exchange groups uses SHA-1 which has security concerns [RFC6194]. If exchange groups uses SHA-1 which has security concerns [RFC6194]. If
GSS-API key exchange methods are being used, then this one SHOULD be 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 implemented until such time as SHA-2 variants may be implemented and
deployed. This method will transition to SHOULD NOT when SHA-2 deployed. This method will transition to SHOULD NOT when SHA-2
alternatives are more generally available. No other standard alternatives are more generally available. No other standard
indicated that this method was anything other than optional even indicated that this method was anything other than optional even
though it was implemented in all GSS-API systems. This method MAY be though it was implemented in all GSS-API systems. This method MAY be
implemented. implemented.
3.18. gss-group14-sha256-* 3.16.4. gss-group14-sha256-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. This key exchange
[I-D.ietf-curdle-gss-keyex-sha2]. This key exchange uses the group14 uses the group14 (a 2048-bit MODP group) along with a SHA-2
(a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash. This (SHA2-256) hash. This represents the smallest Finite Field
represents the smallest Finite Field Cryptography (FFC) Diffie- Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered
Hellman (DH) key exchange method considered to be secure. It is a to be secure. It is a reasonably simple transition to move from
reasonably simple transition to move from SHA-1 to SHA-2. If the SHA-1 to SHA-2. If the GSS-API is to be used, then this method
GSS-API is to be used, then this method SHOULD be implemented. SHOULD be implemented.
3.19. gss-group15-sha512-* 3.16.5. gss-group15-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732] and uses group15 (a
[I-D.ietf-curdle-gss-keyex-sha2]. The use of this 3072-bit MODP 3072-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
group does not really provide much additional head room over the [RFC6234] for integrity. This modulus is the minimum required by
2048-bit group14 FFC DH. If the GSS-API is to be used, then this [CNSA-SUITE]. If the GSS-API is to be used, then this method MAY be
method MAY be implemented. implemented.
3.20. gss-group16-sha512-* 3.16.6. gss-group16-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732] and uses group16 (a
[I-D.ietf-curdle-gss-keyex-sha2]. The use of FFC DH is well 4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
understood and trusted. Adding larger modulus sizes and protecting [RFC6234] for integrity. The use of FFC DH is well understood and
with SHA2-512 should give enough head room to be ready for the next trusted. Adding larger modulus sizes and protecting with SHA2-512
scare that someone has pre-computed. This modulus (4096-bit) is should give enough head room to be ready for the next scare that
larger than that required by [CNSA-SUITE] and should be sufficient to someone has pre-computed it. If the GSS-API is to be used, then this
inter-operate with more paranoid nation-states. If the GSS-API is to method MAY be implemented.
be used, then this method SHOULD be implemented.
3.21. gss-group17-sha512-* 3.16.7. gss-group17-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]and uses group17 (a
[I-D.ietf-curdle-gss-keyex-sha2]. The use of this 6144-bit MODP 6144-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
group is going to be slower than what may be desirable. It is [RFC6234] for integrity. The use of this 6144-bit MODP group is
provided to help those who wish to avoid using ECC algorithms. If going to be slower than what may be desirable. It is provided to
the GSS-API is to be used, then this method MAY be implemented. help those who wish to avoid using ECC algorithms. If the GSS-API is
to be used, then this method MAY be implemented.
3.22. gss-group18-sha512-* 3.16.8. gss-group18-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732] and uses group18 (a
[I-D.ietf-curdle-gss-keyex-sha2]. The use of this 8192-bit MODP 8192-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
group is going to be slower than what may be desirable. It is [RFC6234] for integrity. The use of this 8192-bit MODP group is
provided to help those who prefer to avoid using ECC algorithms. If going to be slower than what may be desirable. It is provided to
the GSS-API is to be used, then this method MAY be implemented. help those who wish to avoid using ECC algorithms. If the GSS-API is
to be used, then this method MAY be implemented.
3.23. gss-nistp256-sha256-* 3.16.9. gss-nistp256-sha256-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. If the GSS-API is
[I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with to be used with ECC algorithms, then this method SHOULD be
ECC algorithms, then this method SHOULD be implemented. implemented.
3.24. gss-nistp384-sha384-* 3.16.10. gss-nistp384-sha384-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. If the GSS-API is
[I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with to be used with ECC algorithms, then this method SHOULD be
ECC algorithms, then this method SHOULD be implemented to permit TOP implemented to permit TOP SECRET information to be communicated.
SECRET information to be communicated.
3.25. gss-nistp521-sha512-* 3.16.11. gss-nistp521-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. If the GSS-API is
[I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with to be used with ECC algorithms, then this method MAY be implemented.
ECC algorithms, then this method MAY be implemented.
3.26. gss-curve25519-sha256-* 3.16.12. gss-curve25519-sha256-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. If the GSS-API is
[I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with to be used with ECC algorithms, then this method SHOULD be
ECC algorithms, then this method SHOULD be implemented. implemented.
3.27. gss-curve448-sha512-* 3.16.13. gss-curve448-sha512-*
This key exchange method is defined in This key exchange method is defined in [RFC8732]. If the GSS-API is
[I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with to be used with ECC algorithms, then this method MAY be implemented.
ECC algorithms, then this method MAY be implemented.
3.28. rsa1024-sha1 3.17. rsa1024-sha1
This key exchange method is defined in [RFC4432]. The security of This key exchange method is defined in [RFC4432]. The security of
RSA 1024-bit modulus keys is not good enough any longer. A key size RSA 1024-bit modulus keys is not good enough any longer per
should be 2048-bits. This generated key exchange groups uses SHA-1 [NIST-SP-800-131Ar2], an RSA key size should be a minimum of
which has security concerns [RFC6194]. This method MUST NOT be 2048-bits. This key exchange group uses SHA-1 which has security
implemented. concerns [RFC6194]. This method MUST NOT be implemented.
3.29. rsa2048-sha256 3.18. rsa2048-sha256
This key exchange method is defined in [RFC4432]. An RSA 2048-bit This key exchange method is defined in [RFC4432]. An RSA 2048-bit
modulus key with a SHA2-256 hash. At the present time, a 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 [NIST-SP-800-131Ar1] RSA key is considered to be suffiently strong in [NIST-SP-800-131Ar2]
to be permitted. In addition, the use of a SHA-2 hash as defined in to be permitted. In addition, the use of a SHA-2 hash as defined in
[RFC6234] is a good integrity measure. This method MAY be [RFC6234] is a good integrity measure. This method MAY be
implemented. implemented.
4. Selecting an appropriate hashing algorithm 4. Selecting an appropriate hashing algorithm
As may be seen from the above, the Key Exchange Methods area all As may be seen from the above, the Key Exchange Methods area all
using either SHA256 or SHA512 with the exception of the ecdh- using either SHA256 or SHA512 with the exception of the ecdh-
sha2-nistp384 which uses SHA384. sha2-nistp384 which uses SHA384.
skipping to change at page 10, line 23 skipping to change at page 12, line 5
SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs
SHA512 is more about reducing the number of code point alternatives SHA512 is more about reducing the number of code point alternatives
to negotiate. There seemed to be consensus in favor of SHA2-512 over to negotiate. There seemed to be consensus in favor of SHA2-512 over
SHA2-384 for key exchanges. SHA2-384 for key exchanges.
5. Summary Guidance for Key Exchange Method Names 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 ssh-curves SHOULD curve25519-sha256 RFC8731 SHOULD
diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT curve448-sha512 RFC8731 MAY
diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT
diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group-exchange-sha256 RFC4419 MAY
diffie-hellman-group14-sha256 RFC8268 MUST diffie-hellman-group1-sha1 RFC4253 SHOULD NOT
diffie-hellman-group16-sha512 RFC8268 SHOULD diffie-hellman-group14-sha1 RFC4253 SHOULD
ecdh-sha2-nistp256 RFC5656 SHOULD diffie-hellman-group14-sha256 RFC8268 SHOULD
ecdh-sha2-nistp384 RFC5656 SHOULD diffie-hellman-group15-sha512 RFC8268 MAY
gss-gex-sha1-* RFC4462 SHOULD NOT diffie-hellman-group16-sha512 RFC8268 MAY
gss-group1-sha1-* RFC4462 SHOULD NOT diffie-hellman-group17-sha512 RFC8268 MAY
gss-group14-sha256-* gss-keyex SHOULD diffie-hellman-group18-sha512 RFC8268 MAY
gss-group16-sha512-* gss-keyex SHOULD ecdh-sha2-* RFC5656 MAY
gss-nistp256-sha256-* gss-keyex SHOULD ecdh-sha2-nistp256 RFC5656 SHOULD
gss-nistp384-sha384-* gss-keyex SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD
gss-curve25519-sha256-* gss-keyex SHOULD ecdh-sha2-nistp521 RFC5656 MAY
rsa1024-sha1 RFC4432 MUST NOT ecmqv-sha2 RFC5656 MAY
ext-info-c RFC8308 MAY
ext-info-s RFC8308 MAY
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 MAY
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
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 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 SHOULD NOT be used. If it is used in implementations, it should only
be provided for backwards compatibility, should not be used in new be provided for backwards compatibility, should not be used in new
designs, and should be phased out of existing key exchanges as designs, and should be phased out of existing key exchanges as
quickly as possible because of its known weaknesses. Any key quickly as possible because of its known weaknesses. Any key
exchange using SHA-1 should not be in a default key exchange list if exchange using SHA-1 should not be in a default key exchange list if
skipping to change at page 11, line 28 skipping to change at page 13, line 26
location: <http://www.iana.org/assignments/ssh-parameters/ssh- location: <http://www.iana.org/assignments/ssh-parameters/ssh-
parameters.xhtml#ssh-parameters-16>] parameters.xhtml#ssh-parameters-16>]
6. Acknowledgements 6. 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. and Tero Kivinen.
Thanks to the following people for code to implement inter-operable 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 7. 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 protection. It also derives a
unique session ID that may be used by higher-level protocols. unique 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. The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT.
This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and
SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1
[RFC6194] and with MODP groups with less than 2048 bits [RFC6194] and with MODP groups with less than 2048 bits
[NIST-SP-800-131Ar1], this method is no longer considered secure. [NIST-SP-800-131Ar2], this method is no longer considered secure.
The United States Information Assurance Directorate (IAD) at the The United States Information Assurance Directorate (IAD) at the
National Security Agency (NSA) has published a FAQ National Security Agency (NSA) has published a FAQ
[MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve
Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
less than SHA2-384 are no longer sufficient for transport of TOP 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. If your systems need to be concerned with TOP
SECRET information, then the guidance for supporting lesser security SECRET information, then the guidance for supporting lesser security
strength key exchanges may be omitted for your implementations. strength key exchanges may be omitted for your implementations.
skipping to change at page 13, line 33 skipping to change at page 15, line 33
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
Internet Key Exchange Protocol Version 2 (IKEv2) Key Internet Key Exchange Protocol Version 2 (IKEv2) Key
Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
<https://www.rfc-editor.org/info/rfc8031>. <https://www.rfc-editor.org/info/rfc8031>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
<https://www.rfc-editor.org/info/rfc8268>. <https://www.rfc-editor.org/info/rfc8268>.
[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
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>.
9.2. Informative References 9.2. Informative References
[CNSA-SUITE] [CNSA-SUITE]
"Information Assurance by the National Security Agency", NSA/IAD, "Commercial National Security Algorithm Suite",
"Commercial National Security Algorithm Suite", September September 2016, <https://apps.nsa.gov/iaarchive/programs/
2016, <https://www.iad.gov/iad/programs/iad-initiatives/ iad-initiatives/cnsa-suite.cfm>.
cnsa-suite.cfm>.
[ECDSA-Nonce-Leak] [ECDSA-Nonce-Leak]
De Mulder, Hutter, Marson, and Pearson, "Using Mulder, E. D., Hutter, M., Marson, M. E., and P. Pearson,
Bleichenbacher's Solution to the Hidden Number Problem to "Using Bleichenbacher's Solution to the Hidden Number
Attack Nonce Leaks in 384-Bit ECDSA", IACR Cryptology Problem to Attack Nonce Leaks in 384-Bit ECDSA", IACR
ePrint Archive 2013, August 2013, Cryptology ePrint Archive 2013, August 2013,
<https://eprint.iacr.org/2013/346.pdf>. <https://eprint.iacr.org/2013/346.pdf>.
[I-D.ietf-curdle-gss-keyex-sha2]
Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2",
draft-ietf-curdle-gss-keyex-sha2-03 (work in progress),
December 2017.
[I-D.ietf-curdle-ssh-curves]
Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method using Curve25519 and
Curve448", draft-ietf-curdle-ssh-curves-06 (work in
progress), November 2017.
[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",
January 2018, <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., [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J., Heninger, N., Springall, D., Green, M., Halderman, J., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Beguelin, S., and P. Zimmermann, "Imperfect Zanella-Beguelin, S., and P. Zimmermann, "Imperfect
Forward Secrecy: How Diffie-Hellman Fails in Practice", Forward Secrecy: How Diffie-Hellman Fails in Practice",
ACM Conference on Computer and Communications Security ACM Conference on Computer and Communications Security
(CCS) 2015, 2015, (CCS) 2015, 2015,
<https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>. <https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>.
[MFQ-U-OO-815099-15] [MFQ-U-OO-815099-15]
"National Security Agency/Central Security Service", "CNSA NSA/CSS, "CNSA Suite and Quantum Computing FAQ", January
Suite and Quantum Computing FAQ", January 2016, 2016, <https://www.iad.gov/iad/library/ia-guidance/ia-
<https://www.iad.gov/iad/library/ia-guidance/ solutions-for-classified/algorithm-guidance/cnsa-suite-
ia-solutions-for-classified/algorithm-guidance/ and-quantum-computing-faq.cfm>.
cnsa-suite-and-quantum-computing-faq.cfm>.
[NIST-SP-800-131Ar1] [NIST-SP-800-131Ar2]
Barker and Roginsky, "Transitions: Recommendation for the Barker, E. and A. Roginsky, "Transitions: Recommendation
Transitioning of the Use of Cryptographic Algorithms and for the Transitioning of the Use of Cryptographic
Key Lengths", NIST Special Publication 800-131A Revision Algorithms and Key Lengths", NIST Special
1, November 2015, Publication 800-131A Revision 2, March 2019,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://doi.org/10.6028/NIST.SP.800-131Ar2.pdf>.
NIST.SP.800-131Ar1.pdf>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<https://www.rfc-editor.org/info/rfc3174>. <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
skipping to change at page 15, line 48 skipping to change at page 17, line 44
[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. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>.
[RFC8732] Sorce, S. and H. Kario, "Generic Security Service
Application Program Interface (GSS-API) Key Exchange with
SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
<https://www.rfc-editor.org/info/rfc8732>.
[safe-curves] [safe-curves]
Bernstein and Lange, "SafeCurves: choosing safe curves for Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe
elliptic-curve cryptography.", February 2016, curves for elliptic-curve cryptography.", February 2016,
<https://safecurves.cr.yp.to/>. <https://safecurves.cr.yp.to/>.
Author's Address Author's Address
Mark D. Baushke Mark D. Baushke
Juniper Networks, Inc. Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089-1228
US
Email: mdb@juniper.net Email: mdb@juniper.net
URI: http://www.juniper.net/
 End of changes. 79 change blocks. 
264 lines changed or deleted 334 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/