Internet Engineering Task Force                            M. D. Baushke
Internet-Draft                                             6 August 2021
Updates: 4250 4253 4432 4462 (if approved)
Intended status: Standards Track
Expires: 7 February 2022


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

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, RFC 4253, RFC 4432, and RFC 4462.

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 7 February 2022.

Copyright Notice

   Copyright (c) 2021 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) 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.



Baushke                  Expires 7 February 2022                [Page 1]


Internet-Draft         KEX Method Updates for SSH            August 2021


Table of Contents

   1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   2
     1.1.  Selecting an appropriate hashing algorithm  . . . . . . .   4
     1.2.  Selecting an appropriate Public key Algorithm . . . . . .   5
       1.2.1.  Elliptic Curve Cryptography (ECC) . . . . . . . . . .   6
       1.2.2.  Finite Field Cryptography (FFC) . . . . . . . . . . .   7
       1.2.3.  Integer Factorization Cryptography (IFC)  . . . . . .   8
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   9
   3.  Key Exchange Methods  . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Elliptic Curve Cryptography (ECC) . . . . . . . . . . . .  10
       3.1.1.  curve25519-sha256 and gss-curve25519-sha256-* . . . .  10
       3.1.2.  curve448-sha512 and gss-curve448-sha512-* . . . . . .  11
       3.1.3.  ecdh-*, ecmqv-sha2, and gss-nistp*  . . . . . . . . .  11
     3.2.  Finite Field Cryptography (FFC) . . . . . . . . . . . . .  12
       3.2.1.  FFC diffie-hellman using generated MODP groups  . . .  13
       3.2.2.  FFC diffie-hellman using named MODP groups  . . . . .  13
     3.3.  Integer Factorization Cryptography (IFC)  . . . . . . . .  14
     3.4.  KDFs and Integrity Hashing  . . . . . . . . . . . . . . .  15
     3.5.  Secure Shell Extension Negotiation  . . . . . . . . . . .  16
   4.  Summary Guidance for Key Exchange Method Names
           Implementations . . . . . . . . . . . . . . . . . . . . .  16
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

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 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 or disallowed as well as recommending some that SHOULD and
   one that MUST be adopted.

   This document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by
   changing the requirement level ("MUST" moving to "SHOULD" or "MAY" or
   "SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT"
   or "MUST NOT") of various key exchange mechanisms.  Some
   recommendations will be unchanged, but are included for completeness.

   [RFC4253] section 7.2 says the following:




Baushke                  Expires 7 February 2022                [Page 2]


Internet-Draft         KEX Method Updates for SSH            August 2021


   "The key exchange produces two values: a shared secret K, and an
   exchange hash H.  Encryption and authentication keys are derived from
   these.  The exchange hash H from the first key exchange is
   additionally used as the session identifier, which is a unique
   identifier for this connection.  It is used by authentication methods
   as a part of the data that is signed as a proof of possession of a
   private key.  Once computed, the session identifier is not changed,
   even if keys are later re-exchanged."

   The security strength of the public key exchange algorithm and the
   hash used in the Key Derivation Function (KDF) both impact the
   security of the shared secret K being used.

   The hashing algorithms used by key exchange methods described in this
   document are: sha1, sha256, sha384, and sha512.  In many cases, the
   hash name is explicitly appended to the public key exchange algorithm
   name.  However, some of them are implicit and defined in the RFC that
   defines the key exchange algorithm name.

   Various RFCs use different spellings and capitalizations for the
   hashing function and encryption function names.  For the purpose of
   this document, the following are equivalent names: sha1, SHA1, and
   SHA-1; sha256, SHA256, and SHA2-256; sha384, SHA384, and SHA2-384;
   sha512, SHA512, and SHA2-512.

   For the purpose of this document, the following are equivalent:
   aes128, AES128, AES-128; aes192, AES192, and AES-192; aes256, AES256,
   and AES-256.

   It is good to try to match the security strength of the public key
   exchange algorithm with security strength of the symmetric cipher.

   There are many possible symmetric ciphers available, with multiple
   modes.  The list in Table 1 is intended as a representative sample of
   those which appear to be present in most SSH implementations.  The
   security strength estimates are generally available in [RFC4086] for
   triple-DES and AES as well as [NIST.SP.800-57pt1r5] Section 5.6.1.1.














