wdiff draft-ietf-curdle-ssh-kex-sha2-11.txt draft-ietf-curdle-ssh-kex-sha2-12.txt


Internet Engineering Task Force                            M. D. Baushke
Internet-Draft                                    Juniper Networks, Inc.
Updates: 4250 (if approved)                                July 13,                             23 November 2020
Intended status: Standards Track
Expires: January 14, 27 May 2021

 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
                                 (SSH)
                   draft-ietf-curdle-ssh-kex-sha2-11
                   draft-ietf-curdle-ssh-kex-sha2-12

Abstract

   This document is intended to update the recommended set of key
   exchange methods for use in the Secure Shell (SSH) protocol to meet
   evolving needs for stronger security.  This document updates RFC
   4250.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 14, 27 May 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . .   2
     1.1.  Selecting an appropriate hashing algorithm  . . . . . . .   3
   3.
     1.2.  Selecting an appropriate Public Key Exchange Methods  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  curve25519-sha256 . . . . . . . . . . . . . . . . . . . .   4
     3.2.  curve448-sha512 . . . . . Algorithm . . . . . .   3
       1.2.1.  Elliptic Curve Cryptography (ECC) . . . . . . . . . .   4
     3.3.  diffie-hellman-group-exchange-sha1
       1.2.2.  Finite Field Cryptography (FFC) . . . . . . . . . . .   4
     3.4.  diffie-hellman-group-exchange-sha256  . . . . . . . . . .   5
     3.5.  diffie-hellman-group1-sha1  . . . . . . . . .
       1.2.3.  Integer Factorization Cryptography (IFC)  . . . . . .   5
     3.6.  diffie-hellman-group14-sha1 . . . . . . . . .
   2.  Requirements Language . . . . . .   5
     3.7.  diffie-hellman-group14-sha256 . . . . . . . . . . . . . .   5
     3.8.  diffie-hellman-group15-sha512 . . . . . . . . . . . . . .   6
     3.9.  diffie-hellman-group16-sha512 . . . . .
   3.  Key Exchange Methods  . . . . . . . . .   6
     3.10. diffie-hellman-group17-sha512 . . . . . . . . . . .   5
     3.1.  SHA-1 and SHA-2 Hashing . . .   6
     3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . .   6
     3.12. ecdh-sha2-* . . . . . . . . . . .
     3.2.  Elliptic Curve Cryptography (ECC) . . . . . . . . . . . .   6
       3.12.1.  ecdh-sha2-nistp256 . . . . . . . . . . . . .
       3.2.1.  curve25519-sha256 and gss-curve25519-sha256-* . . . .   6
       3.12.2.  ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . .   7
       3.12.3.  ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . .   7
     3.13. ecmqv-sha2  . . . . . . . . . . . . . . . . .
       3.2.2.  curve448-sha512 and gss-curve448-sha512-* . . . . . .   7
     3.14. ext-info-c  . .
       3.2.3.  ECC diffie-hellman using ecdh-*, ecmqv-sha2, and
               gss-nistp*  . . . . . . . . . . . . . . . . . . . . .   7
     3.15. ext-info-s  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.16. gss-* . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.16.1.  gss-gex-sha1-* . . . . . .
     3.3.  Finite Field Cryptography (FFC) . . . . . . . . . . . . .   8
       3.16.2.  gss-group1-sha1-*  . . . . . . . . . . . . . .
       3.3.1.  FFC diffie-hellman using generated MODP groups  . . .   8
       3.16.3.  gss-group14-sha1-* . . . . . . . . . . . .
       3.3.2.  FFC diffie-hellman using named MODP groups  . . . . .   8
       3.16.4.  gss-group14-sha256-* . . . . . . . . . . . . . . . .   9
       3.16.5.  gss-group15-sha512-* . . . . . . . .
     3.4.  Integer Factorization Cryptography (IFC)  . . . . . . . .   9
       3.16.6.  gss-group16-sha512-* . . . . .
     3.5.  Secure Shell Extension Negotiation  . . . . . . . . . . .   9
       3.16.7.  gss-group17-sha512-* . . . . . . . . . . .
   4.  Summary Guidance for Key Exchange Method Names
           Implementations . . . . .   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.  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18  14

