rfc9142.original   rfc9142.txt 
Internet Engineering Task Force M. D. Baushke Internet Engineering Task Force (IETF) M. Baushke
Internet-Draft 6 August 2021 Request for Comments: 9142 January 2022
Updates: 4250 4253 4432 4462 (if approved) Updates: 4250, 4253, 4432, 4462
Intended status: Standards Track Category: Standards Track
Expires: 7 February 2022 ISSN: 2070-1721
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH) (SSH)
draft-ietf-curdle-ssh-kex-sha2-20
Abstract Abstract
This document is intended to update the recommended set of key This document updates the recommended set of key exchange methods for
exchange methods for use in the Secure Shell (SSH) protocol to meet use in the Secure Shell (SSH) protocol to meet evolving needs for
evolving needs for stronger security. This document updates RFC stronger security. It updates RFCs 4250, 4253, 4432, and 4462.
4250, RFC 4253, RFC 4432, and RFC 4462.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 February 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9142.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2 1. Overview and Rationale
1.1. Selecting an appropriate hashing algorithm . . . . . . . 4 1.1. Selecting an Appropriate Hashing Algorithm
1.2. Selecting an appropriate Public key Algorithm . . . . . . 5 1.2. Selecting an Appropriate Public Key Algorithm
1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 6 1.2.1. Elliptic Curve Cryptography (ECC)
1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 7 1.2.2. Finite Field Cryptography (FFC)
1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 8 1.2.3. Integer Factorization Cryptography (IFC)
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 9 2. Requirements Language
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 9 3. Key Exchange Methods
3.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 10 3.1. Elliptic Curve Cryptography (ECC)
3.1.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 10 3.1.1. curve25519-sha256 and gss-curve25519-sha256-*
3.1.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 11 3.1.2. curve448-sha512 and gss-curve448-sha512-*
3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* . . . . . . . . . 11 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp*
3.2. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 12 3.2. Finite Field Cryptography (FFC)
3.2.1. FFC diffie-hellman using generated MODP groups . . . 13 3.2.1. FFC Diffie-Hellman Using Generated MODP Groups
3.2.2. FFC diffie-hellman using named MODP groups . . . . . 13 3.2.2. FFC Diffie-Hellman Using Named MODP Groups
3.3. Integer Factorization Cryptography (IFC) . . . . . . . . 14 3.3. Integer Factorization Cryptography (IFC)
3.4. KDFs and Integrity Hashing . . . . . . . . . . . . . . . 15 3.4. KDFs and Integrity Hashing
3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 16 3.5. Secure Shell Extension Negotiation
4. Summary Guidance for Key Exchange Method Names 4. Summary Guidance for Implementation of Key Exchange Method
Implementations . . . . . . . . . . . . . . . . . . . . . 16 Names
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 21 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address
1. Overview and Rationale 1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined two Key Exchange the Internet. In [RFC4253], SSH originally defined two Key Exchange
(KEX) Method Names that MUST be implemented. Over time what was once (KEX) Method Names that MUST be implemented. Over time, what was
considered secure is no longer considered secure. The purpose of once considered secure is no longer considered secure. The purpose
this RFC is to recommend that some published key exchanges be of this RFC is to recommend that some published key exchanges be
deprecated or disallowed as well as recommending some that SHOULD and deprecated or disallowed as well as to recommend some that SHOULD and
one that MUST be adopted. one that MUST be adopted.
This document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by This document updates [RFC4250], [RFC4253], [RFC4432], and [RFC4462]
changing the requirement level ("MUST" moving to "SHOULD" or "MAY" or by changing the requirement level ("MUST" moving to "SHOULD", "MAY",
"SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT" or "SHOULD NOT", and "MAY" moving to "MUST", "SHOULD", "SHOULD NOT",
or "MUST NOT") of various key exchange mechanisms. Some or "MUST NOT") of various key exchange mechanisms. Some
recommendations will be unchanged, but are included for completeness. recommendations will be unchanged but are included for completeness.
[RFC4253] section 7.2 says the following: Section 7.2 of [RFC4253] says the following:
"The key exchange produces two values: a shared secret K, and an | The key exchange produces two values: a shared secret K, and an
exchange hash H. Encryption and authentication keys are derived from | exchange hash H. Encryption and authentication keys are derived
these. The exchange hash H from the first key exchange is | from these. The exchange hash H from the first key exchange is
additionally used as the session identifier, which is a unique | additionally used as the session identifier, which is a unique
identifier for this connection. It is used by authentication methods | identifier for this connection. It is used by authentication
as a part of the data that is signed as a proof of possession of a | methods as a part of the data that is signed as a proof of
private key. Once computed, the session identifier is not changed, | possession of a private key. Once computed, the session
even if keys are later re-exchanged." | identifier is not changed, even if keys are later re-exchanged.
The security strength of the public key exchange algorithm and the The security strength of the public key exchange algorithm and the
hash used in the Key Derivation Function (KDF) both impact the hash used in the Key Derivation Function (KDF) both impact the
security of the shared secret K being used. security of the shared secret K being used.
The hashing algorithms used by key exchange methods described in this The hashing algorithms used by key exchange methods described in this
document are: sha1, sha256, sha384, and sha512. In many cases, the document are: sha1, sha256, sha384, and sha512. In many cases, the
hash name is explicitly appended to the public key exchange algorithm hash name is explicitly appended to the public key exchange algorithm
name. However, some of them are implicit and defined in the RFC that name. However, some of them are implicit and defined in the RFC that
defines the key exchange algorithm name. defines the key exchange algorithm name.
Various RFCs use different spellings and capitalizations for the Various RFCs use different spellings and capitalizations for the
hashing function and encryption function names. For the purpose of hashing function and encryption function names. For the purpose of
this document, the following are equivalent names: sha1, SHA1, and this document, the following are equivalent names: sha1, SHA1, and
SHA-1; sha256, SHA256, and SHA2-256; sha384, SHA384, and SHA2-384; SHA-1; sha256, SHA256, SHA-256, and SHA2-256; sha384, SHA384, SHA-
sha512, SHA512, and SHA2-512. 384, and SHA2-384; and sha512, SHA512, SHA-512, and SHA2-512.
For the purpose of this document, the following are equivalent: For the purpose of this document, the following are equivalent:
aes128, AES128, AES-128; aes192, AES192, and AES-192; aes256, AES256, aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256,
and AES-256. AES256, and AES-256.
It is good to try to match the security strength of the public key It is good to try to match the security strength of the public key
exchange algorithm with security strength of the symmetric cipher. exchange algorithm with the security strength of the symmetric
cipher.
There are many possible symmetric ciphers available, with multiple There are many possible symmetric ciphers available with multiple
modes. The list in Table 1 is intended as a representative sample of modes. The list in Table 1 is intended as a representative sample of
those which appear to be present in most SSH implementations. The those that appear to be present in most SSH implementations. The
security strength estimates are generally available in [RFC4086] for 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. triple-DES and AES, as well as Section 5.6.1.1 of
[NIST.SP.800-57pt1r5].
+========================+=============================+ +========================+=============================+
| Cipher Name (modes) | Estimated Security Strength | | Cipher Name (modes) | Estimated Security Strength |
+========================+=============================+ +========================+=============================+
| 3des (cbc) | 112 bits | | 3des (cbc) | 112 bits |
+------------------------+-----------------------------+ +------------------------+-----------------------------+
| aes128 (cbc, ctr, gcm) | 128 bits | | aes128 (cbc, ctr, gcm) | 128 bits |
+------------------------+-----------------------------+ +------------------------+-----------------------------+
| aes192 (cbc, ctr, gcm) | 192 bits | | aes192 (cbc, ctr, gcm) | 192 bits |
+------------------------+-----------------------------+ +------------------------+-----------------------------+
| aes256 (cbc, ctr, gcm) | 256 bits | | aes256 (cbc, ctr, gcm) | 256 bits |
+------------------------+-----------------------------+ +------------------------+-----------------------------+
Table 1: Symmetric Cipher Security Strengths Table 1: Symmetric Cipher Security Strengths
The following subsections describe how to select each component of The following subsections describe how to select each component of
the key exchange. the key exchange.
1.1. Selecting an appropriate hashing algorithm 1.1. Selecting an Appropriate Hashing Algorithm
The SHA-1 hash is in the process of being deprecated for many The SHA-1 hash is in the process of being deprecated for many
reasons. reasons.
There have been attacks against SHA-1 and it is no longer strong There have been attacks against SHA-1, and it is no longer strong
enough for SSH security requirements. Therefore, it is desirable to enough for SSH security requirements. Therefore, it is desirable to
move away from using it before attacks become more serious. move away from using it before attacks become more serious.
The SHA-1 hash provides for approximately 80 bits of security The SHA-1 hash provides for approximately 80 bits of security
strength. This means that the shared key being used has at most 80 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. bits of security strength, which may not be sufficient for most
users.
For purposes of key exchange methods, attacks against SHA-1 are For purposes of key exchange methods, attacks against SHA-1 are
collision attacks that usually rely on human help, rather than a pre- collision attacks that usually rely on human help rather than a pre-
image attack. SHA-1 resistance against second pre-image is still at image attack. The SHA-1 hash resistance against a second pre-image
160 bits, but SSH does not depend on second pre-image resistance, but is still at 160 bits, but SSH does not depend on second pre-image
rather on chosen-prefix collision resistance. resistance but rather on chosen-prefix collision resistance.
Transcript Collision attacks are documented in [TRANS-COLL]. This Transcript Collision attacks are documented in [TRANSCRIPTION]. This
paper shows that an on-path attacker does not tamper with the Diffie- paper shows that an on-path attacker does not tamper with the Diffie-
Hellman values and does not know the connection keys. The attack 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 could be used to tamper with both I_C and I_S (as defined in
7.3 of [RFC4253]), and might potentially be able to downgrade the Section 7.3 of [RFC4253]) and might potentially be able to downgrade
negotiated ciphersuite to a weak cryptographic algorithm that the the negotiated ciphersuite to a weak cryptographic algorithm that the
attacker knows how to break. attacker knows how to break.
These attacks are still computationally very difficult to perform, These attacks are still computationally very difficult to perform,
but it is desirable that any key exchange using SHA-1 be phased out but it is desirable that any key exchange using SHA-1 be phased out
as soon as possible. as soon as possible.
If there is a need for using SHA-1 in a key exchange for 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 compatibility, it would be desirable to list it last in the
preference list of key exchanges. preference list of key exchanges.
Use of the SHA-2 family of hashes found in [RFC6234] rather than the Use of the SHA-2 family of hashes found in [RFC6234] rather than the
SHA-1 hash is strongly advised. SHA-1 hash is strongly advised.
When it comes to the SHA-2 family of Secure Hashing functions, 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 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. security strength; and SHA2-512 has 256 bits of security strength.
It is suggested that the minimum secure hashing function that should It is suggested that the minimum secure hashing function used for key
be used for key exchange methods is SHA2-256 with 128 bits of exchange methods should be SHA2-256 with 128 bits of security
security strength. Other hashing functions may also have the same strength. Other hashing functions may also have the same number of
number of bits of security strength, but none are as yet defined in bits of security strength, but none are as yet defined in any RFC for
any RFC for use in a KEX for SSH. use in a KEX for SSH.
To avoid combinatorial explosion of key exchange names, newer key To avoid combinatorial explosion of key exchange names, newer key
exchanges are generally restricted to *-sha256 and *-sha512. The exchanges are generally restricted to *-sha256 and *-sha512. The
exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-* which are exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*, which
defined to use SHA2-384 for the hash algorithm. are defined to use SHA2-384 (also known as SHA-384) defined in
[RFC6234] for the hash algorithm.
Table 2 provides a summary of security strength for hashing functions Table 2 provides a summary of security strength for hashing functions
for collision resistance. You may consult [NIST.SP.800-107r1] for for collision resistance. You may consult [NIST.SP.800-107r1] for
more information on hash algorithm security strength. more information on hash algorithm security strength.
+===========+=============================+ +===========+=============================+
| Hash Name | Estimated Security Strength | | Hash Name | Estimated Security Strength |
+===========+=============================+ +===========+=============================+
| sha1 | 80 bits (before attacks) | | sha1 | 80 bits (before attacks) |
+-----------+-----------------------------+ +-----------+-----------------------------+
| sha256 | 128 bits | | sha256 | 128 bits |
+-----------+-----------------------------+ +-----------+-----------------------------+
| sha384 | 192 bits | | sha384 | 192 bits |
+-----------+-----------------------------+ +-----------+-----------------------------+
| sha512 | 256 bits | | sha512 | 256 bits |
+-----------+-----------------------------+ +-----------+-----------------------------+
Table 2: Hashing Function Security Table 2: Hashing Function Security
Strengths Strengths
1.2. Selecting an appropriate Public key Algorithm 1.2. Selecting an Appropriate Public Key Algorithm
SSH uses mathematically hard problems for doing key exchanges: SSH uses mathematically hard problems for doing key exchanges:
* Elliptic Curve Cryptography (ECC) has families of curves for key * Elliptic Curve Cryptography (ECC) has families of curves for key
exchange methods for SSH. NIST prime curves with names and other exchange methods for SSH. NIST prime curves with names and other
curves are available using an object identifier (OID) with curves are available using an object identifier (OID) with
Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519
and Curve448 key exchanges are used with ECDH via [RFC8731]. and curve448 key exchanges are used with ECDH via [RFC8731].
* Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH)
key exchange with "safe primes" either from a specified list found key exchange with "safe primes" either from a specified list found
in [RFC3526] or generated dynamically via [RFC4419] as updated by in [RFC3526] or generated dynamically via [RFC4419] as updated by
[RFC8270]. [RFC8270].
* Integer Factorization Cryptography (IFC) using the RSA algorithm * Integer Factorization Cryptography (IFC) using the RSA algorithm
is provided for in [RFC4432]. is provided for in [RFC4432].
It is desirable that the security strength of the key exchange be It is desirable that the security strength of the key exchange be
chosen to be comparable with the security strength of the other chosen to be comparable with the security strength of the other
elements of the SSH handshake. Attackers can target the weakest elements of the SSH handshake. Attackers can target the weakest
element of the SSH handshake. element of the SSH handshake.
It is desirable to select a minimum of 112 bits of security strength It is desirable that a minimum of 112 bits of security strength be
to match the weakest of the symmetric cipher (3des-cbc) available. selected to match the weakest of the symmetric cipher (3des-cbc)
Based on implementer security needs, a stronger minimum may be available. Based on implementer security needs, a stronger minimum
desired. may be desired.
The larger the MODP group, the ECC curve size, or the RSA key length, The larger the Modular Exponentiation (MODP) group, the ECC curve
the more computation power will be required to perform the key size, or the RSA key length, the more computation power will be
exchange. required to perform the key exchange.
1.2.1. Elliptic Curve Cryptography (ECC) 1.2.1. Elliptic Curve Cryptography (ECC)
For ECC, across all of the named curves the minimum security strength For ECC, across all of the named curves, the minimum security
is approximately 128 bits. The [RFC5656] key exchanges for the named strength is approximately 128 bits. The [RFC5656] key exchanges for
curves use a hashing function with a matching security strength. the named curves use a hashing function with a matching security
Likewise, the [RFC8731] key exchanges use a hashing function which strength. Likewise, the [RFC8731] key exchanges use a hashing
has more security strength than the curves. The minimum strength function that has more security strength than the curves. The
will be the security strength of the curve. Table 3 contains a minimum strength will be the security strength of the curve. Table 3
breakdown of just the ECC security strength by curve name and not contains a breakdown of just the ECC security strength by curve name;
including the hashing algorithm used. The curve* security level it does include the hashing algorithm used. The curve25519 and
numbers are in [RFC7748]. The nist* numbers are in [RFC5656]. The curve488 security-level numbers are in [RFC7748]. The nistp256,
hashing algorithm designated for use with the individual curves have nistp384, and nistp521 (NIST prime curves) are provided in [RFC5656].
approximately the same number of bits of security as the named curve. The hashing algorithm designated for use with the individual curves
have approximately the same number of bits of security as the named
curve.
+============+=============================+ +============+=============================+
| Curve Name | Estimated Security Strength | | Curve Name | Estimated Security Strength |
+============+=============================+ +============+=============================+
| nistp256 | 128 bits | | nistp256 | 128 bits |
+------------+-----------------------------+ +------------+-----------------------------+
| nistp384 | 192 bits | | nistp384 | 192 bits |
+------------+-----------------------------+ +------------+-----------------------------+
| nistp521 | 512 bits | | nistp521 | 512 bits |
+------------+-----------------------------+ +------------+-----------------------------+
| Curve25519 | 128 bits | | curve25519 | 128 bits |
+------------+-----------------------------+ +------------+-----------------------------+
| Curve448 | 224 bits | | curve448 | 224 bits |
+------------+-----------------------------+ +------------+-----------------------------+
Table 3: ECC Security Strengths Table 3: ECC Security Strengths
1.2.2. Finite Field Cryptography (FFC) 1.2.2. Finite Field Cryptography (FFC)
For FFC, it is recommended to use a modulus with a minimum of 2048 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 bits (approximately 112 bits of security strength) with a hash that
has at least as many bits of security as the FFC. The security 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 strength of the FFC and the hash together will be the minimum of
those two values. This is sufficient to provide a consistent those two values. This is sufficient to provide a consistent
security strength for the 3des-cbc cipher. [RFC3526] section 1 notes security strength for the 3des-cbc cipher. Section 1 of [RFC3526]
that the Advanced Encryption Standard (AES) cipher, which has more notes that the Advanced Encryption Standard (AES) cipher, which has
strength, needs stronger groups. For the 128-bit AES we need about a more strength, needs stronger groups. For the 128-bit AES, we need
3200-bit group. The 192 and 256-bit keys would need groups that are about a 3200-bit group. The 192- and 256-bit keys would need groups
about 8000 and 15400 bits respectively. Table 4 provides the that are about 8000 and 15400 bits, respectively. Table 4 provides
security strength of the MODP group. When paired with a hashing the security strength of the MODP group. When paired with a hashing
algorithm, the security strength will be the minimum of the two algorithm, the security strength will be the minimum of the two
algorithms. algorithms.
+==================+=============================+============+ +==================+=============================+============+
| Prime Field Size | Estimated Security Strength | Example | | Prime Field Size | Estimated Security Strength | Example |
| | | MODP Group | | | | MODP Group |
+==================+=============================+============+ +==================+=============================+============+
| 2048-bit | 112 bits | group14 | | 2048-bit | 112 bits | group14 |
+------------------+-----------------------------+------------+ +------------------+-----------------------------+------------+
| 3072-bit | 128 bits | group15 | | 3072-bit | 128 bits | group15 |
skipping to change at page 8, line 6 skipping to change at line 322
| 4096-bit | 152 bits | group16 | | 4096-bit | 152 bits | group16 |
+------------------+-----------------------------+------------+ +------------------+-----------------------------+------------+
| 6144-bit | 176 bits | group17 | | 6144-bit | 176 bits | group17 |
+------------------+-----------------------------+------------+ +------------------+-----------------------------+------------+
| 8192-bit | 200 bits | group18 | | 8192-bit | 200 bits | group18 |
+------------------+-----------------------------+------------+ +------------------+-----------------------------+------------+
Table 4: FFC MODP Security Strengths Table 4: FFC MODP Security Strengths
The minimum MODP group is the 2048-bit MODP group14. When used with The minimum MODP group is the 2048-bit MODP group14. When used with
sha1, this group provides approximately 80 bits of security. When a SHA-1 hash, this group provides approximately 80 bits of security.
used with sha256, this group provides approximately 112 bits of When used with a SHA2-256 hash, this group provides approximately 112
security. The 3des-cbc cipher itself provides at most 112 bits of bits of security. The 3des-cbc cipher itself provides at most 112
security, so the group14-sha256 key exchanges is sufficient to keep bits of security, so the group14-sha256 key exchanges is sufficient
all of the 3des-cbc key, for 112 bits of security. 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 A 3072-bit MODP group when used with a SHA2-256 hash will provide
bits of security. This is desirable when using a cipher such as approximately 128 bits of security. This is desirable when using a
aes128 or chacha20-poly1305 that provides approximately 128 bits of cipher such as aes128 or chacha20-poly1305 that provides
security. approximately 128 bits of security.
The 8192-bit group18 MODP group when used with sha512 provides The 8192-bit group18 MODP group when used with sha512 provides
approximately 200 bits of security which is sufficient to protect approximately 200 bits of security, which is sufficient to protect
aes192 with 192 bits of security. aes192 with 192 bits of security.
1.2.3. Integer Factorization Cryptography (IFC) 1.2.3. Integer Factorization Cryptography (IFC)
The only IFC algorithm for key exchange is the RSA algorithm The only IFC algorithm for key exchange is the RSA algorithm
specified in [RFC4432]. RSA 1024-bit keys have approximately 80 bits 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. RSA 2048-bit keys have approximately 112 bits
of security strength. It is worth noting that the IFC types of key 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 exchange do not provide Forward Secrecy, which both FFC and ECC do
provide. provide.
In order to match the 112 bits of security strength needed for 3des- 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 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 SHA-2 family hash with RSA 2048-bit keys has sufficient security to
match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange
has approximately 80 bits of security strength and is not desirable. has approximately 80 bits of security strength and is not desirable.
Table 5 summarizes the security strengths of these key exchanges Table 5 summarizes the security strengths of these key exchanges
without including the hashing algorithm strength. Guidance for these without including the hashing algorithm strength. Guidance for these
strengths are in [NIST.SP.800-57pt1r5] Section 5.6.1.1. strengths can be found in Section 5.6.1.1 of [NIST.SP.800-57pt1r5].
+=====================+=============================+ +=====================+=============================+
| Key Exchange Method | Estimated Security Strength | | Key Exchange Method | Estimated Security Strength |
+=====================+=============================+ +=====================+=============================+
| rsa1024-sha1 | 80 bits | | rsa1024-sha1 | 80 bits |
+---------------------+-----------------------------+ +---------------------+-----------------------------+
| rsa2048-sha256 | 112 bits | | rsa2048-sha256 | 112 bits |
+---------------------+-----------------------------+ +---------------------+-----------------------------+
Table 5: IFC Security Strengths Table 5: IFC Security Strengths
skipping to change at page 9, line 19 skipping to change at line 380
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Key Exchange Methods 3. Key Exchange Methods
This document adopts the style and conventions of [RFC4253] in This document adopts the style and conventions of [RFC4253] in
specifying how the use of data key exchange is indicated in SSH. specifying how the use of data key exchange is indicated in SSH.
This RFC also collects key exchange method names in various existing This RFC also collects key exchange method names in various existing
RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], RFCs ([RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
[RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a [RFC8268], [RFC8308], [RFC8731], and [RFC8732]) and provides a
suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD
NOT, and MUST NOT. Any method not explicitly listed MAY be NOT, and MUST NOT. Any method not explicitly listed MAY be
implemented. implemented.
[RFC4253] section 7.2 "Output of Key Exchange" defines generation of Section 7.2 of [RFC4253] defines the generation of a shared secret K
a shared secret K (really the output of the KDF) and an exchange key (really the output of the KDF) and an exchange key hash H. Each key
hash H. Each key exchange method uses a specified HASH function exchange method uses a specified HASH function, which must be the
which must be the same for both key exchange and Key Derivation. H same for both key exchange and Key Derivation. H is used for key
is used for key exchange integrity across the SSH session as it is exchange integrity across the SSH session as it is computed only
computed only once. It is noted at the end of the 7.2 section that once. It is noted at the end of Section 7.2 of [RFC4253] 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 | This process will lose entropy if the amount of entropy in K is
algorithms are to be considered for new or updated SSH | larger than the internal state size of HASH.
implementations.
In general, key exchange methods which are considered 'weak' are So, care must be taken that the hashing algorithm used is well chosen
being moved to either deprecated ("SHOULD NOT"), or disallowed ("MUST ("reasonable") for the key exchange algorithms being used.
NOT"). Methods which are newer or considered to be stronger usually
require more device resources than many administrators and/or This document provides guidance as to what key exchange algorithms
developers need are to be allowed ("MAY"). (Eventually, some of are to be considered for new or updated SSH implementations.
these methods could be moved by consensus to "SHOULD" to increase
interoperability and security.) Methods which are not 'weak' and In general, key exchange methods that are considered "weak" are being
have implementation consensus are encouraged ("SHOULD"). There needs moved to either deprecated ("SHOULD NOT") or disallowed ("MUST NOT").
to be at least one consensus method promoted to a mandatory to Methods that are newer or considered to be stronger usually require
implement (MTI). This should help to provide continued more device resources than many administrators and/or developers need
interoperability even with the loss of one of the now disallowed MTI are to be allowed ("MAY"). (Eventually, some of these methods could
methods. be moved by consensus to "SHOULD" to increase interoperability and
security.) Methods that are not "weak" and have implementation
consensus are encouraged ("SHOULD"). There needs to be at least one
consensus method promoted to a status of mandatory to implement
(MTI). This should help to provide continued interoperability even
with the loss of one of the now disallowed MTI methods.
For this document, 112 bits of security strength is the minimum. Use 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 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 bits of security fall below this minimum and should be deprecated and
moved to disallowed as quickly as possible in configured deployments moved to disallowed as quickly as possible in configured deployments
of SSH. It seems plausible that this minimum may be increased over of SSH. It seems plausible that this minimum may be increased over
time, so authors and administrators may wish to prepare for a switch time, so authors and administrators may wish to prepare for a switch
to algorithms that provide more security strength. to algorithms that provide more security strength.
3.1. Elliptic Curve Cryptography (ECC) 3.1. Elliptic Curve Cryptography (ECC)
The EC key exchange algorithms used with SSH include the ECDH and EC The Elliptic Curve (EC) key exchange algorithms used with SSH include
Menezes-Qu-Vanstone (ecmqv). the ECDH and EC Menezes-Qu-Vanstone (ECMQV).
The ECC curves defined for the key exchange algorithms above include; The ECC curves defined for the key exchange algorithms above include
curve25519, curve448, the NIST prime curves (nistp256, nistp384, the following: curve25519, curve448, the NIST prime curves (nistp256,
nistp521) as well as other curves allowed for by [RFC5656] section 6. nistp384, and nistp521), as well as other curves allowed for by
There are GSSAPI-based key-exchange mechanisms that use these curves Section 6 of [RFC5656]. There are key exchange mechanisms based on
as well which have a 'gss-' prefix. the Generic Security Service Application Program Interface (GSS-API)
that use these curves as well that have a "gss-" prefix.
3.1.1. curve25519-sha256 and gss-curve25519-sha256-* 3.1.1. curve25519-sha256 and gss-curve25519-sha256-*
Curve25519 is efficient on a wide range of architectures with Curve25519 is efficient on a wide range of architectures with
properties that allow higher performance implementations compared to properties that allow higher-performance implementations compared to
the patented elliptic curve parameters purchased by NIST for the the patented elliptic curve parameters purchased by NIST for the
general public to use and described in [RFC5656]. The corresponding general public to use as described in [RFC5656]. The corresponding
key exchange methods use SHA2-256 (also known as SHA-256) defined in 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 [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 session integrity. It is reasonable for both gss and non-gss uses of
curve25519 key exchange methods. These key exchange methods are curve25519 key exchange methods. These key exchange methods are
described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key
agreement described in [RFC8031]. The curve25519-sha256 key exchange agreement described in [RFC8031]. The curve25519-sha256 key exchange
method has multiple implementations and SHOULD be implemented. The method has multiple implementations and SHOULD be implemented. The
gss-curve25519-sha256-* key exchange method SHOULD also be gss-curve25519-sha256-* key exchange method SHOULD also be
implemented because it shares the same performance and security implemented because it shares the same performance and security
characteristics as curve25519-sha256. characteristics as curve25519-sha256.
Table 6 contains a summary of the recommendations for curve25519 Table 6 contains a summary of the recommendations for
based key exchanges. curve25519-based key exchanges.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
| curve25519-sha256 | SHOULD | | curve25519-sha256 | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
| gss-curve25519-sha256-* | SHOULD | | gss-curve25519-sha256-* | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
Table 6: Curve25519 Implementation Table 6: Curve25519 Implementation
Guidance Guidance
3.1.2. curve448-sha512 and gss-curve448-sha512-* 3.1.2. curve448-sha512 and gss-curve448-sha512-*
Curve448 provides more security strength than Curve25519 at a higher Curve448 provides more security strength than curve25519 at a higher
computational and bandwidth cost. The corresponding key exchange computational and bandwidth cost. The corresponding key exchange
methods use SHA2-512 (also known as SHA-512) defined in [RFC6234]. 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 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 integrity. It is reasonable for both gss and non-gss uses of
curve448 key exchange methods. These key exchange methods are curve448 key exchange methods. These key exchange methods are
described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key
agreement described in [RFC8031]. The curve448-sha512 key exchange agreement described in [RFC8031]. The curve448-sha512 key exchange
method MAY be implemented. The gss-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 method MAY also be implemented because it shares the same performance
and security characteristics as curve448-sha512. and security characteristics as curve448-sha512.
Table 7 contains a summary of the recommendations for curve448 based Table 7 contains a summary of the recommendations for curve448-based
key exchanges. key exchanges.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
| curve448-sha512 | MAY | | curve448-sha512 | MAY |
+--------------------------+----------+ +--------------------------+----------+
| gss-curve448-sha512-* | MAY | | gss-curve448-sha512-* | MAY |
+--------------------------+----------+ +--------------------------+----------+
Table 7: Curve448 Implementation Table 7: Curve448 Implementation
Guidance Guidance
3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp*
The ecdh-sha2-* name-space allows for both the named NIST prime The ecdh-sha2-* namespace allows for both the named NIST prime curves
curves (nistp256, nistp384, nistp521) as well as other curves to be (nistp256, nistp384, and nistp521) as well as other curves to be
defined for the Elliptic-curve Diffie-Hellman key exchange. At the defined for the ECDH key exchange. At the time of this writing,
time of this writing, there are three named curves in this name-space there are three named curves in this namespace that SHOULD be
which SHOULD be supported. They appear in [RFC5656] in section 10.1 supported. They appear in Section 10.1 of [RFC5656]. If
("Required Curves"). If implemented, the named curves SHOULD always implemented, the named curves SHOULD always be enabled unless
be enabled unless specifically disabled by local security policy. In specifically disabled by local security policy. In Section 6.1 of
[RFC5656], the method to name other ECDH curves using OIDs is
[RFC5656], section 6.1, the method to name other ECDH curves using specified. These other curves MAY be implemented.
OIDs is specified. These other curves MAY be implemented.
The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms The GSS-API namespace with gss-nistp*-sha* mirrors the algorithms
used by ecdh-sha2-* names. They are described in [RFC8732]. used by ecdh-sha2-* names. They are described in [RFC8732].
ECDH reduces bandwidth of key exchanges compared to FFC DH at a ECDH reduces bandwidth of key exchanges compared to FFC DH at a
similar security strength. similar security strength.
Table 8 lists algorithms as SHOULD where implementations may be more Table 8 lists algorithms as "SHOULD" where implementations may be
efficient or widely deployed. The items listed as MAY in Table 8 are more efficient or widely deployed. The items listed as "MAY" in
potentially less efficient. Table 8 are potentially less efficient.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
| ecdh-sha2-* | MAY | | ecdh-sha2-* | MAY |
+--------------------------+----------+ +--------------------------+----------+
| ecdh-sha2-nistp256 | SHOULD | | ecdh-sha2-nistp256 | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
| gss-nistp256-sha256-* | SHOULD | | gss-nistp256-sha256-* | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
skipping to change at page 12, line 40 skipping to change at line 537
+--------------------------+----------+ +--------------------------+----------+
| ecdh-sha2-nistp521 | SHOULD | | ecdh-sha2-nistp521 | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
| gss-nistp521-sha512-* | SHOULD | | gss-nistp521-sha512-* | SHOULD |
+--------------------------+----------+ +--------------------------+----------+
| ecmqv-sha2 | MAY | | ecmqv-sha2 | MAY |
+--------------------------+----------+ +--------------------------+----------+
Table 8: ECDH Implementation Guidance Table 8: ECDH Implementation Guidance
It is advisable to match the ECDSA and ECDH algorithms to use the It is advisable to match the Elliptic Curve Digital Signature
same curve for both to maintain the same security strength in the Algorithm (ECDSA) and ECDH algorithm to use the same curve for both
connection. to maintain the same security strength in the connection.
3.2. Finite Field Cryptography (FFC) 3.2. Finite Field Cryptography (FFC)
3.2.1. FFC diffie-hellman using generated MODP groups
3.2.1. FFC Diffie-Hellman Using Generated MODP Groups
[RFC4419] defines two key exchange methods that use a random [RFC4419] defines two key exchange methods that use a random
selection from a set of pre-generated moduli for key exchange: the selection from a set of pre-generated moduli for key exchange: the
diffie-hellman-group-exchange-sha1 method, and the diffie-hellman- diffie-hellman-group-exchange-sha1 method and the diffie-hellman-
group-exchange-sha256 method. Per [RFC8270], implementations SHOULD group-exchange-sha256 method. Per [RFC8270], implementations SHOULD
use a MODP group whose modulus size is equal to or greater than 2048 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 bits. MODP groups with a modulus size less than 2048 bits are weak
and MUST NOT be used. and MUST NOT be used.
The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT
be used. This method uses SHA-1, which is being deprecated. be used. This method uses SHA-1, which is being deprecated.
The diffie-hellman-group-exchange-sha256 key exchange method MAY be The diffie-hellman-group-exchange-sha256 key exchange method MAY be
used. This method uses SHA-256, which is reasonable for MODP groups used. This method uses SHA2-256, which is reasonable for MODP groups
less than 4000 bits. less than 4096 bits.
Care should be taken in the pre-generation of the moduli P and 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 generator G such that the generator provides a Q-ordered subgroup of
P. Otherwise, the parameter set may leak one bit of the shared P. Otherwise, the parameter set may leak one bit of the shared
secret. secret.
Table 9 provides a summary of the Guidance for these exchanges. Table 9 provides a summary of the guidance for these exchanges.
+======================================+============+ +======================================+============+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+======================================+============+ +======================================+============+
| diffie-hellman-group-exchange-sha1 | SHOULD NOT | | diffie-hellman-group-exchange-sha1 | SHOULD NOT |
+--------------------------------------+------------+ +--------------------------------------+------------+
| diffie-hellman-group-exchange-sha256 | MAY | | diffie-hellman-group-exchange-sha256 | MAY |
+--------------------------------------+------------+ +--------------------------------------+------------+
Table 9: FFC Generated MODP Group Implementation Table 9: FFC Generated MODP Group Implementation
Guidance Guidance
3.2.2. FFC diffie-hellman using named MODP groups 3.2.2. FFC Diffie-Hellman Using Named MODP Groups
The diffie-hellman-group14-sha256 key exchange method is defined in The diffie-hellman-group14-sha256 key exchange method is defined in
[RFC8268] and represents a key exchange which has approximately 112 [RFC8268] and represents a key exchange that has approximately 112
bits of security strength that matches 3des-cbc symmetric cipher bits of security strength that matches 3des-cbc symmetric cipher
security strength. It is a reasonably simple transition from SHA-1 security strength. It is a reasonably simple transition from SHA-1
to SHA-2 and given that diffie-hellman-group14-sha1 and diffie- 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 hellman-group14-sha256 share a MODP group and only differ in the hash
function used for the KDF and integrity, it is a correspondingly function used for the KDF and integrity, it is a correspondingly
simple transition from implementing diffie-hellman-group14-sha1 to simple transition from implementing diffie-hellman-group14-sha1 to
implementing diffie-hellman-group14-sha256. Given that diffie- implementing diffie-hellman-group14-sha256. Given that diffie-
hellman-group14-sha1 is being removed from mandatory to implement hellman-group14-sha1 is being removed from mandatory to implement
(MTI) status, the diffie-hellman-group14-sha256 method MUST be (MTI) status, the diffie-hellman-group14-sha256 method MUST be
implemented. The rest of the FFC MODP group from [RFC8268] have a implemented. The rest of the FFC MODP group from [RFC8268] have a
larger number of security bits and are suitable for symmetric ciphers larger number of security bits and are suitable for symmetric ciphers
that also have a similar number of security bits. that also have a similar number of security bits.
Table 10 below provides explicit guidance by name. Table 10 provides explicit guidance by name.
+===============================+==========+ +===============================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+===============================+==========+ +===============================+==========+
| diffie-hellman-group14-sha256 | MUST | | diffie-hellman-group14-sha256 | MUST |
+-------------------------------+----------+ +-------------------------------+----------+
| gss-group14-sha256-* | SHOULD | | gss-group14-sha256-* | SHOULD |
+-------------------------------+----------+ +-------------------------------+----------+
| diffie-hellman-group15-sha512 | MAY | | diffie-hellman-group15-sha512 | MAY |
+-------------------------------+----------+ +-------------------------------+----------+
skipping to change at page 14, line 45 skipping to change at line 632
Guidance Guidance
3.3. Integer Factorization Cryptography (IFC) 3.3. Integer Factorization Cryptography (IFC)
The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses 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 an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does
NOT meet security requirements. This method MUST NOT be implemented. NOT meet security requirements. This method MUST NOT be implemented.
The rsa2048-sha256 key exchange method is defined in [RFC4432] and 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 uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange
meets 112 bit minimum security strength. This method MAY be meets 112-bit minimum security strength. This method MAY be
implemented. implemented.
Table 11 provide a summary of the guidance for IFC key exchanges. Table 11 provides a summary of the guidance for IFC key exchanges.
+==========================+==========+ +==========================+==========+
| Key Exchange Method Name | Guidance | | Key Exchange Method Name | Guidance |
+==========================+==========+ +==========================+==========+
| rsa1024-sha1 | MUST NOT | | rsa1024-sha1 | MUST NOT |
+--------------------------+----------+ +--------------------------+----------+
| rsa2048-sha256 | MAY | | rsa2048-sha256 | MAY |
+--------------------------+----------+ +--------------------------+----------+
Table 11: IFC Implementation Guidance Table 11: IFC Implementation Guidance
skipping to change at page 15, line 30 skipping to change at line 662
The selected hash algorithm is used both in the KDF as well as for The selected hash algorithm is used both in the KDF as well as for
the integrity of the response. the integrity of the response.
All of the key exchange methods using the SHA-1 hashing algorithm All of the key exchange methods using the SHA-1 hashing algorithm
should be deprecated and phased out due to security concerns for SHA- should be deprecated and phased out due to security concerns for SHA-
1, as documented in [RFC6194]. 1, as documented in [RFC6194].
Unconditionally deprecating and/or disallowing SHA-1 everywhere will Unconditionally deprecating and/or disallowing SHA-1 everywhere will
hasten the day when it may be simply removed from implementations hasten the day when it may be simply removed from implementations
completely. Leaving partially-broken algorithms lying around is not completely. Leaving partially broken algorithms lying around is not
a good thing to do. a good thing to do.
The SHA-2 Family of hashes [RFC6234] is more secure than SHA-1. They 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 have been standardized for use in SSH with many of the currently
defined key exchanges. defined key exchanges.
Please note that at the present time, there is no key exchange method 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 for Secure Shell that uses the SHA-3 family of secure hashing
functions or the Extendable Output Functions. functions or the Extendable-Output Functions [NIST.FIPS.202].
Prior to the changes made by this document, diffie-hellman- Prior to the changes made by this document, diffie-hellman-
group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie- group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie-
hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit
MODP group) is defined in [RFC3526]. The group1 MODP group with MODP group) is defined in Section 3 of [RFC3526]. The SSH group1 is
approximately 80 bits of security is too weak to be retained. defined in Section 8.1 of [RFC4253] as using the Oakley Group 2
However, rather than jumping from the MTI to making it disallowed, provided in Section 6.2 of [RFC2409] (a 1024-bit MODP group). This
many implementers suggested that it should transition to deprecated group1 MODP group with approximately 80 bits of security is too weak
first and be disallowed at a later time. The group14 MODP group to be retained. However, rather than jumping from the MTI status to
using a sha1 hash for the KDF is not as weak as the group1 MODP making it disallowed, many implementers suggested that it should
group. There are some legacy situations where it will still provide transition to deprecated first and be disallowed at a later time.
administrators with value, such as small hardware IOT devices which The group14 MODP group using a SHA-1 hash for the KDF is not as weak
have insufficient compute and memory resources to use larger MODP as the group1 MODP group. There are some legacy situations where it
groups before a timeout of the session occurs. Transitioning from will still provide administrators with value, such as small hardware
MTI to a requirement status that provides for continued use with the Internet of Things (IOT) devices that have insufficient compute and
expectation of deprecating or disallowing it in the future was able memory resources to use larger MODP groups before a timeout of the
to find consensus. Therefore, it is considered reasonable to retain session occurs. There was consensus to transition from MTI to a
the diffie-hellman-group14-sha1 exchange for interoperability with requirement status that provides for continued use with the
legacy implementations. The diffie-hellman-group14-sha1 key exchange expectation that it would be deprecated or disallowed in the future.
MAY be implemented, but should be put at the end of the list of Therefore, it is considered reasonable to retain the diffie-hellman-
negotiated key exchanges. 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 The diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1
SHOULD NOT be implemented. The gss-group1-sha1-*, gss- SHOULD NOT be implemented. The gss-group1-sha1-*, gss-
group14-sha1-*, and gss-gex-sha1-* key exchanges are already group14-sha1-*, and gss-gex-sha1-* key exchanges are already
specified as SHOULD NOT be implemented by [RFC8732]. specified as SHOULD NOT be implemented by [RFC8732].
3.5. Secure Shell Extension Negotiation 3.5. Secure Shell Extension Negotiation
There are two methods, ext-info-c and ext-info-s, defined in There are two methods, ext-info-c and ext-info-s, defined in
[RFC8308]. They provide a mechanism to support other Secure Shell [RFC8308]. They provide a mechanism to support other Secure Shell
negotiations. Being able to extend functionality is desirable. Both negotiations. Being able to extend functionality is desirable. Both
ext-info-c and ext-info-s SHOULD be implemented. ext-info-c and ext-info-s SHOULD be implemented.
4. Summary Guidance for Key Exchange Method Names Implementations 4. Summary Guidance for Implementation of Key Exchange Method Names
The Implement column is the current recommendations of this RFC.
Table 12 provides the existing key exchange method names listed Table 12 provides the existing key exchange method names listed
alphabetically. alphabetically. The Implement column contains the current
recommendations of this RFC.
+==========================+===========+================+===========+ +=======================+============+================+===========+
| Key Exchange Method | Reference | Previous | RFCxxxxx | | Key Exchange Method | Reference | Previous | RFC 9142 |
| Name | | Recommendation | Implement | | Name | | Recommendation | Implement |
+==========================+===========+================+===========+ +=======================+============+================+===========+
| curve25519-sha256 | RFC8731 | none | SHOULD | | curve25519-sha256 | [RFC8731] | none | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| curve448-sha512 | RFC8731 | none | MAY | | curve448-sha512 | [RFC8731] | none | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | RFC4419 | none | SHOULD | | diffie-hellman-group- | [RFC4419], | none | SHOULD |
| exchange-sha1 | RFC8270 | | NOT | | exchange-sha1 | [RFC8270] | | NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman-group- | RFC4419 | none | MAY | | diffie-hellman-group- | [RFC4419], | none | MAY |
| exchange-sha256 | RFC8720 | | | | exchange-sha256 | [RFC8270] | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC4253 | MUST | SHOULD | | diffie-hellman- | [RFC4253] | MUST | SHOULD |
| group1-sha1 | | | NOT | | group1-sha1 | | | NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC4253 | MUST | MAY | | diffie-hellman- | [RFC4253] | MUST | MAY |
| group14-sha1 | | | | | group14-sha1 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC8268 | none | MUST | | diffie-hellman- | [RFC8268] | none | MUST |
| group14-sha256 | | | | | group14-sha256 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC8268 | none | MAY | | diffie-hellman- | [RFC8268] | none | MAY |
| group15-sha512 | | | | | group15-sha512 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC8268 | none | SHOULD | | diffie-hellman- | [RFC8268] | none | SHOULD |
| group16-sha512 | | | | | group16-sha512 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC8268 | none | MAY | | diffie-hellman- | [RFC8268] | none | MAY |
| group17-sha512 | | | | | group17-sha512 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| diffie-hellman- | RFC8268 | none | MAY | | diffie-hellman- | [RFC8268] | none | MAY |
| group18-sha512 | | | | | group18-sha512 | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ecdh-sha2-* | RFC5656 | MAY | MAY | | ecdh-sha2-* | [RFC5656] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp256 | RFC5656 | MUST | SHOULD | | ecdh-sha2-nistp256 | [RFC5656] | MUST | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD | | ecdh-sha2-nistp384 | [RFC5656] | MUST | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD | | ecdh-sha2-nistp521 | [RFC5656] | MUST | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ecmqv-sha2 | RFC5656 | MAY | MAY | | ecmqv-sha2 | [RFC5656] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ext-info-c | RFC8308 | SHOULD | SHOULD | | ext-info-c | [RFC8308] | SHOULD | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| ext-info-s | RFC8308 | SHOULD | SHOULD | | ext-info-s | [RFC8308] | SHOULD | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss- | RFC4462 | reserved | reserved | | gss- | [RFC4462] | reserved | reserved |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss- | RFC8732 | SHOULD | SHOULD | | gss- | [RFC8732] | SHOULD | SHOULD |
| curve25519-sha256-* | | | | | curve25519-sha256-* | | | |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-curve448-sha512-* | RFC8732 | MAY | MAY | | gss-curve448-sha512-* | [RFC8732] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-gex-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | | gss-gex-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | RFC8732 | | NOT | | | [RFC8732] | | NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group1-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | | gss-group1-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | RFC8732 | | NOT | | | [RFC8732] | | NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group14-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | | gss-group14-sha1-* | [RFC4462], | SHOULD NOT | SHOULD |
| | RFC8732 | | NOT | | | [RFC8732] | | NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group14-sha256-* | RFC8732 | SHOULD | SHOULD | | gss-group14-sha256-* | [RFC8732] | SHOULD | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group15-sha512-* | RFC8732 | MAY | MAY | | gss-group15-sha512-* | [RFC8732] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group16-sha512-* | RFC8732 | SHOULD | MAY | | gss-group16-sha512-* | [RFC8732] | SHOULD | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group17-sha512-* | RFC8732 | MAY | MAY | | gss-group17-sha512-* | [RFC8732] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-group18-sha512-* | RFC8732 | MAY | MAY | | gss-group18-sha512-* | [RFC8732] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-nistp256-sha256-* | RFC8732 | SHOULD | SHOULD | | gss-nistp256-sha256-* | [RFC8732] | SHOULD | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-nistp384-sha384-* | RFC8732 | MAY | SHOULD | | gss-nistp384-sha384-* | [RFC8732] | MAY | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| gss-nistp521-sha512-* | RFC8732 | MAY | SHOULD | | gss-nistp521-sha512-* | [RFC8732] | MAY | SHOULD |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| rsa1024-sha1 | RFC4432 | MAY | MUST NOT | | rsa1024-sha1 | [RFC4432] | MAY | MUST NOT |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
| rsa2048-sha256 | RFC4432 | MAY | MAY | | rsa2048-sha256 | [RFC4432] | MAY | MAY |
+--------------------------+-----------+----------------+-----------+ +-----------------------+------------+----------------+-----------+
Table 12: IANA guidance for key exchange method name implementations Table 12: IANA Guidance for Implementation of Key Exchange
Method Names
The full set of official [IANA-KEX] key algorithm method names not The full set of official [IANA-SSH] "Key Exchange Method Names" not
otherwise mentioned in this document MAY be implemented. otherwise mentioned in this document MAY be implemented.
[TO BE REMOVED: This registration should take place at the following 5. Security Considerations
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.
6. Security Considerations
This SSH protocol provides a secure encrypted channel over an This SSH protocol provides a secure encrypted channel over an
insecure network. It performs server host authentication, key insecure network. It performs server host authentication, key
exchange, encryption, and integrity checks. It also derives a unique exchange, encryption, and integrity checks. It also derives a unique
session ID that may be used by higher-level protocols. The key session ID that may be used by higher-level protocols. The key
exchange itself generates a shared secret and uses the hash function exchange itself generates a shared secret and uses the hash function
for both the KDF and integrity. for both the KDF and integrity.
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in
[RFC4251] continue to apply. In addition, the security [RFC4251] and continue to apply. In addition, the security
considerations provided in [RFC4432] apply. Note that Forward considerations provided in [RFC4432] apply. Note that Forward
Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key
exchanges. exchanges.
It is desirable to deprecate or disallow key exchange methods that It is desirable to deprecate or disallow key exchange methods that
are considered weak, so they are not in still actively in operation are considered weak so they are not still actively in operation when
when they are broken. they are broken.
A key exchange method is considered weak when the security strength A key exchange method is considered weak when the security strength
is insufficient to match the symmetric cipher or the algorithm has is insufficient to match the symmetric cipher or the algorithm has
been broken. been broken.
The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too
small for the symmetric ciphers used in SSH. small for the symmetric ciphers used in SSH.
MODP groups with a modulus size less than 2048 bits are too small for 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- the symmetric ciphers used in SSH. If the diffie-hellman-group-
skipping to change at page 19, line 46 skipping to change at line 848
At this time, the rsa1024-sha1 key exchange is too small for the At this time, the rsa1024-sha1 key exchange is too small for the
symmetric ciphers used in SSH. symmetric ciphers used in SSH.
The use of SHA-1 for use with any key exchange may not yet be 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 completely broken, but it is time to retire all uses of this
algorithm as soon as possible. algorithm as soon as possible.
The diffie-hellman-group14-sha1 algorithm is not yet completely The diffie-hellman-group14-sha1 algorithm is not yet completely
deprecated. This is to provide a practical transition from the MTI 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 algorithms to a new one. However, it would be best to only be used
last resort in key exchange negotiations. All key exchange methods as a last resort in key exchange negotiations. All key exchange
using the SHA-1 hash are to be considered as deprecated. methods using the SHA-1 hash are to be considered as deprecated.
7. IANA Considerations 6. IANA Considerations
IANA is requested to add a new column to [IANA-KEX] with heading "OK IANA has added a new column to the "Key Exchange Method Names"
to Implement", and to annotate entries therein with the registry [IANA-SSH] with the heading "OK to Implement" and annotated
implementation guidance provided in section 4 "Summary Guidance for entries therein with the implementation guidance provided in
Key Exchange Method Names Implementation" in this document. A Section 4, "Summary Guidance for Implementation of Key Exchange
summary may be found in Table 12 in section 4. IANA is additionally Method Names", in this document. IANA also added entries for ecdh-
requested to include this document as an additional reference for the sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, and added
with the suggested implementation guidance provided in section 4 references to [RFC4462] and [RFC8732] for gss-gex-sha1-*, gss-
"Summary Guidance for Key Exchange Method Names Implementation" in group1-sha1-*, gss-group14-sha1-*, diffie-hellman-group-exchange-
this document. [IANA-KEX] registry. Registry entries annotated with sha1, and diffie-hellman-group-exchange-sha256. A summary may be
"MUST NOT" are considered disallowed. Registry entries annotated found in Table 12 in Section 4. IANA has also included this document
with "SHOULD NOT" are deprecated and may be disallowed in the future. as an additional registry reference for the suggested implementation
guidance provided in Section 4 of this document and added a note
indicating the following:
8. References | OK to Implement guidance entries for registrations that pre-date
| [RFC9142] are found in Table 12 in Section 4 of [RFC9142].
8.1. Normative References Registry entries annotated with "MUST NOT" are considered disallowed.
Registry entries annotated with "SHOULD NOT" are deprecated and may
be disallowed in the future.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006, DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>. <https://www.rfc-editor.org/info/rfc4250>.
skipping to change at page 21, line 14 skipping to change at line 916
[RFC8308] Bider, D., "Extension Negotiation in the Secure Shell [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell
(SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
2018, <https://www.rfc-editor.org/info/rfc8308>. 2018, <https://www.rfc-editor.org/info/rfc8308>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>. <https://www.rfc-editor.org/info/rfc8731>.
8.2. Informative References 7.2. Informative References
[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key [IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters",
Exchange Method Names", July 2021, <https://www.iana.org/assignments/ssh-parameters/>.
<https://www.iana.org/assignments/ssh-parameters/ssh-
parameters.xhtml#ssh-parameters-16>. [NIST.FIPS.202]
National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", FIPS PUB 202, DOI 10.6028/NIST.FIPS.202,
August 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
[NIST.SP.800-107r1] [NIST.SP.800-107r1]
Dang, Q., "Recommendation for applications using approved Dang, Q., "Recommendation for applications using approved
hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August
2012, <https://doi.org/10.6028/NIST.SP.800-107r1>. 2012, <https://doi.org/10.6028/NIST.SP.800-107r1>.
[NIST.SP.800-57pt1r5] [NIST.SP.800-57pt1r5]
Barker, E., "Recommendation for Key Management - Part 1 - Barker, E., "Recommendation for Key Management: Part 1 -
General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020,
<https://doi.org/10.6028/NIST.SP.800-57pt1r5>. <https://doi.org/10.6028/NIST.SP.800-57pt1r5>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003, RFC 3526, DOI 10.17487/RFC3526, May 2003,
<https://www.rfc-editor.org/info/rfc3526>. <https://www.rfc-editor.org/info/rfc3526>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
skipping to change at page 22, line 40 skipping to change at line 999
[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
Internet Key Exchange Protocol Version 2 (IKEv2) Key Internet Key Exchange Protocol Version 2 (IKEv2) Key
Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
<https://www.rfc-editor.org/info/rfc8031>. <https://www.rfc-editor.org/info/rfc8031>.
[RFC8732] Sorce, S. and H. Kario, "Generic Security Service [RFC8732] Sorce, S. and H. Kario, "Generic Security Service
Application Program Interface (GSS-API) Key Exchange with Application Program Interface (GSS-API) Key Exchange with
SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020,
<https://www.rfc-editor.org/info/rfc8732>. <https://www.rfc-editor.org/info/rfc8732>.
[TRANS-COLL] [TRANSCRIPTION]
Bhargavan, K. and G. Leurent, "Transcript Collision Bhargavan, K. and G. Leurent, "Transcript Collision
Attacks: Breaking Authentication in TLS, IKE, and SSH", Attacks: Breaking Authentication in TLS, IKE, and SSH",
Network and Distributed System Security Symposium - NDSS Network and Distributed System Security Symposium (NDSS),
2016, Feb 2016, San Diego, United DOI 10.14722/ndss.2016.23418, February 2016,
States. 10.14722/ndss.2016.23418 . hal-01244855, <https://doi.org/10.14722/ndss.2016.23418>.
<https://hal.inria.fr/hal-01244855/document>.
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 document:
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 document.
Author's Address Author's Address
Mark D. Baushke Mark D. Baushke
Email: mbaushke.ietf@gmail.com Email: mbaushke.ietf@gmail.com
 End of changes. 93 change blocks. 
375 lines changed or deleted 391 lines changed or added

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