Baushke                  Expires 7 February 2022                [Page 3]


Internet-Draft         KEX Method Updates for SSH            August 2021


         +========================+=============================+
         | Cipher Name (modes)    | Estimated Security Strength |
         +========================+=============================+
         | 3des (cbc)             | 112 bits                    |
         +------------------------+-----------------------------+
         | aes128 (cbc, ctr, gcm) | 128 bits                    |
         +------------------------+-----------------------------+
         | aes192 (cbc, ctr, gcm) | 192 bits                    |
         +------------------------+-----------------------------+
         | aes256 (cbc, ctr, gcm) | 256 bits                    |
         +------------------------+-----------------------------+

               Table 1: Symmetric Cipher Security Strengths

   The following subsections describe how to select each component of
   the key exchange.

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 and it is no longer strong
   enough for SSH security requirements.  Therefore, it is desirable to
   move away from using it before attacks become more serious.

   The SHA-1 hash provides for approximately 80 bits of security
   strength.  This means that the shared key being used has at most 80
   bits of security strength which may not be sufficient for most users.

   For purposes of key exchange methods, attacks against SHA-1 are
   collision attacks that usually rely on human help, rather than a pre-
   image attack.  SHA-1 resistance against second pre-image is still at
   160 bits, but SSH does not depend on second pre-image resistance, but
   rather on chosen-prefix collision resistance.

   Transcript Collision attacks are documented in [TRANS-COLL].  This
   paper shows that an on-path attacker does not tamper with the Diffie-
   Hellman values and does not know the connection keys.  The attack
   could be used to tamper with both I_C and I_S (as defined in section
   7.3 of [RFC4253]), and might potentially be able to downgrade the
   negotiated ciphersuite to a weak cryptographic algorithm that the
   attacker knows how to break.

   These attacks are still computationally very difficult to perform,
   but it is desirable that any key exchange using SHA-1 be phased out
   as soon as possible.




Baushke                  Expires 7 February 2022                [Page 4]


Internet-Draft         KEX Method Updates for SSH            August 2021


   If there is a need for using SHA-1 in a key exchange for
   compatibility, it would be desirable to list it last in the
   preference list of key exchanges.

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

   When it comes to the SHA-2 family of Secure Hashing functions,
   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.
   It is suggested that the minimum secure hashing function that should
   be used for key exchange methods is SHA2-256 with 128 bits of
   security strength.  Other hashing functions may also have the same
   number of bits of security strength, but none are as yet defined in
   any RFC for use in a KEX for SSH.

   To avoid combinatorial explosion of key exchange names, newer key
   exchanges are generally restricted to *-sha256 and *-sha512.  The
   exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-* which are
   defined to use SHA2-384 for the hash algorithm.

   Table 2 provides a summary of security strength for hashing functions
   for collision resistance.  You may consult [NIST.SP.800-107r1] for
   more information on hash algorithm security strength.

                +===========+=============================+
                | Hash Name | Estimated Security Strength |
                +===========+=============================+
                | sha1      | 80 bits (before attacks)    |
                +-----------+-----------------------------+
                | sha256    | 128 bits                    |
                +-----------+-----------------------------+
                | sha384    | 192 bits                    |
                +-----------+-----------------------------+
                | sha512    | 256 bits                    |
                +-----------+-----------------------------+

                     Table 2: Hashing Function Security
                                 Strengths

1.2.  Selecting an appropriate Public key Algorithm

   SSH uses mathematically hard problems for doing key exchanges:








Baushke                  Expires 7 February 2022                [Page 5]


Internet-Draft         KEX Method Updates for SSH            August 2021


   *  Elliptic Curve Cryptography (ECC) 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) via [RFC5656].  Curve25519
      and Curve448 key 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 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 that the security strength of the key exchange be
   chosen to be comparable with the security strength of the other
   elements of the SSH handshake.  Attackers can target the weakest
   element of the SSH handshake.

   It is desirable to select a minimum of 112 bits of security strength
   to match the weakest of the symmetric cipher (3des-cbc) available.
   Based on implementer security needs, a stronger minimum may be
   desired.

   The larger the MODP group, the ECC curve size, or the RSA key length,
   the more computation power will be required to perform the key
   exchange.