1.  Overview and Rationale

   Secure Shell (SSH) is a common protocol for secure communication on
   the Internet.  In [RFC4253], SSH originally defined two Key Exchange
   (KEX) Method Names that MUST be implemented.  Over time, time what was once
   considered secure is no longer considered secure.  The purpose of
   this RFC is to recommend that some published key exchanges be
   deprecated as well as recommending some that SHOULD and one that MUST
   be adopted.  This document updates [RFC4250].

   New

   A key exchange methods will has two components, a hashing algorithm and a public
   key algorithm.  The following subsections describe how to select each
   component.

1.1.  Selecting an appropriate hashing algorithm

   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.

   At present, the attacks against SHA-1 are collision attacks that rely
   on human help rather than a pre-image attack.  So, it is still
   possible to allow time backward compatibility use of SHA-1 during a
   SSH key-exchange for a transition to stronger hashing.  However, any
   such key exchanges should be listed last in the preference list.

   Use of the SHA-2 family of hashes found in [RFC6234] rather than the
   SHA-1 hash which is in strongly advised.

   When it comes to the process SHA-2 family of being
   deprecated Secure Hashing functions,
   SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of
   security strength; SHA2-384 has 192 bits of security strength; and
   SHA2-512 has 256 bits of security strength.  As the same compute
   power is needed for many purposes as both SHA2-224 and SHA2-256 and currently no longer providing enough security. KeX
   uses SHA2-224, it is suggested that the minimum secure hashing
   function that should be used for Key Exchange Methods is SHA2-256.

   To avoid combinatorial explosion of key exchange names, newer key
   exchanges are restricting to the use of *-sha256 and *-sha512.

1.2.  Selecting an appropriate Public Key Algorithm

   SSH uses multiple mathematically hard problems for doing Key
   Exchange.  Finite Field Cryptography (FFC) with "safe primes" for
   diffie-hellman (DH) key exchange. Exchange:

   *  Elliptic Curve Cryptography (ECC)
   using has families of curves for Key
      Exchange Methods for SSH.  NIST prime curves with names and other
      curves are available using an object identifier (OID) with
      Elliptic Curve Diffie-Hellman (ECDH) and
   the similar via [RFC5656].  Curve25519
      and Curve448 key exchanges.

   For FFC, many experts have suggested that exchanges are used with ECDH via [RFC8731].

   *  Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH)
      key exchange with "safe primes" either from a prime field of 2048-bits specified list found
      in [RFC3526] or generated dynamically via [RFC4419] as updated by
      [RFC8270].

   *  Integer Factorization Cryptography (IFC) using the RSA algorithm
      is provided for in [RFC4432].

   It is desirable for the minimum (2048-bits 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.

   It is said desirable to have select a minimum of 112 bits of security and
   3072-bits strength.
   Based on implementer security needs, a stronger minimum may be
   desired.

1.2.1.  Elliptic Curve Cryptography (ECC)

   For ECC, it is said recommended to have select one with approximately 128 bits
   of security) allowed and larger
   sizes up to 8192 security strength.

               +============+=============================+
               | Curve Name | Estimated Security Strength |
               +============+=============================+
               | nistp256   | 128 bits are considered to be much stronger.                    |
               +------------+-----------------------------+
               | nistp384   | 192 bits                    |
               +------------+-----------------------------+
               | nistp521   | 512 bits                    |
               +------------+-----------------------------+
               | Curve25519 | 128 bits                    |
               +------------+-----------------------------+
               | Curve448   | 224 bits                    |
               +------------+-----------------------------+

                     Table 1: ECC Security Strengths

