rfc9142.original.xml   rfc9142.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-curdle-ssh-kex-sha2-20" docName="draft-ietf-curdle-ssh-kex-sha2-20"
updates="4250 4253 4432 4462" number="9142"
ipr="trust200902" ipr="trust200902"
updates="4250, 4253, 4432, 4462"
obsoletes="" obsoletes=""
submissionType="IETF" submissionType="IETF"
xml:lang="en" tocInclude="true" category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="4" tocDepth="4"
symRefs="true" symRefs="true"
sortRefs="true" sortRefs="true"
consensus="true"
version="3"> version="3">
<!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<title abbrev="KEX Method Updates for SSH"> <title abbrev="KEX Method Updates for SSH">
Key Exchange (KEX) Method Updates and Recommendations for Secure Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
Shell (SSH) (SSH)
</title> </title>
<seriesInfo name="RFC" value="9142"/>
<seriesInfo name="Internet-Draft" <author initials="M." surname="Baushke" fullname="Mark D. Baushke">
value="draft-ietf-curdle-ssh-kex-sha2-20"/>
<author initials="M. D." surname="Baushke" fullname="Mark D. Baushke">
<address> <address>
<email>mbaushke.ietf@gmail.com</email> <email>mbaushke.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="August" day="6" year="2021"/> <date month="January" year="2022"/>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<abstract> <keyword>3DES</keyword>
<keyword>AES</keyword>
<keyword>Advanced Encryption Standard</keyword>
<keyword>Curve25519</keyword>
<keyword>Curve448</keyword>
<keyword>DH</keyword>
<keyword>Diffie-Hellman</keyword>
<keyword>Digital Encryption Standard</keyword>
<keyword>ECC</keyword>
<keyword>ECDH</keyword>
<keyword>Elliptic Curve Cryptography</keyword>
<keyword>Elliptic Curve Diffie-Hellman</keyword>
<keyword>FFC</keyword>
<keyword>Finite Field Cryptography</keyword>
<keyword>IFC</keyword>
<keyword>Integer Factorization Cryptography</keyword>
<keyword>MODP</keyword>
<keyword>MTI</keyword>
<keyword>Mandatory to Implement</keyword>
<keyword>Modular Exponential</keyword>
<keyword>Modular Exponentiation</keyword>
<keyword>Public Key Exchange</keyword>
<keyword>RSA</keyword>
<keyword>SHA-2</keyword>
<keyword>Secure Shell Key Exchange</keyword>
<keyword>Secure Shell</keyword>
<keyword>Security Strength</keyword>
<keyword>Triple-DES</keyword>
<keyword>sha1</keyword>
<keyword>sha256</keyword>
<keyword>sha384</keyword>
<keyword>sha512</keyword>
<keyword>SHA-1</keyword>
<abstract>
<t> <t>
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 use in the Secure Shell (SSH) protocol to meet evolving needs for
meet evolving needs for stronger security. stronger security. It updates RFCs 4250, 4253, 4432, and 4462.
This document updates RFC 4250, RFC 4253, RFC 4432, and RFC
4462.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- Section 1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overview and Rationale</name> <name>Overview and Rationale</name>
<t> <t>
Secure Shell (SSH) is a common protocol for secure Secure Shell (SSH) is a common protocol for secure
communication on the Internet. communication on the Internet.
In In <xref target="RFC4253" format="default"/>,
SSH originally defined two Key Exchange (KEX) Method Names that
<xref target="RFC4253" format="default"/>, <bcp14>MUST</bcp14> be implemented.
SSH originally defined two Key Exchange (KEX) Method Names
that MUST be implemented.
Over time what was once considered secure is no longer Over time, what was once considered secure is no longer considered
considered secure. secure.
The purpose of this RFC is to recommend that some published The purpose of this RFC is to recommend that some published key
key exchanges be deprecated or disallowed as well as exchanges be deprecated or disallowed as well as to recommend some
recommending some that SHOULD and one that MUST be adopted. that <bcp14>SHOULD</bcp14> and one that <bcp14>MUST</bcp14> be
adopted.
</t> </t>
<t> <t>
This document updates This document updates
<xref target="RFC4250" format="default"/> <xref target="RFC4250" format="default"/>, <xref target="RFC4253"
<xref target="RFC4253" format="default"/> format="default"/>, <xref target="RFC4432" format="default"/>, and
<xref target="RFC4432" format="default"/>
<xref target="RFC4462" format="default"/> <xref target="RFC4462" format="default"/>
by changing the requirement level ("MUST" moving to "SHOULD" by changing the requirement level ("<bcp14>MUST</bcp14>" moving to
or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or "<bcp14>SHOULD</bcp14>", "<bcp14>MAY</bcp14>", or "<bcp14>SHOULD
"SHOULD" or "SHOULD NOT" or "MUST NOT") of various NOT</bcp14>", and "<bcp14>MAY</bcp14>" moving to
key exchange mechanisms. "<bcp14>MUST</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD
NOT</bcp14>", or "<bcp14>MUST NOT</bcp14>") of various key exchange
mechanisms.
Some recommendations will be unchanged, but are included for Some recommendations will be unchanged but are included for
completeness. completeness.
</t> </t>
<t> <t>
<xref target="RFC4253" format="default"/> <xref target="RFC4253" sectionFormat="of" section="7.2"/> says the following:
section 7.2 says the following:
</t> </t>
<t> <blockquote>
"The key exchange produces two values: a shared secret K, and The key exchange produces two values: a shared secret K, and
an exchange hash H. an exchange hash H.
Encryption and authentication keys are derived from these. Encryption and authentication keys are derived from these.
The exchange hash H from the first key exchange is 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. identifier for this connection.
It is used by authentication methods as a part of the data It is used by authentication methods as a part of the data
that is signed as a proof of possession of a private key. that is signed as a proof of possession of a private key.
Once computed, the session identifier is not changed, even if Once computed, the session identifier is not changed, even if
keys are later re-exchanged." keys are later re-exchanged.
</t> </blockquote>
<t> <t>
The security strength of the public key exchange algorithm and 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. the security of the shared secret K being used.
</t> </t>
<t> <t>
The hashing algorithms used by key exchange methods described The hashing algorithms used by key exchange methods described
in this document are: sha1, sha256, sha384, and sha512. in this document are: sha1, sha256, sha384, and sha512.
skipping to change at line 139 skipping to change at line 171
public key exchange algorithm name. public key exchange algorithm name.
However, some of them are implicit and defined in the RFC that However, some of them are implicit and defined in the RFC that
defines the key exchange algorithm name. defines the key exchange algorithm name.
</t> </t>
<t> <t>
Various RFCs use different spellings and capitalizations for Various RFCs use different spellings and capitalizations for
the hashing function and encryption function names. the hashing function and encryption function names.
For the purpose of this document, the following are equivalent For the purpose of this document, the following are equivalent names:
names: sha1, SHA1, and SHA-1; sha256, SHA256, and SHA2-256; sha1, SHA1, and SHA-1; sha256, SHA256, SHA-256, and SHA2-256; sha384,
sha384, SHA384, and SHA2-384; sha512, SHA512, and SHA2-512. SHA384, SHA-384, and SHA2-384; and sha512, SHA512, SHA-512, and
SHA2-512.
</t> </t>
<t> <t>
For the purpose of this document, the following are For the purpose of this document, the following are equivalent:
equivalent: aes128, AES128, AES-128; aes192, AES192, and aes128, AES128, AES-128; aes192, AES192, and AES-192; and aes256,
AES-192; aes256, AES256, and AES-256. AES256, and AES-256.
</t> </t>
<t> <t>
It is good to try to match the security strength of the public It is good to try to match the security strength of the public
key exchange algorithm with security strength of the symmetric key exchange algorithm with the security strength of the symmetric
cipher. cipher.
</t> </t>
<t> <t>
There are many possible symmetric ciphers available, with There are many possible symmetric ciphers available with multiple
multiple modes. 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
<xref target="RFC4086" format="default"/>
for triple-DES and AES as well as
<xref target="NIST.SP.800-57pt1r5" format="default"/> The list in <xref target="sym_ci_sec"/> is intended as a representative
sample
of those that appear to be present in most SSH implementations.
Section 5.6.1.1. The security strength estimates are generally available in <xref
target="RFC4086" format="default"/> for triple-DES and AES, as well as
Section 5.6.1.1 of <xref target="NIST.SP.800-57pt1r5"
format="default"/>.
</t> </t>
<!-- Table 1 --> <table align="center" anchor="sym_ci_sec">
<table align="center">
<name>Symmetric Cipher Security Strengths</name> <name>Symmetric Cipher Security Strengths</name>
<thead> <thead>
<tr> <tr>
<th align="left">Cipher Name (modes)</th> <th align="left">Cipher Name (modes)</th>
<th align="left">Estimated Security Strength</th> <th align="left">Estimated Security Strength</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">3des (cbc)</td> <td align="left">3des (cbc)</td>
skipping to change at line 208 skipping to change at line 235
<td align="left">256 bits</td> <td align="left">256 bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The following subsections describe how to select each The following subsections describe how to select each
component of the key exchange. component of the key exchange.
</t> </t>
<!-- Section 1.1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Selecting an appropriate hashing algorithm</name> <name>Selecting an Appropriate Hashing Algorithm</name>
<t> <t>
The SHA-1 hash is in the process of being deprecated for The SHA-1 hash is in the process of being deprecated for
many reasons. many reasons.
</t> </t>
<t> <t>
There have been attacks against SHA-1 and it is no longer There have been attacks against SHA-1, and it is no longer
strong enough for SSH security requirements. strong enough for SSH security requirements.
Therefore, it is desirable to move away from using it before Therefore, it is desirable to move away from using it before
attacks become more serious. attacks become more serious.
</t> </t>
<t> <t>
The SHA-1 hash provides for approximately 80 bits of The SHA-1 hash provides for approximately 80 bits of
security strength. security strength.
This means that the shared key being used has at most 80 This means that the shared key being used has at most 80
bits of security strength which may not be sufficient for bits of security strength, which may not be sufficient for
most users. most users.
</t> </t>
<t> <t>
For purposes of key exchange methods, attacks against SHA-1 For purposes of key exchange methods, attacks against SHA-1 are
are collision attacks that usually rely on human help, collision attacks that usually rely on human help rather than a
rather than a pre-image attack. pre-image attack.
SHA-1 resistance against second pre-image is still at 160 The SHA-1 hash resistance against a second pre-image is still at 160
bits, but SSH does not depend on second pre-image bits, but SSH does not depend on second pre-image
resistance, but rather on chosen-prefix collision resistance but rather on chosen-prefix collision
resistance. resistance.
</t> </t>
<t> <t>
Transcript Collision attacks are documented in Transcript Collision attacks are documented in
<xref target="TRANS-COLL" format="default"/>. <xref target="TRANSCRIPTION" format="default"/>.
This paper shows that an on-path attacker does not tamper This paper shows that an on-path attacker does not tamper
with the Diffie-Hellman values and does not know the with the Diffie-Hellman values and does not know the
connection keys. connection keys.
The attack could be used to tamper with both I_C and I_S (as The attack could be used to tamper with both I_C and I_S (as defined
defined in section 7.3 of in <xref target="RFC4253" sectionFormat="of" section="7.3"
format="default"/>) and might potentially be able to downgrade the
<xref target="RFC4253" format="default"/>), negotiated ciphersuite to a weak cryptographic algorithm that the
and might potentially be able to downgrade the negotiated
ciphersuite to a weak cryptographic algorithm that the
attacker knows how to break. attacker knows how to break.
</t> </t>
<t> <t>
These attacks are still computationally very difficult to These attacks are still computationally very difficult to
perform, but it is desirable that any key exchange using perform, but it is desirable that any key exchange using
SHA-1 be phased out as soon as possible. SHA-1 be phased out as soon as possible.
</t> </t>
<t> <t>
skipping to change at line 285 skipping to change at line 308
<t> <t>
Use of the SHA-2 family of hashes found in Use of the SHA-2 family of hashes found in
<xref target="RFC6234" format="default"/> <xref target="RFC6234" format="default"/>
rather than the SHA-1 hash is strongly advised. rather than the SHA-1 hash is strongly advised.
</t> </t>
<t> <t>
When it comes to the SHA-2 family of Secure Hashing When it comes to the SHA-2 family of secure hashing
functions, SHA2-256 has 128 bits of security strength; functions, SHA2-256 has 128 bits of security strength;
SHA2-384 has 192 bits of security strength; and SHA2-512 has SHA2-384 has 192 bits of security strength; and SHA2-512 has
256 bits of security strength. 256 bits of security strength.
It is suggested that the minimum secure hashing function It is suggested that the minimum secure hashing function
that should be used for key exchange methods is SHA2-256 used for key exchange methods should be SHA2-256
with 128 bits of security strength. with 128 bits of security strength.
Other hashing functions may also have the same number of Other hashing functions may also have the same 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 use in a KEX for SSH. any RFC for use in a KEX for SSH.
</t> </t>
<t> <t>
To avoid combinatorial explosion of key exchange names, To avoid combinatorial explosion of key exchange names,
newer key exchanges are generally restricted to *-sha256 and newer key exchanges are generally restricted to *-sha256 and
*-sha512. *-sha512.
The exceptions are ecdh-sha2-nistp384 and The exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-*,
gss-nistp384-sha384-* which are defined to use SHA2-384 for which are defined to use SHA2-384 (also known as SHA-384) defined in
the hash algorithm. <xref target="RFC6234"/> for the hash algorithm.
</t> </t>
<t> <t>
Table 2 provides a summary of security strength for hashing <xref target="sec_strength"/> provides a summary of security
functions for collision resistance. You may consult strength for hashing functions for collision resistance. You may
consult
<xref target="NIST.SP.800-107r1" format="default"/> <xref target="NIST.SP.800-107r1" format="default"/>
for more information on hash algorithm security strength. for more information on hash algorithm security strength.
</t> </t>
<!-- Table 2 -->
<table align="center"> <table anchor="sec_strength" align="center">
<name>Hashing Function Security Strengths</name> <name>Hashing Function Security Strengths</name>
<thead> <thead>
<tr> <tr>
<th align="left">Hash Name</th> <th align="left">Hash Name</th>
<th align="left">Estimated Security Strength</th> <th align="left">Estimated Security Strength</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">sha1</td> <td align="left">sha1</td>
skipping to change at line 348 skipping to change at line 372
</tr> </tr>
<tr> <tr>
<td align="left">sha512</td> <td align="left">sha512</td>
<td align="left">256 bits</td> <td align="left">256 bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 1.2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Selecting an appropriate Public key Algorithm</name> <name>Selecting an Appropriate Public Key Algorithm</name>
<t> <t>
SSH uses mathematically hard problems for doing key SSH uses mathematically hard problems for doing key
exchanges: exchanges:
</t> </t>
<ul> <ul>
<li> <li>
Elliptic Curve Cryptography (ECC) has families of curves Elliptic Curve Cryptography (ECC) has families of curves
for key exchange methods for SSH. for key exchange methods for SSH.
NIST prime curves with names and other curves are NIST prime curves with names and other curves are
available using an object identifier (OID) with Elliptic available using an object identifier (OID) with Elliptic
Curve Diffie-Hellman (ECDH) via Curve Diffie-Hellman (ECDH) via
<xref target="RFC5656" format="default"/>. <xref target="RFC5656" format="default"/>.
Curve25519 and Curve448 key exchanges are used with ECDH Curve25519 and curve448 key exchanges are used with ECDH
via via
<xref target="RFC8731" format="default"/>. <xref target="RFC8731" format="default"/>.
</li> </li>
<li> <li>
Finite Field Cryptography (FFC) is used for Diffie-Hellman Finite Field Cryptography (FFC) is used for Diffie-Hellman
(DH) key exchange with "safe primes" either from a (DH) key exchange with "safe primes" either from a
specified list found in specified list found in
skipping to change at line 408 skipping to change at line 431
<t> <t>
It is desirable that the security strength of the key It is desirable that the security strength of the key
exchange be chosen to be comparable with the security exchange be chosen to be comparable with the security
strength of the other elements of the SSH handshake. strength of the other elements of the SSH handshake.
Attackers can target the weakest element of the SSH Attackers can target the weakest element of the SSH
handshake. handshake.
</t> </t>
<t> <t>
It is desirable to select a minimum of 112 bits of security It is desirable that a minimum of 112 bits of security
strength to match the weakest of the symmetric cipher strength be selected to match the weakest of the symmetric cipher
(3des-cbc) available. (3des-cbc) available.
Based on implementer security needs, a stronger minimum may Based on implementer security needs, a stronger minimum may
be desired. be desired.
</t> </t>
<t> <t>
The larger the MODP group, the ECC curve size, or the RSA The larger the Modular Exponentiation (MODP) group, the ECC curve size , or the RSA
key length, the more computation power will be required to key length, the more computation power will be required to
perform the key exchange. perform the key exchange.
</t> </t>
<!-- Section 1.2.1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Elliptic Curve Cryptography (ECC)</name> <name>Elliptic Curve Cryptography (ECC)</name>
<t> <t>
For ECC, across all of the named curves the minimum For ECC, across all of the named curves, the minimum security
security strength is approximately 128 bits. strength is approximately 128 bits.
The The
<xref target="RFC5656" format="default"/> <xref target="RFC5656" format="default"/>
key exchanges for the named curves use a hashing function with a
key exchanges for the named curves use a hashing function matching security strength.
with a matching security strength.
Likewise, the Likewise, the
<xref target="RFC8731" format="default"/> <xref target="RFC8731" format="default"/>
key exchanges use a hashing function which has more key exchanges use a hashing function that has more security
security strength than the curves. strength than the curves.
The minimum strength will be the security strength of the The minimum strength will be the security strength of the
curve. curve.
Table 3 contains a breakdown of just the ECC security <xref target="ecc_sec_strengths"/> contains a breakdown of just
strength by curve name and not including the hashing the ECC security strength by curve name; it does include the
algorithm used. hashing algorithm used.
The curve* security level numbers are in The curve25519 and curve488 security-level numbers are in
<xref target="RFC7748" format="default"/>. <xref target="RFC7748" format="default"/>.
The nist* numbers are in The nistp256, nistp384, and nistp521 (NIST prime curves) are
<xref target="RFC5656" format="default"/>. provided in <xref target="RFC5656" format="default"/>.
The hashing algorithm designated for use with the The hashing algorithm designated for use with the
individual curves have approximately the same number of individual curves have approximately the same number of
bits of security as the named curve. bits of security as the named curve.
</t> </t>
<!-- Table 3 --> <table align="center" anchor="ecc_sec_strengths">
<table align="center">
<name>ECC Security Strengths</name> <name>ECC Security Strengths</name>
<thead> <thead>
<tr> <tr>
<th align="left">Curve Name</th> <th align="left">Curve Name</th>
<th align="left">Estimated Security Strength</th> <th align="left">Estimated Security Strength</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">nistp256</td> <td align="left">nistp256</td>
skipping to change at line 485 skipping to change at line 504
</tr> </tr>
<tr> <tr>
<td align="left">nistp384</td> <td align="left">nistp384</td>
<td align="left">192 bits</td> <td align="left">192 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">nistp521</td> <td align="left">nistp521</td>
<td align="left">512 bits</td> <td align="left">512 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Curve25519</td> <td align="left">curve25519</td>
<td align="left">128 bits</td> <td align="left">128 bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">Curve448</td> <td align="left">curve448</td>
<td align="left">224 bits</td> <td align="left">224 bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 1.2.2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Finite Field Cryptography (FFC)</name> <name>Finite Field Cryptography (FFC)</name>
<t> <t>
For FFC, it is recommended to use a modulus with a minimum For FFC, it is recommended to use a modulus with a minimum
of 2048 bits (approximately 112 bits of security strength) of 2048 bits (approximately 112 bits of security strength)
with a hash that has at least as many bits of security as with a hash that has at least as many bits of security as
the FFC. the FFC.
The security strength of the FFC and the hash together The security strength of the FFC and the hash together
will be the minimum of those two values. will be the minimum of those two values.
This is sufficient to provide a consistent security This is sufficient to provide a consistent security
strength for the 3des-cbc cipher. strength for the 3des-cbc cipher.
<xref target="RFC3526" format="default"/> <xref target="RFC3526" sectionFormat="of" section="1"
format="default"/> notes that the Advanced Encryption Standard
section 1 notes that the Advanced Encryption Standard (AES) cipher, which has more strength, needs stronger groups.
(AES) cipher, which has more strength, needs stronger
groups.
For the 128-bit AES we need about a 3200-bit group. For the 128-bit AES, we need about a 3200-bit group.
The 192 and 256-bit keys would need groups that are about The 192- and 256-bit keys would need groups that are about
8000 and 15400 bits respectively. 8000 and 15400 bits, respectively.
Table 4 provides the security strength of the MODP group. <xref target="fcc_modp_sec"/> provides the security strength of the MODP group.
When paired with a hashing algorithm, the security When paired with a hashing algorithm, the security
strength will be the minimum of the two algorithms. strength will be the minimum of the two algorithms.
</t> </t>
<!-- Table 4 --> <table align="center" anchor="fcc_modp_sec">
<table align="center">
<name>FFC MODP Security Strengths</name> <name>FFC MODP Security Strengths</name>
<thead> <thead>
<tr> <tr>
<th align="left">Prime Field Size</th> <th align="left">Prime Field Size</th>
<th align="left">Estimated Security Strength</th> <th align="left">Estimated Security Strength</th>
<th align="left">Example MODP Group</th> <th align="left">Example MODP Group</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 572 skipping to change at line 587
<td align="left">8192-bit</td> <td align="left">8192-bit</td>
<td align="left">200 bits</td> <td align="left">200 bits</td>
<td align="left">group18</td> <td align="left">group18</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The minimum MODP group is the 2048-bit MODP group14. The minimum MODP group is the 2048-bit MODP group14.
When used with sha1, this group provides approximately 80 When used with a SHA-1 hash, this group provides approximately 80
bits of security. bits of security.
When used with sha256, this group provides approximately When used with a SHA2-256 hash, this group provides approximately
112 bits of security. 112 bits of security.
The 3des-cbc cipher itself provides at most 112 bits of The 3des-cbc cipher itself provides at most 112 bits of
security, so the group14-sha256 key exchanges is security, so the group14-sha256 key exchanges is
sufficient to keep all of the 3des-cbc key, for 112 bits of sufficient to keep all of the 3des-cbc key, for 112 bits of
security. security.
</t> </t>
<t> <t>
A 3072-bit MODP group with sha256 hash will provide A 3072-bit MODP group when used with a SHA2-256 hash will provide
approximately 128 bits of security. approximately 128 bits of security.
This is desirable when using a cipher such as aes128 or This is desirable when using a cipher such as aes128 or
chacha20-poly1305 that provides approximately 128 bits of chacha20-poly1305 that provides approximately 128 bits of
security. security.
</t> </t>
<t> <t>
The 8192-bit group18 MODP group when used with sha512 The 8192-bit group18 MODP group when used with sha512
provides approximately 200 bits of security which is provides approximately 200 bits of security, which is
sufficient to protect aes192 with 192 bits of security. sufficient to protect aes192 with 192 bits of security.
</t> </t>
</section> </section>
<!-- Section 1.2.3. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Integer Factorization Cryptography (IFC)</name> <name>Integer Factorization Cryptography (IFC)</name>
<t> <t>
The only IFC algorithm for key exchange is the RSA The only IFC algorithm for key exchange is the RSA
algorithm specified in algorithm specified in
<xref target="RFC4432" format="default"/>. <xref target="RFC4432" format="default"/>.
RSA 1024-bit keys have approximately 80 bits of security RSA 1024-bit keys have approximately 80 bits of security
strength. strength.
RSA 2048-bit keys have approximately 112 bits of security RSA 2048-bit keys have approximately 112 bits of security
strength. strength.
It is worth noting that the IFC types of key exchange do It is worth noting that the IFC types of key exchange do
not provide Forward Secrecy which both FFC and ECC do not provide Forward Secrecy, which both FFC and ECC do
provide. provide.
</t> </t>
<t> <t>
In order to match the 112 bits of security strength needed In order to match the 112 bits of security strength needed
for 3des-cbc, an RSA 2048-bit key matches the security for 3des-cbc, an RSA 2048-bit key matches the security
strength. strength.
The use of a SHA-2 Family hash with RSA 2048-bit keys has The use of a SHA-2 family hash with RSA 2048-bit keys has
sufficient security to match the 3des-cbc symmetric cipher. sufficient security to match the 3des-cbc symmetric cipher.
The rsa1024-sha1 key exchange has approximately 80 bits of The rsa1024-sha1 key exchange has approximately 80 bits of
security strength and is not desirable. security strength and is not desirable.
</t> </t>
<t> <t>
Table 5 summarizes the security strengths of these key <xref target="ifc_sec"/> summarizes the security strengths of
exchanges without including the hashing algorithm these key exchanges without including the hashing algorithm
strength. Guidance for these strengths are in strength. Guidance for these strengths can be found in Section
5.6.1.1 of <xref target="NIST.SP.800-57pt1r5" format="default"/>.
<xref target="NIST.SP.800-57pt1r5" format="default"/>
Section 5.6.1.1.
</t> </t>
<!-- Table 5 --> <table anchor="ifc_sec" align="center">
<table align="center">
<name>IFC Security Strengths</name> <name>IFC Security Strengths</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method</th> <th align="left">Key Exchange Method</th>
<th align="left">Estimated Security Strength</th> <th align="left">Estimated Security Strength</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">rsa1024-sha1</td> <td align="left">rsa1024-sha1</td>
skipping to change at line 671 skipping to change at line 681
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
</section> </section>
<!-- Section 2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
interpreted as described in BCP&nbsp;14 RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC2119" format="default"/> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here.
</t>
when, and only when, they appear in all capitals, as shown
here.
</t>
</section> </section>
<!-- Section 3. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Key Exchange Methods</name> <name>Key Exchange Methods</name>
<t> <t>
This document adopts the style and conventions of This document adopts the style and conventions of
<xref target="RFC4253" format="default"/> <xref target="RFC4253" format="default"/>
in specifying how the use of data key exchange is indicated in in specifying how the use of data key exchange is indicated in
SSH. SSH.
</t> </t>
<t> <t>
This RFC also collects key exchange method names in various This RFC also collects key exchange method names in various
existing RFCs existing RFCs
<xref target="RFC4253" format="default"/>, (<xref target="RFC4253" format="default"/>, <xref target="RFC4419"
<xref target="RFC4419" format="default"/>, format="default"/>, <xref target="RFC4432" format="default"/>, <xref
<xref target="RFC4432" format="default"/>, target="RFC4462" format="default"/>, <xref target="RFC5656"
<xref target="RFC4462" format="default"/>, format="default"/>, <xref target="RFC8268" format="default"/>, <xref
<xref target="RFC5656" format="default"/>, target="RFC8308" format="default"/>, <xref target="RFC8731"
<xref target="RFC8268" format="default"/>, format="default"/>, and <xref target="RFC8732" format="default"/>) and
<xref target="RFC8731" format="default"/>, provides a suggested suitability for implementation of
<xref target="RFC8732" format="default"/>, and <bcp14>MUST</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>MAY</bcp14>,
<xref target="RFC8308" format="default"/>, <bcp14>SHOULD NOT</bcp14>, and <bcp14>MUST NOT</bcp14>.
and provides a suggested suitability for implementation of
MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT.
Any method not explicitly listed MAY be implemented. Any method not explicitly listed <bcp14>MAY</bcp14> be implemented.
</t> </t>
<!-- Address confusion of martin.h.duke@gmail.com -->
<t> <t>
<xref target="RFC4253" format="default"/> section 7.2 "Output <xref target="RFC4253" sectionFormat="of" section="7.2"
of Key Exchange" defines generation of a shared secret K format="default"/> defines the generation of a shared secret K (really
(really the output of the KDF) and an exchange key hash H. the output of the KDF) and an exchange key hash H. Each key exchange
Each key exchange method uses a specified HASH function which method uses a specified HASH function, which must be the same for both
must be the same for both key exchange and Key Derivation. key exchange and Key Derivation.
H is used for key exchange integrity across the SSH session as H is used for key exchange integrity across the SSH session as
it is computed only once. it is computed only once.
It is noted at the end of the 7.2 section that "This process It is noted at the end of <xref target="RFC4253" section="7.2"
will lose entropy if the amount of entropy in K is larger than sectionFormat="of"/> that:
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.
</t> </t>
<blockquote>This process will lose entropy if the
amount of entropy in K is larger than the internal state size of
HASH.</blockquote>
<t>
So, care must be taken that the hashing algorithm used is well
chosen ("reasonable") for the key exchange algorithms being used.
</t>
<t> <t>
This document is intended to provide guidance as to what key
This document provides guidance as to what key
exchange algorithms are to be considered for new or updated exchange algorithms are to be considered for new or updated
SSH implementations. SSH implementations.
</t> </t>
<t> <t>
In general, key exchange methods which are considered 'weak' In general, key exchange methods that are considered "weak"
are being moved to either deprecated ("SHOULD NOT"), or are being moved to either deprecated ("<bcp14>SHOULD NOT</bcp14>") or
disallowed ("MUST NOT"). disallowed ("<bcp14>MUST NOT</bcp14>").
Methods which are newer or considered to be stronger usually Methods that are newer or considered to be stronger usually
require more device resources than many administrators and/or require more device resources than many administrators and/or
developers need are to be allowed ("MAY"). developers need are to be allowed ("<bcp14>MAY</bcp14>").
(Eventually, some of these methods could be moved by consensus (Eventually, some of these methods could be moved by consensus
to "SHOULD" to increase interoperability and security.) to "<bcp14>SHOULD</bcp14>" to increase interoperability and security.)
Methods which are not 'weak' and have implementation consensus Methods that are not "weak" and have implementation consensus
are encouraged ("SHOULD"). are encouraged ("<bcp14>SHOULD</bcp14>").
There needs to be at least one consensus method promoted to a There needs to be at least one consensus method promoted to a status
mandatory to implement (MTI). of mandatory to implement (MTI).
This should help to provide continued interoperability even This should help to provide continued interoperability even
with the loss of one of the now disallowed MTI methods. with the loss of one of the now disallowed MTI methods.
</t> </t>
<t> <t>
For this document, 112 bits of security strength is the For this document, 112 bits of security strength is the
minimum. minimum.
Use of either or both of SHA-1 and RSA 1024-bits at an Use of either or both of SHA-1 and RSA 1024 bits at an
approximate 80 bits of security fall below this minimum and approximate 80 bits of security fall below this minimum and
should be deprecated and moved to disallowed as quickly as should be deprecated and moved to disallowed as quickly as
possible in configured deployments of SSH. possible in configured deployments of SSH.
It seems plausible that this minimum may be increased over It seems plausible that this minimum may be increased over
time, so authors and administrators may wish to prepare for a time, so authors and administrators may wish to prepare for a
switch to algorithms that provide more security strength. switch to algorithms that provide more security strength.
</t> </t>
<!-- Section 3.1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Elliptic Curve Cryptography (ECC)</name> <name>Elliptic Curve Cryptography (ECC)</name>
<t> <t>
The EC key exchange algorithms used with SSH include the The Elliptic Curve (EC) key exchange algorithms used with SSH include
ECDH and EC Menezes–Qu–Vanstone (ecmqv). the
ECDH and EC Menezes-Qu-Vanstone (ECMQV).
</t> </t>
<t> <t>
The ECC curves defined for the key exchange algorithms above The ECC curves defined for the key exchange algorithms above include
include; curve25519, curve448, the NIST prime curves the following: curve25519, curve448, the NIST prime curves
(nistp256, nistp384, nistp521) as well as other curves (nistp256, nistp384, and nistp521), as well as other curves allowed
allowed for by for by <xref target="RFC5656" sectionFormat="of" section="6"
format="default"/>. There are key exchange mechanisms based on the
<xref target="RFC5656" format="default"/> Generic Security Service Application Program Interface (GSS-API) that
use these curves as well that have a "gss-" prefix.
section 6.
There are GSSAPI-based key-exchange mechanisms that use
these curves as well which have a 'gss-' prefix.
</t> </t>
<!-- Section 3.1.1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>curve25519-sha256 and gss-curve25519-sha256-*</name> <name>curve25519-sha256 and gss-curve25519-sha256-*</name>
<t> <t>
Curve25519 is efficient on a wide range of architectures Curve25519 is efficient on a wide range of architectures with
with properties that allow higher performance properties that allow higher-performance implementations compared
implementations compared to the patented elliptic curve to the patented elliptic curve parameters purchased by NIST for
parameters purchased by NIST for the general public to use the general public to use as described in
and described in
<xref target="RFC5656" format="default"/>. <xref target="RFC5656" format="default"/>.
The corresponding key exchange methods use SHA2-256 (also The corresponding key exchange methods use SHA2-256 (also known as
known as SHA-256) defined in SHA-256) defined in
<xref target="RFC6234" format="default"/>. <xref target="RFC6234" format="default"/>.
SHA2-256 is a reasonable hash for use in both the KDF and SHA2-256 is a reasonable hash for use in both the KDF and
session integrity. It is reasonable for both gss and session integrity. It is reasonable for both gss and
non-gss uses of curve25519 key exchange methods. non-gss uses of curve25519 key exchange methods.
These key exchange methods are described in These key exchange methods are described in
<xref target="RFC8731" format="default"/> <xref target="RFC8731" format="default"/>
and and
<xref target="RFC8732" format="default"/> <xref target="RFC8732" format="default"/>
and are similar to the IKEv2 key agreement described in and are similar to the IKEv2 key agreement described in
<xref target="RFC8031" format="default"/>. <xref target="RFC8031" format="default"/>.
The curve25519-sha256 key exchange method has multiple The curve25519-sha256 key exchange method has multiple
implementations and SHOULD be implemented. implementations and <bcp14>SHOULD</bcp14> be implemented.
The gss-curve25519-sha256-* key exchange method SHOULD The gss-curve25519-sha256-* key exchange method <bcp14>SHOULD</bcp14 >
also be implemented because it shares the same performance also be implemented because it shares the same performance
and security characteristics as curve25519-sha256. and security characteristics as curve25519-sha256.
</t> </t>
<t> <t>
Table 6 contains a summary of the recommendations for <xref target="curve25519"/> contains a summary of the
curve25519 based key exchanges. recommendations for curve25519-based key exchanges.
</t> </t>
<!-- Table 6 --> <table align="center" anchor="curve25519">
<table align="center">
<name>Curve25519 Implementation Guidance</name> <name>Curve25519 Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">curve25519-sha256</td> <td align="left">curve25519-sha256</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-curve25519-sha256-*</td> <td align="left">gss-curve25519-sha256-*</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 3.1.2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>curve448-sha512 and gss-curve448-sha512-*</name> <name>curve448-sha512 and gss-curve448-sha512-*</name>
<t> <t>
Curve448 provides more security strength than Curve25519 Curve448 provides more security strength than curve25519
at a higher computational and bandwidth cost. at a higher computational and bandwidth cost.
The corresponding key exchange methods use SHA2-512 (also The corresponding key exchange methods use SHA2-512 (also known as
known as SHA-512) defined in SHA-512) defined in
<xref target="RFC6234" format="default"/>. <xref target="RFC6234" format="default"/>.
SHA2-512 is a reasonable hash for use in both the KDF and SHA2-512 is a reasonable hash for use in both the KDF and
session integrity. It is reasonable for both gss and session integrity. It is reasonable for both gss and
non-gss uses of curve448 key exchange methods. non-gss uses of curve448 key exchange methods.
These key exchange methods are described in These key exchange methods are described in
<xref target="RFC8731" format="default"/> <xref target="RFC8731" format="default"/>
and and
<xref target="RFC8732" format="default"/> <xref target="RFC8732" format="default"/>
and are similar to the IKEv2 key agreement described in and are similar to the IKEv2 key agreement described in
<xref target="RFC8031" format="default"/>. <xref target="RFC8031" format="default"/>.
The curve448-sha512 key exchange method MAY be The curve448-sha512 key exchange method <bcp14>MAY</bcp14> be
implemented. implemented.
The gss-curve448-sha512-* key exchange method MAY also be The gss-curve448-sha512-* key exchange method <bcp14>MAY</bcp14> als o be
implemented because it shares the same performance and implemented because it shares the same performance and
security characteristics as curve448-sha512. security characteristics as curve448-sha512.
</t> </t>
<t> <t>
Table 7 contains a summary of the recommendations for <xref target="curve448"/> contains a summary of the
curve448 based key exchanges. recommendations for curve448-based key exchanges.
</t> </t>
<!-- Table 7 --> <table align="center" anchor="curve448">
<table align="center">
<name>Curve448 Implementation Guidance</name> <name>Curve448 Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">curve448-sha512</td> <td align="left">curve448-sha512</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-curve448-sha512-*</td> <td align="left">gss-curve448-sha512-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 3.1.3. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name> <name>
ecdh-*, ecmqv-sha2, and gss-nistp* ecdh-*, ecmqv-sha2, and gss-nistp*
</name> </name>
<t> <t>
The ecdh-sha2-* name-space allows for both the named NIST The ecdh-sha2-* namespace allows for both the named NIST prime
prime curves (nistp256, nistp384, nistp521) as well as curves (nistp256, nistp384, and nistp521) as well as other curves
other curves to be defined for the Elliptic-curve to be defined for the ECDH key exchange.
Diffie-Hellman key exchange.
At the time of this writing, there are three named curves At the time of this writing, there are three named curves
in this name-space which SHOULD be supported. in this namespace that <bcp14>SHOULD</bcp14> be supported.
They appear in
<xref target="RFC5656" format="default"/>
in section 10.1 ("Required Curves"). They appear in <xref target="RFC5656" sectionFormat="of"
section="10.1" format="default"/>.
If implemented, the named curves SHOULD always be enabled If implemented, the named curves <bcp14>SHOULD</bcp14> always be ena bled
unless specifically disabled by local security policy. unless specifically disabled by local security policy.
In In <xref target="RFC5656" sectionFormat="of" section="6.1"
format="default"/>, the method to name other ECDH curves using
<xref target="RFC5656" format="default"/>,
section 6.1, the method to name other ECDH curves using
OIDs is specified. OIDs is specified.
These other curves MAY be implemented. These other curves <bcp14>MAY</bcp14> be implemented.
</t> </t>
<t> <t>
The GSS-API name-space with gss-nistp*-sha* mirrors the The GSS-API namespace with gss-nistp*-sha* mirrors the
algorithms used by ecdh-sha2-* names. algorithms used by ecdh-sha2-* names.
They are described in They are described in
<xref target="RFC8732" format="default"/>. <xref target="RFC8732" format="default"/>.
</t> </t>
<t> <t>
ECDH reduces bandwidth of key exchanges compared to ECDH reduces bandwidth of key exchanges compared to
FFC DH at a similar security strength. FFC DH at a similar security strength.
</t> </t>
<t> <t>
Table 8 lists algorithms as SHOULD where <xref target="ecdh_guidance"/> lists algorithms as
implementations may be more efficient or widely "<bcp14>SHOULD</bcp14>" where implementations may be more
deployed. efficient or widely deployed.
The items listed as MAY in Table 8 are potentially less The items listed as "<bcp14>MAY</bcp14>" in <xref
efficient. target="ecdh_guidance"/> are potentially less efficient.
</t> </t>
<!-- Table 8 --> <table anchor="ecdh_guidance" align="center">
<table align="center">
<name>ECDH Implementation Guidance</name> <name>ECDH Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">ecdh-sha2-*</td> <td align="left">ecdh-sha2-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp256</td> <td align="left">ecdh-sha2-nistp256</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp256-sha256-*</td> <td align="left">gss-nistp256-sha256-*</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp384</td> <td align="left">ecdh-sha2-nistp384</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp384-sha384-*</td> <td align="left">gss-nistp384-sha384-*</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp521</td> <td align="left">ecdh-sha2-nistp521</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp521-sha512-*</td> <td align="left">gss-nistp521-sha512-*</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecmqv-sha2</td> <td align="left">ecmqv-sha2</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
It is advisable to match the ECDSA and ECDH algorithms It is advisable to match the Elliptic Curve Digital Signature
to use the same curve for both to maintain the same Algorithm (ECDSA) and ECDH algorithm to use the same curve for
security strength in the connection. both to maintain the same security strength in the connection.
</t> </t>
</section> </section>
</section> </section>
<!-- Section 3.2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Finite Field Cryptography (FFC)</name> <name>Finite Field Cryptography (FFC)</name>
<!-- Section 3.2.1. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>FFC diffie-hellman using generated MODP groups</name> <name>FFC Diffie-Hellman Using Generated MODP Groups</name>
<t> <t>
<xref target="RFC4419" format="default"/> <xref target="RFC4419" format="default"/>
defines two key exchange methods that use a random defines two key exchange methods that use a random
selection from a set of pre-generated moduli for key selection from a set of pre-generated moduli for key
exchange: exchange:
the diffie-hellman-group-exchange-sha1 method, and the the diffie-hellman-group-exchange-sha1 method and the
diffie-hellman-group-exchange-sha256 method. diffie-hellman-group-exchange-sha256 method.
Per Per
<xref target="RFC8270" format="default"/>, <xref target="RFC8270" format="default"/>,
implementations SHOULD use a MODP group whose modulus size implementations <bcp14>SHOULD</bcp14> use a MODP group whose modulus size
is equal to or greater than 2048 bits. is equal to or greater than 2048 bits.
MODP groups with a modulus size less than 2048 bits are MODP groups with a modulus size less than 2048 bits are
weak and MUST NOT be used. weak and <bcp14>MUST NOT</bcp14> be used.
</t> </t>
<t> <t>
The diffie-hellman-group-exchange-sha1 key exchange method The diffie-hellman-group-exchange-sha1 key exchange method
SHOULD NOT be used. <bcp14>SHOULD NOT</bcp14> be used.
This method uses SHA-1, which is being deprecated. This method uses SHA-1, which is being deprecated.
</t> </t>
<t> <t>
The diffie-hellman-group-exchange-sha256 key exchange The diffie-hellman-group-exchange-sha256 key exchange
method MAY be used. method <bcp14>MAY</bcp14> be used.
This method uses SHA-256, which is reasonable for MODP This method uses SHA2-256, which is reasonable for MODP
groups less than 4000 bits. groups less than 4096 bits.
</t> </t>
<t> <t>
Care should be taken in the pre-generation of the moduli P Care should be taken in the pre-generation of the moduli P
and generator G such that the generator provides a and generator G such that the generator provides a
Q-ordered subgroup of P. Q-ordered subgroup of P.
Otherwise, the parameter set may leak one bit of the Otherwise, the parameter set may leak one bit of the
shared secret. shared secret.
</t> </t>
<t> <t>
Table 9 provides a summary of the Guidance for these <xref target="ffc_modp"/> provides a summary of the guidance for the se
exchanges. exchanges.
</t> </t>
<!-- Table 9 --> <table anchor="ffc_modp" align="center">
<table align="center">
<name>FFC Generated MODP Group Implementation Guidance</name> <name>FFC Generated MODP Group Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">diffie-hellman-group-exchange-sha1</td> <td align="left">diffie-hellman-group-exchange-sha1</td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group-exchange-sha256</td> <td align="left">diffie-hellman-group-exchange-sha256</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 3.2.2. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>FFC diffie-hellman using named MODP groups</name> <name>FFC Diffie-Hellman Using Named MODP Groups</name>
<t> <t>
The diffie-hellman-group14-sha256 key exchange method is The diffie-hellman-group14-sha256 key exchange method is
defined in defined in
<xref target="RFC8268" format="default"/> <xref target="RFC8268" format="default"/>
and represents a key exchange which has approximately and represents a key exchange that has approximately
112 bits of security strength that matches 3des-cbc 112 bits of security strength that matches 3des-cbc
symmetric cipher security strength. symmetric cipher security strength.
It is a reasonably simple transition from SHA-1 to SHA-2 It is a reasonably simple transition from SHA-1 to SHA-2, and
and given that diffie-hellman-group14-sha1 and given that diffie-hellman-group14-sha1 and
diffie-hellman-group14-sha256 share a MODP group and diffie-hellman-group14-sha256 share a MODP group and only differ
only differ in the hash function used for the KDF and in the hash function used for the KDF and integrity, it is a
integrity, it is a correspondingly simple transition correspondingly simple transition from implementing
from implementing diffie-hellman-group14-sha1 to diffie-hellman-group14-sha1 to implementing
implementing diffie-hellman-group14-sha256. diffie-hellman-group14-sha256.
Given that diffie-hellman-group14-sha1 is being removed Given that diffie-hellman-group14-sha1 is being removed
from mandatory to implement (MTI) status, the from mandatory to implement (MTI) status, the
diffie-hellman-group14-sha256 method MUST be diffie-hellman-group14-sha256 method <bcp14>MUST</bcp14> be
implemented. implemented.
The rest of the FFC MODP group from The rest of the FFC MODP group from
<xref target="RFC8268" format="default"/> <xref target="RFC8268" format="default"/>
have a larger number of security bits and are suitable have a larger number of security bits and are suitable
for symmetric ciphers that also have a similar number of for symmetric ciphers that also have a similar number of
security bits. security bits.
</t> </t>
<t> <t>
Table 10 below provides explicit guidance by name. <xref target="ffc_named_group"/> provides explicit guidance by nam e.
</t> </t>
<!-- Table 10 --> <table anchor="ffc_named_group" align="center">
<table align="center">
<name>FFC Named Group Implementation Guidance</name> <name>FFC Named Group Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">diffie-hellman-group14-sha256</td> <td align="left">diffie-hellman-group14-sha256</td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group14-sha256-*</td> <td align="left">gss-group14-sha256-*</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group15-sha512</td> <td align="left">diffie-hellman-group15-sha512</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group15-sha512-*</td> <td align="left">gss-group15-sha512-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group16-sha512</td> <td align="left">diffie-hellman-group16-sha512</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group16-sha512-*</td> <td align="left">gss-group16-sha512-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group17-sha512</td> <td align="left">diffie-hellman-group17-sha512</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group17-sha512-*</td> <td align="left">gss-group17-sha512-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group18-sha512</td> <td align="left">diffie-hellman-group18-sha512</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group18-sha512-*</td> <td align="left">gss-group18-sha512-*</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<!-- Section 3.3. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Integer Factorization Cryptography (IFC)</name> <name>Integer Factorization Cryptography (IFC)</name>
<t> <t>
The rsa1024-sha1 key exchange method is defined in The rsa1024-sha1 key exchange method is defined in
<xref target="RFC4432" format="default"/> <xref target="RFC4432" format="default"/>
and uses an RSA 1024-bit modulus with a SHA-1 hash. and uses an RSA 1024-bit modulus with a SHA-1 hash.
This key exchange does NOT meet security requirements. This key exchange does NOT meet security requirements.
This method MUST NOT be implemented. This method <bcp14>MUST NOT</bcp14> be implemented.
</t> </t>
<t> <t>
The rsa2048-sha256 key exchange method is defined in The rsa2048-sha256 key exchange method is defined in
<xref target="RFC4432" format="default"/> <xref target="RFC4432" format="default"/>
and uses an RSA 2048-bit modulus with a SHA2-256 hash. This key
and uses an RSA 2048-bit modulus with a SHA2-256 hash. exchange meets 112-bit minimum security strength. This method
<bcp14>MAY</bcp14> be implemented.
This key exchange meets 112 bit minimum security strength.
This method MAY be implemented.
</t> </t>
<t> <t>
Table 11 provide a summary of the guidance for IFC key exchanges. <xref target="ifc_guidance"></xref> provides a summary of the
guidance for IFC key exchanges.
</t> </t>
<!-- Table 11 --> <table anchor="ifc_guidance" align="center">
<table align="center">
<name>IFC Implementation Guidance</name> <name>IFC Implementation Guidance</name>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Guidance</th> <th align="left">Guidance</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">rsa1024-sha1</td> <td align="left">rsa1024-sha1</td>
<td align="left">MUST NOT</td> <td align="left"><bcp14>MUST NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">rsa2048-sha256</td> <td align="left">rsa2048-sha256</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- Section 3.4. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>KDFs and Integrity Hashing</name> <name>KDFs and Integrity Hashing</name>
<t> <t>
The SHA-1 and SHA-2 family of hashing algorithms are The SHA-1 and SHA-2 family of hashing algorithms are
combined with the FFC, ECC, and IFC algorithms to comprise a combined with the FFC, ECC, and IFC algorithms to comprise a
key exchange method name. key exchange method name.
</t> </t>
<t> <t>
skipping to change at line 1314 skipping to change at line 1287
security concerns for SHA-1, as documented in security concerns for SHA-1, as documented in
<xref target="RFC6194" format="default"/>. <xref target="RFC6194" format="default"/>.
</t> </t>
<t> <t>
Unconditionally deprecating and/or disallowing SHA-1 Unconditionally deprecating and/or disallowing SHA-1
everywhere will hasten the day when it may be simply removed everywhere will hasten the day when it may be simply removed
from implementations completely. from implementations completely.
Leaving partially-broken algorithms lying around is not a Leaving partially broken algorithms lying around is not a
good thing to do. good thing to do.
</t> </t>
<t> <t>
The SHA-2 Family of hashes The SHA-2 family of hashes
<xref target="RFC6234" format="default"/> <xref target="RFC6234" format="default"/>
is more secure than SHA-1. They have been standardized for is more secure than SHA-1. They have been standardized for
use in SSH with many of the currently defined key exchanges. use in SSH with many of the currently defined key exchanges.
</t> </t>
<t> <t>
Please note that at the present time, there is no key Please note that at the present time, there is no key
exchange method for Secure Shell which uses the SHA-3 family exchange method for Secure Shell that uses the SHA-3 family
of Secure Hashing functions or the Extendable Output of secure hashing functions or the Extendable-Output
Functions. Functions <xref target="NIST.FIPS.202" format="default"/>.
</t> </t>
<t> <t>
Prior to the changes made by this document, Prior to the changes made by this document,
diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1
were MTI. were MTI.
diffie-hellman-group14-sha1 is the stronger of the two. diffie-hellman-group14-sha1 is the stronger of the two.
Group14 (a 2048-bit MODP group) is defined in Group14 (a 2048-bit MODP group) is defined in
<xref target="RFC3526" format="default"/>. <xref target="RFC3526" format="default" sectionFormat="of"
section="3"/>.
The group1 MODP group with approximately 80 bits of security The SSH group1 is defined in <xref target="RFC4253" sectionFormat="of"
is too weak to be retained. section="8.1"/> as using the Oakley Group 2 provided in <xref target="
RFC2409"
sectionFormat="of" section="6.2"/> (a 1024-bit MODP group). This
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 However, rather than jumping from the MTI status to making it
disallowed, many implementers suggested that it should disallowed, many implementers suggested that it should transition to
transition to deprecated first and be disallowed at a later deprecated first and be disallowed at a later time.
time.
The group14 MODP group using a sha1 hash for the KDF is not The group14 MODP group using a SHA-1 hash for the KDF is not
as weak as the group1 MODP group. as weak as the group1 MODP group.
There are some legacy situations where it will still provide There are some legacy situations where it will still provide
administrators with value, such as small hardware IOT administrators with value, such as small hardware Internet of Things
devices which have insufficient compute and memory resources (IOT) devices that have insufficient compute and memory resources to
to use larger MODP groups before a timeout of the session use larger MODP groups before a timeout of the session occurs.
occurs.
Transitioning from MTI to a requirement status that provides There was consensus to transition from MTI to a requirement status
for continued use with the expectation of deprecating or that provides for continued use with the expectation that it would
disallowing it in the future was able to find consensus. be deprecated or disallowed in the future.
Therefore, it is considered reasonable to retain the Therefore, it is considered reasonable to retain the
diffie-hellman-group14-sha1 exchange for interoperability diffie-hellman-group14-sha1 exchange for interoperability
with legacy implementations. with legacy implementations.
The diffie-hellman-group14-sha1 key exchange MAY be The diffie-hellman-group14-sha1 key exchange <bcp14>MAY</bcp14> be
implemented, but should be put at the end of the list of implemented, but should be put at the end of the list of
negotiated key exchanges. negotiated key exchanges.
</t> </t>
<t> <t>
The diffie-hellman-group1-sha1 and The diffie-hellman-group1-sha1 and
diffie-hellman-group-exchange-sha1 SHOULD NOT be diffie-hellman-group-exchange-sha1 <bcp14>SHOULD NOT</bcp14> be
implemented. implemented.
The gss-group1-sha1-*, gss-group14-sha1-*, and The gss-group1-sha1-*, gss-group14-sha1-*, and
gss-gex-sha1-* key exchanges are already specified as SHOULD gss-gex-sha1-* key exchanges are already specified as <bcp14>SHOULD
NOT be implemented by NOT</bcp14> be implemented by
<xref target="RFC8732" format="default"/>. <xref target="RFC8732" format="default"/>.
</t> </t>
</section> </section>
<!-- Section 3.5. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Secure Shell Extension Negotiation</name> <name>Secure Shell Extension Negotiation</name>
<t> <t>
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
<xref target="RFC8308" format="default"/>. <xref target="RFC8308" format="default"/>.
They provide a mechanism to support other Secure Shell They provide a mechanism to support other Secure Shell
negotiations. negotiations.
Being able to extend functionality is desirable. Being able to extend functionality is desirable.
Both ext-info-c and ext-info-s SHOULD be implemented. Both ext-info-c and ext-info-s <bcp14>SHOULD</bcp14> be implemented.
</t> </t>
</section> </section>
</section> </section>
<!-- Section 4. --> <section numbered="true" toc="default" anchor="key_ex_method">
<section numbered="true" toc="default">
<name> <name>
Summary Guidance for Key Exchange Method Names Implementations Summary Guidance for Implementation of Key Exchange Method Names
</name> </name>
<t> <t>
The Implement column is the current recommendations of this <xref target="iana_key_exchange"/> provides the existing key exchange me
RFC. thod names
Table 12 provides the existing key exchange method names
listed alphabetically. listed alphabetically.
The Implement column contains the current recommendations of this RFC.
</t> </t>
<!-- Table 12 --> <table align="center" anchor="iana_key_exchange">
<table align="center"> <name>IANA Guidance for Implementation of Key Exchange Method Names</nam
<name>IANA guidance for key exchange method name implementations</name> e>
<thead> <thead>
<tr> <tr>
<th align="left">Key Exchange Method Name</th> <th align="left">Key Exchange Method Name</th>
<th align="left">Reference</th> <th align="left">Reference</th>
<th align="left">Previous Recommendation</th> <th align="left">Previous Recommendation</th>
<!--
RFC EDITOR TODO
The RFCxxxxx should be replaced with the RFC of this <th align="left">RFC 9142 Implement</th>
document.
-->
<th align="left">RFCxxxxx Implement</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">curve25519-sha256</td> <td align="left">curve25519-sha256</td>
<td align="left">RFC8731</td> <td align="left"><xref target="RFC8731"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">curve448-sha512</td> <td align="left">curve448-sha512</td>
<td align="left">RFC8731</td> <td align="left"><xref target="RFC8731"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group-exchange-sha1</td> <td align="left">diffie-hellman-group-exchange-sha1</td>
<td align="left">RFC4419 RFC8270</td> <td align="left"><xref target="RFC4419"/>, <xref target="RFC8270"/>< /td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group-exchange-sha256</td> <td align="left">diffie-hellman-group-exchange-sha256</td>
<td align="left">RFC4419 RFC8720</td> <td align="left"><xref target="RFC4419"/>, <xref target="RFC8270"/>< /td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group1-sha1</td> <td align="left">diffie-hellman-group1-sha1</td>
<td align="left">RFC4253</td> <td align="left"><xref target="RFC4253"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group14-sha1</td> <td align="left">diffie-hellman-group14-sha1</td>
<td align="left">RFC4253</td> <td align="left"><xref target="RFC4253"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group14-sha256</td> <td align="left">diffie-hellman-group14-sha256</td>
<td align="left">RFC8268</td> <td align="left"><xref target="RFC8268"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group15-sha512</td> <td align="left">diffie-hellman-group15-sha512</td>
<td align="left">RFC8268</td> <td align="left"><xref target="RFC8268"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group16-sha512</td> <td align="left">diffie-hellman-group16-sha512</td>
<td align="left">RFC8268</td> <td align="left"><xref target="RFC8268"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group17-sha512</td> <td align="left">diffie-hellman-group17-sha512</td>
<td align="left">RFC8268</td> <td align="left"><xref target="RFC8268"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">diffie-hellman-group18-sha512</td> <td align="left">diffie-hellman-group18-sha512</td>
<td align="left">RFC8268</td> <td align="left"><xref target="RFC8268"/></td>
<td align="left">none</td> <td align="left">none</td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-*</td> <td align="left">ecdh-sha2-*</td>
<td align="left">RFC5656</td> <td align="left"><xref target="RFC5656"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp256</td> <td align="left">ecdh-sha2-nistp256</td>
<td align="left">RFC5656</td> <td align="left"><xref target="RFC5656"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp384</td> <td align="left">ecdh-sha2-nistp384</td>
<td align="left">RFC5656</td> <td align="left"><xref target="RFC5656"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecdh-sha2-nistp521</td> <td align="left">ecdh-sha2-nistp521</td>
<td align="left">RFC5656</td> <td align="left"><xref target="RFC5656"/></td>
<td align="left">MUST</td> <td align="left"><bcp14>MUST</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ecmqv-sha2</td> <td align="left">ecmqv-sha2</td>
<td align="left">RFC5656</td> <td align="left"><xref target="RFC5656"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ext-info-c</td> <td align="left">ext-info-c</td>
<td align="left">RFC8308</td> <td align="left"><xref target="RFC8308"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">ext-info-s</td> <td align="left">ext-info-s</td>
<td align="left">RFC8308</td> <td align="left"><xref target="RFC8308"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-</td> <td align="left">gss-</td>
<td align="left">RFC4462</td> <td align="left"><xref target="RFC4462"/></td>
<td align="left">reserved</td> <td align="left">reserved</td>
<td align="left">reserved</td> <td align="left">reserved</td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-curve25519-sha256-*</td> <td align="left">gss-curve25519-sha256-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-curve448-sha512-*</td> <td align="left">gss-curve448-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-gex-sha1-*</td> <td align="left">gss-gex-sha1-*</td>
<td align="left">RFC4462/RFC8732</td> <td align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/><
<td align="left">SHOULD NOT</td> /td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group1-sha1-*</td> <td align="left">gss-group1-sha1-*</td>
<td align="left">RFC4462/RFC8732</td> <td align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/><
<td align="left">SHOULD NOT</td> /td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group14-sha1-*</td> <td align="left">gss-group14-sha1-*</td>
<td align="left">RFC4462/RFC8732</td> <td align="left"><xref target="RFC4462"/>, <xref target="RFC8732"/><
<td align="left">SHOULD NOT</td> /td>
<td align="left">SHOULD NOT</td> <td align="left"><bcp14>SHOULD NOT</bcp14></td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group14-sha256-*</td> <td align="left">gss-group14-sha256-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group15-sha512-*</td> <td align="left">gss-group15-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group16-sha512-*</td> <td align="left">gss-group16-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group17-sha512-*</td> <td align="left">gss-group17-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-group18-sha512-*</td> <td align="left">gss-group18-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp256-sha256-*</td> <td align="left">gss-nistp256-sha256-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp384-sha384-*</td> <td align="left">gss-nistp384-sha384-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">gss-nistp521-sha512-*</td> <td align="left">gss-nistp521-sha512-*</td>
<td align="left">RFC8732</td> <td align="left"><xref target="RFC8732"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">SHOULD</td> <td align="left"><bcp14>SHOULD</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">rsa1024-sha1</td> <td align="left">rsa1024-sha1</td>
<td align="left">RFC4432</td> <td align="left"><xref target="RFC4432"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MUST NOT</td> <td align="left"><bcp14>MUST NOT</bcp14></td>
</tr> </tr>
<tr> <tr>
<td align="left">rsa2048-sha256</td> <td align="left">rsa2048-sha256</td>
<td align="left">RFC4432</td> <td align="left"><xref target="RFC4432"/></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
<td align="left">MAY</td> <td align="left"><bcp14>MAY</bcp14></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The full set of official The full set of official
<xref target="IANA-KEX" format="default"/> <xref target="IANA-SSH" format="default"/>
key algorithm method names not otherwise mentioned in this
document MAY be implemented.
</t>
<t>
[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.
]
</t>
</section>
<!-- Section 5. -->
<section numbered="true" toc="default">
<name>Acknowledgements</name>
<t>
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.
</t>
<t>
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, "Key Exchange Method Names" not otherwise mentioned in this document
Tera Term (ttssh) and Poderosa implementations also adopting <bcp14>MAY</bcp14> be implemented.
new Diffie-Hellman groups based on this draft.
</t> </t>
</section> </section>
<!-- Section 6. -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This SSH protocol provides a secure encrypted channel over an This SSH protocol provides a secure encrypted channel over an
insecure network. insecure network.
It performs server host authentication, key exchange, It performs server host authentication, key exchange,
encryption, and integrity checks. encryption, and integrity checks.
It also derives a unique session ID that may be used by It also derives a unique session ID that may be used by
higher-level protocols. higher-level protocols.
The key exchange itself generates a shared secret and uses The key exchange itself generates a shared secret and uses
the hash function for both the KDF and integrity. the hash function for both the KDF and integrity.
</t> </t>
<t> <t>
Full security considerations for this protocol are provided in Full security considerations for this protocol are provided in <xref
target="RFC4251" format="default"/> and continue to apply. In addition,
<xref target="RFC4251" format="default"/> continue to apply. the security considerations provided in <xref target="RFC4432"
format="default"/> apply.
In addition, the security considerations provided in
<xref target="RFC4432" format="default"/> apply.
Note that Forward Secrecy is NOT available with the Note that Forward Secrecy is NOT available with the
rsa1024-sha1 or rsa2048-sha256 key exchanges. rsa1024-sha1 or rsa2048-sha256 key exchanges.
</t> </t>
<t> <t>
It is desirable to deprecate or disallow key exchange methods It is desirable to deprecate or disallow key exchange methods
that are considered weak, so they are not in still actively in that are considered weak so they are not still actively in
operation when they are broken. operation when they are broken.
</t> </t>
<t> <t>
A key exchange method is considered weak when the security A key exchange method is considered weak when the security
strength is insufficient to match the symmetric cipher or the strength is insufficient to match the symmetric cipher or the
algorithm has been broken. algorithm has been broken.
</t> </t>
<t> <t>
skipping to change at line 1776 skipping to change at line 1699
algorithm as soon as possible. algorithm as soon as possible.
</t> </t>
<t> <t>
The diffie-hellman-group14-sha1 algorithm is not yet The diffie-hellman-group14-sha1 algorithm is not yet
completely deprecated. completely deprecated.
This is to provide a practical transition from the MTI This is to provide a practical transition from the MTI
algorithms to a new one. algorithms to a new one.
However, it would be best to only be as a last resort in key However, it would be best to only be used as a last resort in key
exchange negotiations. exchange negotiations.
All key exchange methods using the SHA-1 hash are to be All key exchange methods using the SHA-1 hash are to be
considered as deprecated. considered as deprecated.
</t> </t>
</section> </section>
<!-- Section 7. -->
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
IANA is requested to add a new column to IANA has added a new column to the "Key Exchange Method Names"
registry <xref target="IANA-SSH" format="default"/> with the heading
<xref target="IANA-KEX" format="default"/> "OK to Implement" and annotated entries therein with the
implementation guidance provided in <xref target="key_ex_method"/>,
with heading "OK to Implement", and to annotate entries "Summary Guidance for Implementation of Key Exchange Method Names", in
therein with the implementation guidance provided in section 4 this document. IANA also added entries for ecdh-sha2-nistp256, ecdh-sha
"Summary Guidance for Key Exchange Method Names 2-nistp384, and ecdh-sha2-nistp521, and added references to <xref target="RFC446
Implementation" in this document. 2"/> and <xref target="RFC8732"/> for gss-gex-sha1-*, gss-group1-sha1-*, gss-gro
up14-sha1-*, diffie-hellman-group-exchange-sha1, and diffie-hellman-group-exchan
A summary may be found in Table 12 in section 4. ge-sha256. A summary may be found in <xref
target="iana_key_exchange"/> in <xref target="key_ex_method"/>. IANA
IANA is additionally requested to include this document as an has also included this document as an additional registry reference
additional reference for the for the suggested implementation guidance provided in <xref
target="key_ex_method"/> of this document and added a note indicating th
with the suggested implementation guidance provided in e following:</t>
section 4 "Summary Guidance for Key Exchange Method Names
Implementation" in this document.
<xref target="IANA-KEX" format="default"/>
registry.
Registry entries annotated with "MUST NOT" are <blockquote>OK to Implement guidance entries for registrations that pre-date [RF
considered disallowed. C9142] are found in Table 12 in Section 4 of [RFC9142].</blockquote>
Registry entries annotated with "SHOULD NOT" are deprecated and <t>Registry entries
may be disallowed in the future. annotated with "<bcp14>MUST NOT</bcp14>" are considered disallowed.
Registry entries annotated with "<bcp14>SHOULD NOT</bcp14>" are
deprecated and may be disallowed in the future.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- Section 8. -->
<references> <references>
<name>References</name> <name>References</name>
<!-- Section 8.1. -->
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4250.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4250.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4253.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4253.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8268.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8268.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8270.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8270.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8308.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8308.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8731.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8731.xml"/>
</references> </references>
<!-- Section 8.2. -->
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- Here we use entities that we defined at the beginning. -->
<reference <reference
anchor="IANA-KEX" anchor="IANA-SSH"
target="https://www.iana.org/assignments/ssh-parameters/ssh-paramete target="https://www.iana.org/assignments/ssh-parameters/">
rs.xhtml#ssh-parameters-16">
<front> <front>
<title>Secure Shell (SSH) Protocol Parameters: <title>Secure Shell (SSH) Protocol Parameters</title>
Key Exchange Method Names</title>
<author fullname="IANA"> <author fullname="IANA">
<organization>Internet Assigned Numbers Authority (IANA) <organization>Internet Assigned Numbers Authority
</organization> </organization>
</author> </author>
<date month="July" year="2021"/>
</front> </front>
</reference> </reference>
<reference
anchor="NIST.FIPS.202"
>
<front>
<title>
SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions
</title>
<author>
<organization>
National Institute of Standards and Technology
</organization>
</author>
<date year="2015" month="August"/>
</front>
<refcontent>FIPS PUB 202</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference>
<reference <reference
anchor="NIST.SP.800-57pt1r5" anchor="NIST.SP.800-57pt1r5"
target="https://doi.org/10.6028/NIST.SP.800-57pt1r5"> >
<front> <front>
<title> <title>
Recommendation for Key Management - Part 1 - General Recommendation for Key Management: Part 1 - General
</title> </title>
<author initials="E" surname="Barker" fullname="Elaine Barker"> <author initials="E" surname="Barker" fullname="Elaine Barker">
<organization> <organization>
National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST)
</organization> </organization>
</author> </author>
<date year="2020" month="may"/> <date year="2020" month="may"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference> </reference>
<reference <reference anchor="NIST.SP.800-107r1">
anchor="NIST.SP.800-107r1"
target="https://doi.org/10.6028/NIST.SP.800-107r1">
<front> <front>
<title> <title>
Recommendation for applications using approved hash algorithms Recommendation for applications using approved hash algorithms
</title> </title>
<author initials="Q" surname="Dang" fullname="Quynh Dang"> <author initials="Q" surname="Dang" fullname="Quynh Dang">
<organization> <organization>
National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST)
</organization> </organization>
</author> </author>
<date year="2012" month="August"/> <date year="2012" month="August"/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-107r1"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-107r1"/>
</reference> </reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere nce.RFC.2409.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3526.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.3526.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4086.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4251.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4251.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4419.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4419.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4432.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4432.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4462.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4462.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.5656.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.5656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6194.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6194.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6234.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7748.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7748.xml"/>
skipping to change at line 1909 skipping to change at line 1834
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4086.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4086.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4251.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4251.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4419.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4419.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4432.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4432.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4462.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.4462.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.5656.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.5656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6194.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6194.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6234.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.6234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7748.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7748.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8031.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8031.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8732.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.8732.xml"/>
<reference <reference
anchor="TRANS-COLL" anchor="TRANSCRIPTION">
target="https://hal.inria.fr/hal-01244855/document"> <front>
<front>
<title> <title>
Transcript Collision Attacks: Transcript Collision Attacks:
Breaking Authentication in TLS, IKE, and SSH Breaking Authentication in TLS, IKE, and SSH
</title> </title>
<author fullname="Karthikeyan Bhargavan"> <author fullname="Karthikeyan Bhargavan">
</author> </author>
<author fullname="Gaeutan Leurent"> <author fullname="Gaeutan Leurent">
</author> </author>
</front> <date month="February" year="2016"/>
<seriesInfo </front>
name="Network and Distributed System Security Symposium – NDSS 2 <refcontent>Network and Distributed System Security Symposium (NDSS)</
016, Feb 2016, San Diego, United States." refcontent>
value="10.14722/ndss.2016.23418 . hal-01244855"/> <seriesInfo name="DOI" value="10.14722/ndss.2016.23418"/>
</reference>
</references>
</references>
<!-- Change Log
v00 2015-12-10 MDB Initial version
v01 2015-12-10 MDB Fix SHA1 -> SHA-1 for the name of the algorithm.
Add recommendation that DH-group14-sha256 be
in the negotiation list before DH-group14-sha1.
v02 2016-02-12 MDB List all of the key exchange methods currently
listed in the IANA registry for Secure Shell.
Update the rationale.
v03 2016-02-13 MDB Adopt some feedback from the list.
v04 2016-02-14 MDB Update Title to include the text 'Secure Shell'
Drop references to group15 and group17. Fix text
to use group16 and group18.
v05 2016-02-19 MDB Demote ecdh-sha2-nistp384 to SHOULD from MUST.
Reference safecurves.cr.yp.to as justification.
v06 2016-03-01 MDB Clarify RFC5656 SSH ECC MUST requirements.
Update to I-D.draft-josefsson-ssh-curves-04.
Add acknowledgements section.
v00 2016-03-07 MDB Rename as draft-ietf-curdle-ssh-kex-sha2-00
from draft-baushke-ssh-dh-group-sha2-06
v01 2016-03-08 MDB Reference new draft-ietf-curdle-ssh-curves-00.xml
instead of draft-josefsson-ssh-curves-04.xml
v02 2016-03-08 MDB Problems with the -01 upload occurred.
v03 2015-03-14 MDB Clear up abstract and implementation text on
advice of Daniel Migault. Use new title too.
v04 2016-09-05 MDB Peter Gutman suggests that the embedded world
needs DH-2048+SHA-256 for performance issues.
denis bider requests that entries be made for
both Group 15 and Group 17. Group 15 is also
explicitly referenced in the CNSA Suite.
v05 2016-09-20 MDB Split the MODP implementation to
draft-ietf-curdle-ssh-modp-dh-sha2 and add gss-*
entries to the table. Use 'SHOULD NOT' for
'ecmqv-sha2' per suggestion by Damien Miller.
Add clarity to GSS-API SHOULD requirements.
Adjust texttable entries.
v06 2017-03-27 MDB Point to the GSS Keyex SHA2 draft given in
draft-ssorce-gss-keyex-sha2-00.
Remove some left-over MODP text.
General reformatting.
v07 2017-03-27 MDB Update references.
v08 2017-04-16 MDB Clean up nits.
v09 2017-07-17 MDB Input from Tero Kivinen and IETF meeting minutes.
Try to clear up confusion by listing all known
Kex methods and explicitly providing information
on why they are MUST, SHOULD, MAY, SHOULD NOT,
or MUST NOT implement.
v11 2018-02-24 MDB Address Eric Rescorla comments.
v11 2020-07-12 MDB Update references and guidance. Add a few key
exchanges that are in the IANA table, but were
not present in previous versions.
v12 2020-07-31 MDB Convert from v2 to v3 of the IETF RFC xml form.
v12 2020-11-23 MDB Re-ordered sections and rewrote most of the
document.
v13 2021-01-14 MDB Add a larger list of RFCs to the updates="" list.
for Benjamin Kaduk, Tero Kivinen, Hubert Kario,
and Simo Sorce.
Key Exchange Method Name | pre draft | Implement
curve25519-sha256 | - | SHOULD
curve448-sha512 | - | MAY
diffie-hellman-group-exchange-sha1 | - | SHOULD NOT
diffie-hellman-group-exchange-sha256 | - | MAY
diffie-hellman-group1-sha1 | MUST | SHOULD NOT
diffie-hellman-group14-sha1 | MUST | MAY
diffie-hellman-group14-sha256 | - | MUST
diffie-hellman-group15-sha512 | - | MAY
diffie-hellman-group16-sha512 | - | SHOULD
diffie-hellman-group17-sha512 | - | MAY
diffie-hellman-group18-sha512 | - | MAY
ecdh-sha2-* | MAY | MAY
ecdh-sha2-nistp256 | MUST | SHOULD
ecdh-sha2-nistp384 | MUST | SHOULD
ecdh-sha2-nistp521 | MUST | SHOULD
ecmqv-sha2 | MAY | MAY
ext-info-c | SHOULD | SHOULD
ext-info-s | SHOULD | SHOULD
gss- | reserved | reserved
gss-curve25519-sha256-* | SHOULD | SHOULD
gss-curve448-sha512-* | MAY | MAY
gss-gex-sha1-* | SHOULD NOT| SHOULD NOT
gss-group1-sha1-* | SHOULD NOT| SHOULD NOT
gss-group14-sha256-* | SHOULD | SHOULD
gss-group15-sha512-* | MAY | MAY
gss-group16-sha512-* | SHOULD | MAY
gss-group17-sha512-* | MAY | MAY
gss-group18-sha512-* | MAY | MAY
gss-nistp256-sha256-* | SHOULD | SHOULD
gss-nistp384-sha384-* | MAY | MAY
gss-nistp521-sha512-* | MAY | MAY
rsa1024-sha1 | MAY | MUST NOT
rsa2048-sha256 | MAY | MAY
v14 2021-02-10 MDB Address AD comments from Benjamin Kaduk.
v15 2021-03-17 MDB - Address IANA issue from Sabrina Tanamal.
- The IANA section needs to incorporate
information from Table 6 in section 4.
- Add XML comments for each table. Add RFC8270
references for RFC4419 entries.
- Removed SHOULD keyword from 1.2.2.
- Revised section 1.2.3 to avoid "sufficient"
security.
- Section 1.2.3 provide more details.
- section 3.1 provide better guidance on
retaining diffie-hellman-group14-sha1
- Avoid 'only one which is more secure' and
provide a note concerning SHA-3
- Drop "All of the NISTP curves named therein
are mandatory to implement if any of that RFC
is implemented." text.
- Augment security considerations.
- Augment Table 7 for IANA.
- Moved hash discussions after FFC, ECC, IFC
elements.
- Add a few more Ben Kaduk suggested changes.
v16 2021-04-15 MDB - Update author organization and email address.
- Incoprorate comments from James Ralston and
Ben Kaduk.
v17 2021-04-12 MDB - Update author organization and email address.
v18 2021-04-22 MDB - Simon Tatham <anakin@pobox.com> issue in 3.1.2
2021-05-12 MDB - Ben Kaduk suggested changes.
V19 2021-06-25 MDB - Ben Kaduk suggested changes.
V20 2021-07-16 MDB - Ben Kaduk suggested changes for IANA section 7.
through
2021-07-28 MDB - Address other comments made on the -19 draft.
- Lars Eggert <lars@eggert.org>: section 1 nit
s/against SHA-1 and/against SHA1, and/
Changed sentence to "Attacks against SHA-1 are collision attacks
that usually rely on human help, rather than a pre-image attack."
DONE.
- Roman Danyliw <rdd@cert.org>: section 1
s/sha1, sha256, sha384, and sha512/SHA-1, SHA-256, SHA-384, and
SHA-512/
I have added a paragraph:
Various RFCs use different spellings and capitalizaitons 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;
aes128 and AES128; aes192 and AES192; aes256 and AES256.
DONE.
- Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
I didn't find this correct for the all the MAY in the table 12.
some MAY also remains MAY.
Added sentence: "Some recommendations will be unchanged, but are
included for completeness."
DONE.
- Lars Eggert <lars@eggert.org>: update section 1.1 update term
"man" to an alternative.
- Martin Duke <martin.h.duke@gmail.com>: section 1.1
s/man in the middle/on-path attacker/
- Roman Danyliw <rdd@cert.org>: section 1.1
s/man in the middle/on path attacker/
Changed to "on-path attacker"
DONE.
- Lars Eggert <lars@eggert.org>: update section 1.1 "but is is"
nit.
- Lars Eggert <lars@eggert.org>: update section 1.1 "but it be"
nit. s/but it be/but it is/
- Roman Danyliw <rdd@cert.org>: section 1.1
s/is is/it is/
- Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
s/but is is/but it is/
Changed to "it is"
DONE.
- Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>:
Should this be modified to use normative language?
"It is suggested " -> "It is RECOMMENDED "
Normative language should not exist in the introduction.
Rejected modified language.
- Martin Duke <martin.h.duke@gmail.com>: section 1.1 "It is suggested
that the minimum secure hashing function that should be used for
key exchange methods is SHA2-256"
After the previous sentence just went to the effort of defining
the security strength of the SHA-* algorithms by bits, is there a
reason the minimum strength baseline is framed as an algorithm
name rather than a number of bits?
Changed to
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 an RFC for use in a KEX for
SSH.
DONE.
- John Scudder <jgs@juniper.net>: update section 1.2
s/It is desirable for/It is desirable that/
DONE.
- Roman Danyliw <rdd@cert.org>: section 1.2.2
s/sha256/SHA-256/
s/aes128/AES-128/
s/aes192/AES-192/
Addressed with a section 1 paragraph.
- Roman Danyliw <rdd@cert.org>: section 1.2.2
s/Cipher/cipher/
DONE.
- Lars Eggert <lars@eggert.org>: section 1.2.2
s/RSA 1024 bit/RSA 1024-bit/
s/RSA 2048 bit/RSA 2048-bit/g
DONE.
- Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>: section 3:
Can we stick to one way of referencing the same document? either
"this memo" or "this document"? we have three paragraphs
referencing the same in three different ways.
I replaced 'memo' with 'document'
DONE.
- Martin Duke <martin.h.duke@gmail.com>: section 3.1.1 Unable to
parse "is a reasonable hash" Ben Kaduk addressed this comment.
To partially address this comment, I have added the following text
to section 3.1 to try to clear up the confusion.
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.
DONE.
- Martin Duke <martin.h.duke@gmail.com>: section 3.1.1 Unable to
parse "is a reasonable hash" Ben Kaduk addressed this comment.
- Lars Eggert <lars@eggert.org>: section 3.1.1 nit usage error
"as well as" use "and" after "both"
Used this replacement text:
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.
ADDRESSED.
- Lars Eggert <lars@eggert.org>: update section 3.1.1 update term
"traditional" to an alternative.
Changed "traditional elliptic curves" to "the patented elliptic
curve parameters purchased by NIST for the general public to use
and described in RFC5656."
DONE.
- Martin Duke <martin.h.duke@gmail.com>: section 3.1.2 Unable to
parse "is a reasonable hash" Ben Kaduk addressed this comment.
I have added the following text to section 3.1 to try to clear up
the confusion.
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.
DONE.
- Roman Danyliw <rdd@cert.org>: section 3.2.1
s/4K/4000/
DONE.
- John Scudder <jgs@juniper.net>: update section 3.2.2
spell out MTI on first use. Use the abbreviation in section 3.4.
DONE.
- Lars Eggert <lars@eggert.org>: section 3.2.2 nit usage error
"as well as" use "and" after "both"
I think you meant section 3.1.2? I have updated to
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.
ADDRESSED.
- Lars Eggert <lars@eggert.org>: section 3.2.2 nit usage error
s/laying around/lying around/
DONE
- Roman Danyliw <rdd@cert.org>: section 3.4
This section notes that some legacy situations would find
group14 useful. Could you elaborate on that situation?
I have added:
", such as small hardware IOT
devices which have insufficient compute and memory resources
to use larger MODP groups before a timeout of the session
occurs."
DONE
- Roman Danyliw <rdd@cert.org>: section 3.4
s/key exchanges methods/key exchange methods/
DONE.
- Lars Eggert <lars@eggert.org>: section 4, paragraph 3 "in an"
was "and" or "any" intended?
"in any" was intended.
DONE.
- Lars Eggert <lars@eggert.org>: section 4, paragraph 3 "weak so"
may need a comma before "so"
DONE.
- Lars Eggert <lars@eggert.org>: Convert http:// to https:// where
possible.
DONE.
- John Scudder <jgs@juniper.net>: desires general guidance in section
3 about minimal properties a method should have to qualify for
MAY, vs SHOULD NOT or MUST NOT.
DONE.
- Roman Danyliw <rdd@cert.org>: table 1, 2, 4, 5 need to have a
citation on the basis of the estimated security strengths
* Table 1: NIST 800-57Part1R5, Section 5.6.1.1
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.p
df)
I have added a reference to RFC4086 for triple-DES and aes128
strength as well as "various governmental and cryptographic
sources." to try to avoid using NIST URLs or DOIs which are not
entirely trusted by non-US implementers and administrators.
DOI: 10.6028/NIST.SP.800-57pt1r5
DONE.
* Table 2: NIST 800-107r1 Section 4
(https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1
.pdf);
and also note that this security strength is collision resistance
DOI: 10.6028/NIST.SP.800-107r1
I noted for collision resistance.
Table 2 provides a summary of security strength for hashing
functions for collision resistance.
DONE. </reference>
* Table 3: RFC7748 for Curve25519 and Curve448; NIST curves is ?? </references>
</references>
NIST curve strengths are in RFC5656. <section numbered="false" toc="default">
<name>Acknowledgements</name>
* Table 5: NIST 800-57Part1R5, Section 5.6.1.1 <t>
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.p Thanks to the following people for review and comments: <contact
df) fullname="Denis Bider"/>, <contact fullname="Peter Gutmann"/>,
<contact fullname="Damien Miller"/>, <contact fullname="Niels
Moeller"/>, <contact fullname="Matt Johnston"/>, <contact
fullname="Iwamoto Kouichi"/>, <contact fullname="Simon Josefsson"/>,
<contact fullname="Dave Dugal"/>, <contact fullname="Daniel
Migault"/>, <contact fullname="Anna Johnston"/>, <contact
fullname="Tero Kivinen"/>, and <contact fullname="Travis
Finkenauer"/>.
</t>
DOI: 10.6028/NIST.SP.800-57pt1r5 <t>
Thanks to the following people for code to implement interoperable
exchanges using some of these groups as found in this document: <contact
fullname="Darren Tucker"/> for OpenSSH and <contact fullname="Matt
Johnston"/> for Dropbear.
- Update directions to IANA in section 7 per Benjamin Kaduk And thanks to <contact fullname="Iwamoto Kouichi"/> for information abou
<kaduk@mit.edu>. t RLogin,
DONE. Tera Term (ttssh), and Poderosa implementations also adopting
new Diffie-Hellman groups based on this document.
</t>
--> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 269 change blocks. 
992 lines changed or deleted 537 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/