1.2.1.  Elliptic Curve Cryptography (ECC)

   For ECC, across all of the named curves the minimum security strength
   is approximately 128 bits.  The [RFC5656] key exchanges for the named
   curves use a hashing function with a matching security strength.
   Likewise, the [RFC8731] key exchanges use a hashing function which
   has more security strength than the curves.  The minimum strength
   will be the security strength of the curve.  Table 3 contains a
   breakdown of just the ECC security strength by curve name and not
   including the hashing algorithm used.  The curve* security level
   numbers are in [RFC7748].  The nist* numbers are in [RFC5656].  The
   hashing algorithm designated for use with the individual curves have
   approximately the same number of bits of security as the named curve.










Baushke                  Expires 7 February 2022                [Page 6]


Internet-Draft         KEX Method Updates for SSH            August 2021


               +============+=============================+
               | Curve Name | Estimated Security Strength |
               +============+=============================+
               | nistp256   | 128 bits                    |
               +------------+-----------------------------+
               | nistp384   | 192 bits                    |
               +------------+-----------------------------+
               | nistp521   | 512 bits                    |
               +------------+-----------------------------+
               | Curve25519 | 128 bits                    |
               +------------+-----------------------------+
               | Curve448   | 224 bits                    |
               +------------+-----------------------------+

                     Table 3: ECC Security Strengths

1.2.2.  Finite Field Cryptography (FFC)

   For FFC, it is recommended to use a modulus with a minimum of 2048
   bits (approximately 112 bits of security strength) with a hash that
   has at least as many bits of security as the FFC.  The security
   strength of the FFC and the hash together will be the minimum of
   those two values.  This is sufficient to provide a consistent
   security strength for the 3des-cbc cipher.  [RFC3526] section 1 notes
   that the Advanced Encryption Standard (AES) cipher, which has more
   strength, needs stronger groups.  For the 128-bit AES we need about a
   3200-bit group.  The 192 and 256-bit keys would need groups that are
   about 8000 and 15400 bits respectively.  Table 4 provides the
   security strength of the MODP group.  When paired with a hashing
   algorithm, the security strength will be the minimum of the two
   algorithms.

      +==================+=============================+============+
      | 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 4: FFC MODP Security Strengths



Baushke                  Expires 7 February 2022                [Page 7]


Internet-Draft         KEX Method Updates for SSH            August 2021


   The minimum MODP group is the 2048-bit MODP group14.  When used with
   sha1, this group provides approximately 80 bits of security.  When
   used with sha256, this group provides approximately 112 bits of
   security.  The 3des-cbc cipher itself provides at most 112 bits of
   security, so the group14-sha256 key exchanges is sufficient to keep
   all of the 3des-cbc key, for 112 bits of security.

   A 3072-bit MODP group with sha256 hash will provide approximately 128
   bits of security.  This is desirable when using a cipher such as
   aes128 or chacha20-poly1305 that provides approximately 128 bits of
   security.

   The 8192-bit group18 MODP group when used with sha512 provides
   approximately 200 bits of security which is sufficient to protect
   aes192 with 192 bits of security.

1.2.3.  Integer Factorization Cryptography (IFC)

   The only IFC algorithm for key exchange is the RSA algorithm
   specified in [RFC4432].  RSA 1024-bit keys have approximately 80 bits
   of security strength.  RSA 2048-bit keys have approximately 112 bits
   of security strength.  It is worth noting that the IFC types of key
   exchange do not provide Forward Secrecy which both FFC and ECC do
   provide.

   In order to match the 112 bits of security strength needed for 3des-
   cbc, an RSA 2048-bit key matches the security strength.  The use of a
   SHA-2 Family hash with RSA 2048-bit keys has sufficient security to
   match the 3des-cbc symmetric cipher.  The rsa1024-sha1 key exchange
   has approximately 80 bits of security strength and is not desirable.

   Table 5 summarizes the security strengths of these key exchanges
   without including the hashing algorithm strength.  Guidance for these
   strengths are in [NIST.SP.800-57pt1r5] Section 5.6.1.1.

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

                      Table 5: IFC Security Strengths







Baushke                  Expires 7 February 2022                [Page 8]