1.2.2.  Finite Field Cryptography (FFC)

   For FFC, a modulus 2048 bits (112 bits of security strength).

      +==================+=============================+============+
      | 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    |
      +------------------+-----------------------------+------------+

                    Table 2: FFC MODP Security Strengths

   The minimum MODP group that MAY be used is the 2048-bit MODP group14.

   For ECC, many experts have suggested that
   Implementations SHOULD support a 256-bits curve 3072-bit MODP group or larger.

1.2.3.  Integer Factorization Cryptography (IFC)

   The only IFC algorithm for key exchange is the RSA algorithm via
   [RFC4432].  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 modulus size 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. 2048 bits.  The older SHA-1 hash is
   supposed to have about 80-bits use of a
   SHA-2 Family hash with RSA 2048-bit keys has sufficient security.  The minimum secure
   hashing function that should be used is SHA2-256 in the year of this
   RFC.

           +=====================+=============================+
           | Key Exchange Method | Estimated Security Strength |
           +=====================+=============================+
           | rsa1024-sha1        | 80 bits                     |
           +---------------------+-----------------------------+
           | rsa2048-sha256      | 112 bits                    |
           +---------------------+-----------------------------+

                      Table 3: IFC Security Strengths

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 key exchange method names in various existing
   RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
   [RFC8268], [RFC8731] [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
   Algorithms key exchange
   algorithms are to be considered for new or updated SSH
   implementations.  This document will be superseded when one or more

3.1.  SHA-1 and SHA-2 Hashing

   All of the listed algorithms are considered too weak to continue to key exchanges using the SHA-1 hashing algorithm should be
   deprecated and phased out of use
   securely, because SHA-1 has security concerns
   provided in which case they will likely be downgraded to one [RFC6194].  The SHA-2 Family of MAY,
   SHOULD NOT, or MUST NOT.  Or, when newer methods have hashes [RFC6234] is the
   only one which is more secure than SHA-1 and has been analyzed standardized
   for use with SSH key exchanges.

   diffie-hellman-group1-sha1 and found diffie-hellman-group14-sha1 are
   currently mandatory to be secure with wide enough adoption, upgrade their
   recommendation from MAY 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 or MUST.

3.1. be
   implemented and all other *-sha1 key exchanges SHOULD NOT be
   implemented.

3.2.  Elliptic Curve Cryptography (ECC)

3.2.1.  curve25519-sha256 and gss-curve25519-sha256-*

   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.  This Key Exchange Method is  These key exchange methods are
   described in [RFC8731] and [RFC8732] and is similar to the IKEv2 Key
   Agreement described in [RFC8031].  This Key Exchange Method  The curve25519-sha256 key exchange
   method has multiple implementations and SHOULD be implemented in any SSH implementation
   interested in using elliptic curve based implemented.  The
   gss-curve25519-sha256-* key exchanges.

3.2. exchange method SHOULD also be
   implemented because it shares the same performance and security
   characteristics as curve25519-sha2.

3.2.2.  curve448-sha512

   The and gss-curve448-sha512-*

   Curve448 requires provides more work security strength than Curve25519. 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.

3.3.  diffie-hellman-group-exchange-sha1

   This random selection from a set of pre-generated moduli for
   The gss-curve448-sha512-* key exchange uses SHA-1 method MAY also be implemented
   because it shares the same performance and security characteristics
   as curve448-sha512.

3.2.3.  ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp*

   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 [RFC4419].  However, SHA-1 has
   security concerns provided this name-space which SHOULD be supported.
   They appear in [RFC6194], so it would [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 better 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 use
   a name other ECDH curves using OIDs is
   specified.  These other curves MAY be implemented.

   The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms
   used by ecdh-sha2-* names.  The table provides guidance for
   implementation.

   ECDH reduces bandwidth of key exchange method which uses exchanges compared to FFC DH at a SHA-2 hash
   similar security strength.

   The following table lists algorithms as in [RFC6234] for
   integrity.  This key exchange SHOULD NOT where implementations
   may be used.

3.4.  diffie-hellman-group-exchange-sha256 more efficient or widely deployed.  The items listed as MAY
   are potentially less efficient.

                  +==========================+==========+
                  | 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      |
                  +--------------------------+----------+

                   Table 4: ECDH Implementation Guidance

   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.

3.3.  Finite Field Cryptography (FFC)

3.3.1.  FFC diffie-hellman using generated MODP groups

   This random selection from a set of pre-generated moduli for key
   exchange uses SHA2-256 as defined in [RFC4419].  [RFC8270] mandates
   implementations avoid any MODP group with 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 or P.  Otherwise, the parameter set may leak one bit of the
   shared private key secret leaving the MODP group half as strong as desired as compared with the number of
   bits. strong.  This key
   exchange MAY be used.

3.5.  diffie-hellman-group1-sha1

   This method is decribed in [RFC4253] and 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

3.3.2.  FFC diffie-hellman using named 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

   This method uses [RFC3526] group14 (a 2048-bit MODP group) which is
   still a reasonable size.  This key exchange group uses SHA-1 which
   has security concerns [RFC6194].  However, this group is still strong
   enough and is widely deployed.  This method is being moved from MUST
   to SHOULD to aid in transition to stronger SHA-2 based hashes.  This
   method will transition to SHOULD NOT when SHA-2 alternatives are more
   generally available.

3.7.

   diffie-hellman-group14-sha256

   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
   [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

   This key exchange method is defined in [RFC8268] and uses group15 (a
   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  diffie-hellman-group14-sha256 method MAY
   MUST be implemented.

3.9.  diffie-hellman-group16-sha512

   This key exchange method is defined in [RFC8268] and uses group16 (a
   4096-bit MODP group) along with a SHA-2 (SHA2-512) hash as in
   [RFC6234] for integrity.  The use rest 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 FFC MODP groups MAY be
   implemented.

3.10.  diffie-hellman-group17-sha512

   This key exchange method is defined in [RFC8268] and uses group17 (a
   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 table below provides explicit guidance by name.

               +===============================+==========+
               | Key Exchange Method Name      | Guidance |
               +===============================+==========+
               | diffie-hellman-group14-sha256 | MUST     |
               +-------------------------------+----------+
               | gss-group14-sha256-*          | SHOULD   |
               +-------------------------------+----------+
               | diffie-hellman-group15-sha512 | MAY
   be implemented.

3.11.      |
               +-------------------------------+----------+
               | 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

   This key exchange method is defined in [RFC8268] and uses group18 (a
   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-*

   This namespace allows for other curves to be defined for the elliptic
   curve Diffie Hellman key exchange.  At present, there are three
   members of this namespace They appear in [RFC5656] which are covered
   below.  This set of methods      |
               +-------------------------------+----------+
               | gss-group18-sha512-*          | MAY be implemented.

3.12.1.  ecdh-sha2-nistp256

   This key exchange method is defined in [RFC5656].  ECDH methods are
   often implemented because they are smaller and faster than using
   large      |
               +-------------------------------+----------+

                   Table 5: 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. Implementation Guidance

3.4.  Integer Factorization Cryptography (IFC)

   The SSH
   development community is divided on this and many implementations do
   exist.  If traditional ECDH key exchange methods are implemented,
   then this method SHOULD be implemented.

   It is advisable to match the ECDSA and ECDH algorithms to use the
   same curve for both.

3.12.2.  ecdh-sha2-nistp384

   This rsa2048-sha256 key exchange method is defined in [RFC5656].  This ECDH method
   should be implemented because it is smaller and faster than using
   large FFC primes [RFC4432].  Uses
   an RSA 2048-bit modulus 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
   need to be downgraded in the future along the other ECDSA NIST Prime
   curves.

3.12.3.  ecdh-sha2-nistp521

   This key exchange method is defined in [RFC5656].  This ECDH method
   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 a SHA2-256 hash.  This key exchange method is defined in [RFC5656].
   meets 112 bit minimum security strength.  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

3.5.  Secure Shell negotations.  Being able to
   extend functionality is desirable, This method SHOULD be implemented.

3.15.  ext-info-s

   This Extension Negotiation

   There are two key exchange method is methods, ext-info-c and ext-info-s,
   defined in [RFC8308].  This method is [RFC8308] which are not actually a key exchange, but proivides exchanges.  They
   provide a method to provide support
   for extensions to other Secure Shell negotations. negotiations.  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
   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-*

   This key exchange method is defined in [RFC4462].  This generated key
   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-*

   This key exchange method is defined in [RFC8732].  This key exchange
   uses the group14 (a 2048-bit MODP group) along with a SHA-2
   (SHA2-256) hash.  This represents the smallest Finite Field
   Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered
   to be secure.  It is a reasonably simple transition to move from
   SHA-1 to SHA-2.  If the GSS-API is to be used, then this method
   SHOULD be implemented.

3.16.5.  gss-group15-sha512-*

   This key exchange method is defined in [RFC8732] and uses group15 (a
   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].  If the GSS-API is to be used, then this method MAY be
   implemented.

3.16.6.  gss-group16-sha512-*

   This key exchange method is defined in [RFC8732] and uses group16 (a
   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.  If the GSS-API is to be used, then this
   method MAY be implemented.

3.16.7.  gss-group17-sha512-*

   This key exchange method is defined in [RFC8732]and uses group17 (a
   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-*

   This key exchange method is defined in [RFC8732] and uses group18 (a
   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-*

   This key exchange method is defined in [RFC8732].  If the GSS-API is
   to be used with ECC algorithms, then this method SHOULD be
   implemented.

3.16.10.  gss-nistp384-sha384-*

   This key exchange method is defined in [RFC8732].  If the GSS-API is
   to be used with ECC algorithms, then this method SHOULD be
   implemented to permit TOP SECRET information to be communicated.

3.16.11.  gss-nistp521-sha512-*

   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.16.12.  gss-curve25519-sha256-*  This key exchange method is defined in [RFC8732].  If the GSS-API is
   to be used with ECC algorithms, then this method SHOULD be
   implemented.

3.16.13.  gss-curve448-sha512-*

   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
   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-131Ar2]
   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
   implemented.

4.  Selecting an appropriate hashing algorithm

   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 Implementations

   The Implement column is the current recommendations of this RFC.  Key
   Exchange Method Names are listed alphabetically.

     +======================================+===========+============+
     | Key Exchange Method Name             | Reference | Implement
         ------------------------------------ --------- ----------  |
     +======================================+===========+============+
     | curve25519-sha256                    | RFC8731   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | curve448-sha512                      | RFC8731   | MAY        |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group-exchange-sha1   | RFC4419   | SHOULD NOT |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group-exchange-sha256 | RFC4419   | MAY        |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group1-sha1           | RFC4253   | SHOULD NOT |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group14-sha1          | RFC4253   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group14-sha256        | RFC8268   SHOULD   | MUST       |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group15-sha512        | RFC8268   | MAY        |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group16-sha512        | RFC8268   MAY   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group17-sha512        | RFC8268   | MAY        |
     +--------------------------------------+-----------+------------+
     | diffie-hellman-group18-sha512        | RFC8268   | MAY        |
     +--------------------------------------+-----------+------------+
     | ecdh-sha2-*                          | RFC5656   | MAY        |
     +--------------------------------------+-----------+------------+
     | ecdh-sha2-nistp256                   | RFC5656   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | ecdh-sha2-nistp384                   | RFC5656   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | ecdh-sha2-nistp521                   | RFC5656   MAY   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | ecmqv-sha2                           | RFC5656   | MAY        |
     +--------------------------------------+-----------+------------+
     | ext-info-c                           | RFC8308   MAY   | SHOULD     |
     +--------------------------------------+-----------+------------+
     | ext-info-s                           | RFC8308   MAY   | 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   MAY   | 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
   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
   location: <http://www.iana.org/assignments/ssh-parameters/ssh-
   parameters.xhtml#ssh-parameters-16>]

6.
   location URL: http://www.iana.org/assignments/ssh-parameters/ssh-
   parameters.xhtml#ssh-parameters-16 ]

5.  Acknowledgements

   Thanks to the following people for review and comments: Denis Bider,
   Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto
   Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston,
   and
   Tero Kivinen. Kivinen, and Travis Finkenauer.

   Thanks to the following people for code to implement interoperable
   exchanges using some of these groups as found in an this draft:
   Darren Tucker for OpenSSH and Matt Johnston for Dropbear.  And thanks
   to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh)
   and Poderosa implementations also adopting new Diffie-Hellman groups
   based on this draft.

7.

6.  Security Considerations

   This SSH protocol provides a secure encrypted channel over an
   insecure network.  It performs server host authentication, key
   exchange, encryption, and integrity protection. checks.  It also derives a unique
   session ID that may be used by higher-level protocols.

   Full security considerations for this protocol are provided in
   [RFC4251].

   It is desirable to deprecate or remove key exchange method name that
   are considered weak.  A key exchange method may be weak because too
   few bits are used, or the hashing algorithm is considered too weak.

   The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT.
   This method used [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.

7.  IANA Considerations

   IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be
   implemented as being deprecated by this document.

9.

8.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, DOI 10.17487/RFC3526, May 2003,
              <https://www.rfc-editor.org/info/rfc3526>.

   [RFC4250]  Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Assigned Numbers", RFC 4250,
              DOI 10.17487/RFC4250, January 2006,
              <https://www.rfc-editor.org/info/rfc4250>.

   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
              January 2006, <https://www.rfc-editor.org/info/rfc4253>.

   [RFC8031]  Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
              Internet Key Exchange Protocol Version 2 (IKEv2) Key
              Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
              <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-
              Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
              (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
              <https://www.rfc-editor.org/info/rfc8268>.

   [RFC8270]  Velvindron, L. and M. Baushke, "Increase the Secure Shell
              Minimum Recommended Diffie-Hellman Modulus Size to 2048
              Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,
              <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.

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] Internet Assigned Numbers Authority (IANA), "Secure Shell
              (SSH) Protocol Parameters: Key Exchange Method Names",
              July 2020, <http://www.iana.org/assignments/ssh-
              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)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4419]  Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
              Group Exchange for the Secure Shell (SSH) Transport Layer
              Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
              <https://www.rfc-editor.org/info/rfc4419>.

   [RFC4432]  Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
              Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
              March 2006, <https://www.rfc-editor.org/info/rfc4432>.

   [RFC4462]  Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
              "Generic Security Service Application Program Interface
              (GSS-API) Authentication and Key Exchange for the Secure
              Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May
              2006, <https://www.rfc-editor.org/info/rfc4462>.

   [RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
              Integration in the Secure Shell Transport Layer",
              RFC 5656, DOI 10.17487/RFC5656, December 2009,
              <https://www.rfc-editor.org/info/rfc5656>.

   [RFC6194]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
              Considerations for the SHA-0 and SHA-1 Message-Digest
              Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
              <https://www.rfc-editor.org/info/rfc6194>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <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
              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]
              Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe
              curves for elliptic-curve cryptography.", February 2016,
              <https://safecurves.cr.yp.to/>.

Author's Address

   Mark D. Baushke
   Juniper Networks, Inc.

   Email: mdb@juniper.net