Internet-Draft         KEX Method Updates for SSH            August 2021


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 document adopts the style and conventions of [RFC4253] in
   specifying how the use of data key exchange is indicated in SSH.

   This RFC also collects key exchange method names in various existing
   RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
   [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a
   suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD
   NOT, and MUST NOT.  Any method not explicitly listed MAY be
   implemented.

   [RFC4253] section 7.2 "Output of Key Exchange" defines generation of
   a shared secret K (really the output of the KDF) and an exchange key
   hash H.  Each key exchange method uses a specified HASH function
   which must be the same for both key exchange and Key Derivation.  H
   is used for key exchange integrity across the SSH session as it is
   computed only once.  It is noted at the end of the 7.2 section that
   "This process will lose entropy if the amount of entropy in K is
   larger than the internal state size of HASH." so care must be taken
   that the hashing algorithm used is well chosen ("reasonable") for the
   key exchange algorithms being used.

   This document is intended to provide guidance as to what key exchange
   algorithms are to be considered for new or updated SSH
   implementations.

   In general, key exchange methods which are considered 'weak' are
   being moved to either deprecated ("SHOULD NOT"), or disallowed ("MUST
   NOT").  Methods which are newer or considered to be stronger usually
   require more device resources than many administrators and/or
   developers need are to be allowed ("MAY").  (Eventually, some of
   these methods could be moved by consensus to "SHOULD" to increase
   interoperability and security.)  Methods which are not 'weak' and
   have implementation consensus are encouraged ("SHOULD").  There needs
   to be at least one consensus method promoted to a mandatory to
   implement (MTI).  This should help to provide continued
   interoperability even with the loss of one of the now disallowed MTI
   methods.




Baushke                  Expires 7 February 2022                [Page 9]


Internet-Draft         KEX Method Updates for SSH            August 2021


   For this document, 112 bits of security strength is the minimum.  Use
   of either or both of SHA-1 and RSA 1024-bits at an approximate 80
   bits of security fall below this minimum and should be deprecated and
   moved to disallowed as quickly as possible in configured deployments
   of SSH.  It seems plausible that this minimum may be increased over
   time, so authors and administrators may wish to prepare for a switch
   to algorithms that provide more security strength.

3.1.  Elliptic Curve Cryptography (ECC)

   The EC key exchange algorithms used with SSH include the ECDH and EC
   Menezes-Qu-Vanstone (ecmqv).

   The ECC curves defined for the key exchange algorithms above include;
   curve25519, curve448, the NIST prime curves (nistp256, nistp384,
   nistp521) as well as other curves allowed for by [RFC5656] section 6.
   There are GSSAPI-based key-exchange mechanisms that use these curves
   as well which have a 'gss-' prefix.

3.1.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
   the patented elliptic curve parameters purchased by NIST for the
   general public to use and described in [RFC5656].  The corresponding
   key exchange methods use SHA2-256 (also known as SHA-256) defined in
   [RFC6234].  SHA2-256 is a reasonable hash for use in both the KDF and
   session integrity.  It is reasonable for both gss and non-gss uses of
   curve25519 key exchange methods.  These key exchange methods are
   described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key
   agreement described in [RFC8031].  The curve25519-sha256 key exchange
   method has multiple implementations and SHOULD be implemented.  The
   gss-curve25519-sha256-* key exchange method SHOULD also be
   implemented because it shares the same performance and security
   characteristics as curve25519-sha256.

   Table 6 contains a summary of the recommendations for curve25519
   based key exchanges.













Baushke                  Expires 7 February 2022               [Page 10]


Internet-Draft         KEX Method Updates for SSH            August 2021


                  +==========================+==========+
                  | Key Exchange Method Name | Guidance |
                  +==========================+==========+
                  | curve25519-sha256        | SHOULD   |
                  +--------------------------+----------+
                  | gss-curve25519-sha256-*  | SHOULD   |
                  +--------------------------+----------+

                     Table 6: Curve25519 Implementation
                                  Guidance

3.1.2.  curve448-sha512 and gss-curve448-sha512-*

   Curve448 provides more security strength than Curve25519 at a higher
   computational and bandwidth cost.  The corresponding key exchange
   methods use SHA2-512 (also known as SHA-512) defined in [RFC6234].
   SHA2-512 is a reasonable hash for use in both the KDF and session
   integrity.  It is reasonable for both gss and non-gss uses of
   curve448 key exchange methods.  These key exchange methods are
   described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key
   agreement described in [RFC8031].  The curve448-sha512 key exchange
   method MAY be implemented.  The gss-curve448-sha512-* key exchange
   method MAY also be implemented because it shares the same performance
   and security characteristics as curve448-sha512.

   Table 7 contains a summary of the recommendations for curve448 based
   key exchanges.

                  +==========================+==========+
                  | Key Exchange Method Name | Guidance |
                  +==========================+==========+
                  | curve448-sha512          | MAY      |
                  +--------------------------+----------+
                  | gss-curve448-sha512-*    | MAY      |
                  +--------------------------+----------+

                      Table 7: Curve448 Implementation
                                  Guidance

3.1.3.  ecdh-*, ecmqv-sha2, and gss-nistp*

   The ecdh-sha2-* name-space allows for both the named NIST prime
   curves (nistp256, nistp384, nistp521) as well as other curves to be
   defined for the Elliptic-curve Diffie-Hellman key exchange.  At the
   time of this writing, there are three named curves in this name-space
   which SHOULD be supported.  They appear in [RFC5656] in section 10.1
   ("Required Curves").  If implemented, the named curves SHOULD always
   be enabled unless specifically disabled by local security policy.  In



Baushke                  Expires 7 February 2022               [Page 11]


Internet-Draft         KEX Method Updates for SSH            August 2021


   [RFC5656], section 6.1, the method to 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.  They are described in [RFC8732].

   ECDH reduces bandwidth of key exchanges compared to FFC DH at a
   similar security strength.

   Table 8 lists algorithms as SHOULD where implementations may be more
   efficient or widely deployed.  The items listed as MAY in Table 8 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 8: 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.2.  Finite Field Cryptography (FFC)











Baushke                  Expires 7 February 2022               [Page 12]


Internet-Draft         KEX Method Updates for SSH            August 2021


3.2.1.  FFC diffie-hellman using generated MODP groups

   [RFC4419] defines two key exchange methods that use a random
   selection from a set of pre-generated moduli for key exchange: the
   diffie-hellman-group-exchange-sha1 method, and the diffie-hellman-
   group-exchange-sha256 method.  Per [RFC8270], implementations SHOULD
   use a MODP group whose modulus size is equal to or greater than 2048
   bits.  MODP groups with a modulus size less than 2048 bits are weak
   and MUST NOT be used.

   The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT
   be used.  This method uses SHA-1, which is being deprecated.

   The diffie-hellman-group-exchange-sha256 key exchange method MAY be
   used.  This method uses SHA-256, which is reasonable for MODP groups
   less than 4000 bits.

   Care should be taken in the pre-generation of the moduli P and
   generator G such that the generator provides a Q-ordered subgroup of
   P.  Otherwise, the parameter set may leak one bit of the shared
   secret.

   Table 9 provides a summary of the Guidance for these exchanges.

           +======================================+============+
           | Key Exchange Method Name             | Guidance   |
           +======================================+============+
           | diffie-hellman-group-exchange-sha1   | SHOULD NOT |
           +--------------------------------------+------------+
           | diffie-hellman-group-exchange-sha256 | MAY        |
           +--------------------------------------+------------+

              Table 9: FFC Generated MODP Group Implementation
                                  Guidance

3.2.2.  FFC diffie-hellman using named MODP groups

   The diffie-hellman-group14-sha256 key exchange method is defined in
   [RFC8268] and represents a key exchange which has approximately 112
   bits of security strength that matches 3des-cbc symmetric cipher
   security strength.  It is a reasonably simple transition from SHA-1
   to SHA-2 and given that diffie-hellman-group14-sha1 and diffie-
   hellman-group14-sha256 share a MODP group and only differ in the hash
   function used for the KDF and integrity, it is a correspondingly
   simple transition from implementing diffie-hellman-group14-sha1 to
   implementing diffie-hellman-group14-sha256.  Given that diffie-
   hellman-group14-sha1 is being removed from mandatory to implement
   (MTI) status, the diffie-hellman-group14-sha256 method MUST be



Baushke                  Expires 7 February 2022               [Page 13]


Internet-Draft         KEX Method Updates for SSH            August 2021


   implemented.  The rest of the FFC MODP group from [RFC8268] have a
   larger number of security bits and are suitable for symmetric ciphers
   that also have a similar number of security bits.

   Table 10 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      |
               +-------------------------------+----------+
               | gss-group15-sha512-*          | MAY      |
               +-------------------------------+----------+
               | diffie-hellman-group16-sha512 | SHOULD   |
               +-------------------------------+----------+
               | gss-group16-sha512-*          | MAY      |
               +-------------------------------+----------+
               | diffie-hellman-group17-sha512 | MAY      |
               +-------------------------------+----------+
               | gss-group17-sha512-*          | MAY      |
               +-------------------------------+----------+
               | diffie-hellman-group18-sha512 | MAY      |
               +-------------------------------+----------+
               | gss-group18-sha512-*          | MAY      |
               +-------------------------------+----------+

                 Table 10: FFC Named Group Implementation
                                 Guidance

3.3.  Integer Factorization Cryptography (IFC)

   The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses
   an RSA 1024-bit modulus with a SHA-1 hash.  This key exchange does
   NOT meet security requirements.  This method MUST NOT be implemented.

   The rsa2048-sha256 key exchange method is defined in [RFC4432] and
   uses an RSA 2048-bit modulus with a SHA2-256 hash.  This key exchange
   meets 112 bit minimum security strength.  This method MAY be
   implemented.

   Table 11 provide a summary of the guidance for IFC key exchanges.






Baushke                  Expires 7 February 2022               [Page 14]


Internet-Draft         KEX Method Updates for SSH            August 2021


                  +==========================+==========+
                  | Key Exchange Method Name | Guidance |
                  +==========================+==========+
                  | rsa1024-sha1             | MUST NOT |
                  +--------------------------+----------+
                  | rsa2048-sha256           | MAY      |
                  +--------------------------+----------+

                   Table 11: IFC Implementation Guidance

3.4.  KDFs and Integrity Hashing

   The SHA-1 and SHA-2 family of hashing algorithms are combined with
   the FFC, ECC, and IFC algorithms to comprise a key exchange method
   name.

   The selected hash algorithm is used both in the KDF as well as for
   the integrity of the response.

   All of the key exchange methods using the SHA-1 hashing algorithm
   should be deprecated and phased out due to security concerns for SHA-
   1, as documented in [RFC6194].

   Unconditionally deprecating and/or disallowing SHA-1 everywhere will
   hasten the day when it may be simply removed from implementations
   completely.  Leaving partially-broken algorithms lying around is not
   a good thing to do.

   The SHA-2 Family of hashes [RFC6234] is more secure than SHA-1.  They
   have been standardized for use in SSH with many of the currently
   defined key exchanges.

   Please note that at the present time, there is no key exchange method
   for Secure Shell which uses the SHA-3 family of Secure Hashing
   functions or the Extendable Output Functions.

   Prior to the changes made by this document, diffie-hellman-
   group1-sha1 and diffie-hellman-group14-sha1 were MTI.  diffie-
   hellman-group14-sha1 is the stronger of the two.  Group14 (a 2048-bit
   MODP group) is defined in [RFC3526].  The group1 MODP group with
   approximately 80 bits of security is too weak to be retained.
   However, rather than jumping from the MTI to making it disallowed,
   many implementers suggested that it should transition to deprecated
   first and be disallowed at a later time.  The group14 MODP group
   using a sha1 hash for the KDF is not as weak as the group1 MODP
   group.  There are some legacy situations where it will still provide
   administrators with value, such as small hardware IOT devices which
   have insufficient compute and memory resources to use larger MODP



Baushke                  Expires 7 February 2022               [Page 15]


Internet-Draft         KEX Method Updates for SSH            August 2021


   groups before a timeout of the session occurs.  Transitioning from
   MTI to a requirement status that provides for continued use with the
   expectation of deprecating or disallowing it in the future was able
   to find consensus.  Therefore, it is considered reasonable to retain
   the diffie-hellman-group14-sha1 exchange for interoperability with
   legacy implementations.  The diffie-hellman-group14-sha1 key exchange
   MAY be implemented, but should be put at the end of the list of
   negotiated key exchanges.

   The diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1
   SHOULD NOT be implemented.  The gss-group1-sha1-*, gss-
   group14-sha1-*, and gss-gex-sha1-* key exchanges are already
   specified as SHOULD NOT be implemented by [RFC8732].

3.5.  Secure Shell Extension Negotiation

   There are two methods, ext-info-c and ext-info-s, defined in
   [RFC8308].  They provide a mechanism to support other Secure Shell
   negotiations.  Being able to extend functionality is desirable.  Both
   ext-info-c and ext-info-s SHOULD be implemented.

4.  Summary Guidance for Key Exchange Method Names Implementations

   The Implement column is the current recommendations of this RFC.
   Table 12 provides the existing key exchange method names listed
   alphabetically.

   +==========================+===========+================+===========+
   | Key Exchange Method      | Reference | Previous       | RFCxxxxx  |
   | Name                     |           | Recommendation | Implement |
   +==========================+===========+================+===========+
   | curve25519-sha256        | RFC8731   | none           | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | curve448-sha512          | RFC8731   | none           | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-group-    | RFC4419   | none           | SHOULD    |
   | exchange-sha1            | RFC8270   |                | NOT       |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-group-    | RFC4419   | none           | MAY       |
   | exchange-sha256          | RFC8720   |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC4253   | MUST           | SHOULD    |
   | group1-sha1              |           |                | NOT       |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC4253   | MUST           | MAY       |
   | group14-sha1             |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC8268   | none           | MUST      |



Baushke                  Expires 7 February 2022               [Page 16]


Internet-Draft         KEX Method Updates for SSH            August 2021


   | group14-sha256           |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC8268   | none           | MAY       |
   | group15-sha512           |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC8268   | none           | SHOULD    |
   | group16-sha512           |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC8268   | none           | MAY       |
   | group17-sha512           |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | diffie-hellman-          | RFC8268   | none           | MAY       |
   | group18-sha512           |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | ecdh-sha2-*              | RFC5656   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | ecdh-sha2-nistp256       | RFC5656   | MUST           | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | ecdh-sha2-nistp384       | RFC5656   | MUST           | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | ecdh-sha2-nistp521       | RFC5656   | MUST           | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | ecmqv-sha2               | RFC5656   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | ext-info-c               | RFC8308   | SHOULD         | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | ext-info-s               | RFC8308   | SHOULD         | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | gss-                     | RFC4462   | reserved       | reserved  |
   +--------------------------+-----------+----------------+-----------+
   | gss-                     | RFC8732   | SHOULD         | SHOULD    |
   | curve25519-sha256-*      |           |                |           |
   +--------------------------+-----------+----------------+-----------+
   | gss-curve448-sha512-*    | RFC8732   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | gss-gex-sha1-*           | RFC4462/  | SHOULD NOT     | SHOULD    |
   |                          | RFC8732   |                | NOT       |
   +--------------------------+-----------+----------------+-----------+
   | gss-group1-sha1-*        | RFC4462/  | SHOULD NOT     | SHOULD    |
   |                          | RFC8732   |                | NOT       |
   +--------------------------+-----------+----------------+-----------+
   | gss-group14-sha1-*       | RFC4462/  | SHOULD NOT     | SHOULD    |
   |                          | RFC8732   |                | NOT       |
   +--------------------------+-----------+----------------+-----------+
   | gss-group14-sha256-*     | RFC8732   | SHOULD         | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | gss-group15-sha512-*     | RFC8732   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+



Baushke                  Expires 7 February 2022               [Page 17]


Internet-Draft         KEX Method Updates for SSH            August 2021


   | gss-group16-sha512-*     | RFC8732   | SHOULD         | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | gss-group17-sha512-*     | RFC8732   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | gss-group18-sha512-*     | RFC8732   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+
   | gss-nistp256-sha256-*    | RFC8732   | SHOULD         | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | gss-nistp384-sha384-*    | RFC8732   | MAY            | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | gss-nistp521-sha512-*    | RFC8732   | MAY            | SHOULD    |
   +--------------------------+-----------+----------------+-----------+
   | rsa1024-sha1             | RFC4432   | MAY            | MUST NOT  |
   +--------------------------+-----------+----------------+-----------+
   | rsa2048-sha256           | RFC4432   | MAY            | MAY       |
   +--------------------------+-----------+----------------+-----------+

    Table 12: 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.

   [TO BE REMOVED: This registration should take place at the following
   location URL: https://www.iana.org/assignments/ssh-parameters/ssh-
   parameters.xhtml#ssh-parameters-16 It is hoped that the Table 12 in
   section 4 of this draft provide guidance information to be merged
   into the IANA ssh-parameters-16 table.  Future RFCs may update the
   these Implementation Guidance notations.  ]

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,
   Tero Kivinen, and Travis Finkenauer.

   Thanks to the following people for code to implement interoperable
   exchanges using some of these groups as found in 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.









Baushke                  Expires 7 February 2022               [Page 18]


Internet-Draft         KEX Method Updates for SSH            August 2021


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 checks.  It also derives a unique
   session ID that may be used by higher-level protocols.  The key
   exchange itself generates a shared secret and uses the hash function
   for both the KDF and integrity.

   Full security considerations for this protocol are provided in
   [RFC4251] continue to apply.  In addition, the security
   considerations provided in [RFC4432] apply.  Note that Forward
   Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key
   exchanges.

   It is desirable to deprecate or disallow key exchange methods that
   are considered weak, so they are not in still actively in operation
   when they are broken.

   A key exchange method is considered weak when the security strength
   is insufficient to match the symmetric cipher or the algorithm has
   been broken.

   The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too
   small for the symmetric ciphers used in SSH.

   MODP groups with a modulus size less than 2048 bits are too small for
   the symmetric ciphers used in SSH.  If the diffie-hellman-group-
   exchange-sha256 or diffie-hellman-group-exchange-sha1 key exchange
   method is used, the modulus size of the MODP group used needs to be
   at least 2048 bits.

   At this time, the rsa1024-sha1 key exchange is too small for the
   symmetric ciphers used in SSH.

   The use of SHA-1 for use with any key exchange may not yet be
   completely broken, but it is time to retire all uses of this
   algorithm as soon as possible.

   The diffie-hellman-group14-sha1 algorithm is not yet completely
   deprecated.  This is to provide a practical transition from the MTI
   algorithms to a new one.  However, it would be best to only be as a
   last resort in key exchange negotiations.  All key exchange methods
   using the SHA-1 hash are to be considered as deprecated.







Baushke                  Expires 7 February 2022               [Page 19]


Internet-Draft         KEX Method Updates for SSH            August 2021


7.  IANA Considerations

   IANA is requested to add a new column to [IANA-KEX] with heading "OK
   to Implement", and to annotate entries therein with the
   implementation guidance provided in section 4 "Summary Guidance for
   Key Exchange Method Names Implementation" in this document.  A
   summary may be found in Table 12 in section 4.  IANA is additionally
   requested to include this document as an additional reference for the
   with the suggested implementation guidance provided in section 4
   "Summary Guidance for Key Exchange Method Names Implementation" in
   this document.  [IANA-KEX] registry.  Registry entries annotated with
   "MUST NOT" are considered disallowed.  Registry entries annotated
   with "SHOULD NOT" are deprecated and may be disallowed in the future.

8.  References

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

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

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






Baushke                  Expires 7 February 2022               [Page 20]


Internet-Draft         KEX Method Updates for SSH            August 2021


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

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

8.2.  Informative References

   [IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key
              Exchange Method Names", July 2021,
              <https://www.iana.org/assignments/ssh-parameters/ssh-
              parameters.xhtml#ssh-parameters-16>.

   [NIST.SP.800-107r1]
              Dang, Q., "Recommendation for applications using approved
              hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August
              2012, <https://doi.org/10.6028/NIST.SP.800-107r1>.

   [NIST.SP.800-57pt1r5]
              Barker, E., "Recommendation for Key Management - Part 1 -
              General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
              <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.

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

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/info/rfc4086>.

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



Baushke                  Expires 7 February 2022               [Page 21]


Internet-Draft         KEX Method Updates for SSH            August 2021


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

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

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

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

   [TRANS-COLL]
              Bhargavan, K. and G. Leurent, "Transcript Collision
              Attacks: Breaking Authentication in TLS, IKE, and SSH",
              Network and Distributed System Security Symposium - NDSS
              2016, Feb 2016, San Diego, United
              States. 10.14722/ndss.2016.23418 . hal-01244855,
              <https://hal.inria.fr/hal-01244855/document>.

Author's Address

   Mark D. Baushke

   Email: mbaushke.ietf@gmail.com



Baushke                  Expires 7 February 2022               [Page 22]