idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4462, but the abstract doesn't seem to directly say this. It does mention RFC4462 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4250, updated by this document, for RFC5378 checks: 2002-06-20) (Using the creation date from RFC4253, updated by this document, for RFC5378 checks: 1997-03-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (6 August 2021) is 995 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. D. Baushke 3 Internet-Draft 6 August 2021 4 Updates: 4250 4253 4432 4462 (if approved) 5 Intended status: Standards Track 6 Expires: 7 February 2022 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-20 12 Abstract 14 This document is intended to update the recommended set of key 15 exchange methods for use in the Secure Shell (SSH) protocol to meet 16 evolving needs for stronger security. This document updates RFC 17 4250, RFC 4253, RFC 4432, and RFC 4462. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 7 February 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2 53 1.1. Selecting an appropriate hashing algorithm . . . . . . . 4 54 1.2. Selecting an appropriate Public key Algorithm . . . . . . 5 55 1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 6 56 1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 7 57 1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 8 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 9 59 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 10 61 3.1.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 10 62 3.1.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 11 63 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* . . . . . . . . . 11 64 3.2. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 12 65 3.2.1. FFC diffie-hellman using generated MODP groups . . . 13 66 3.2.2. FFC diffie-hellman using named MODP groups . . . . . 13 67 3.3. Integer Factorization Cryptography (IFC) . . . . . . . . 14 68 3.4. KDFs and Integrity Hashing . . . . . . . . . . . . . . . 15 69 3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 16 70 4. Summary Guidance for Key Exchange Method Names 71 Implementations . . . . . . . . . . . . . . . . . . . . . 16 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 8.2. Informative References . . . . . . . . . . . . . . . . . 21 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Overview and Rationale 82 Secure Shell (SSH) is a common protocol for secure communication on 83 the Internet. In [RFC4253], SSH originally defined two Key Exchange 84 (KEX) Method Names that MUST be implemented. Over time what was once 85 considered secure is no longer considered secure. The purpose of 86 this RFC is to recommend that some published key exchanges be 87 deprecated or disallowed as well as recommending some that SHOULD and 88 one that MUST be adopted. 90 This document updates [RFC4250] [RFC4253] [RFC4432] [RFC4462] by 91 changing the requirement level ("MUST" moving to "SHOULD" or "MAY" or 92 "SHOULD NOT", and "MAY" moving to "MUST" or "SHOULD" or "SHOULD NOT" 93 or "MUST NOT") of various key exchange mechanisms. Some 94 recommendations will be unchanged, but are included for completeness. 96 [RFC4253] section 7.2 says the following: 98 "The key exchange produces two values: a shared secret K, and an 99 exchange hash H. Encryption and authentication keys are derived from 100 these. The exchange hash H from the first key exchange is 101 additionally used as the session identifier, which is a unique 102 identifier for this connection. It is used by authentication methods 103 as a part of the data that is signed as a proof of possession of a 104 private key. Once computed, the session identifier is not changed, 105 even if keys are later re-exchanged." 107 The security strength of the public key exchange algorithm and the 108 hash used in the Key Derivation Function (KDF) both impact the 109 security of the shared secret K being used. 111 The hashing algorithms used by key exchange methods described in this 112 document are: sha1, sha256, sha384, and sha512. In many cases, the 113 hash name is explicitly appended to the public key exchange algorithm 114 name. However, some of them are implicit and defined in the RFC that 115 defines the key exchange algorithm name. 117 Various RFCs use different spellings and capitalizations for the 118 hashing function and encryption function names. For the purpose of 119 this document, the following are equivalent names: sha1, SHA1, and 120 SHA-1; sha256, SHA256, and SHA2-256; sha384, SHA384, and SHA2-384; 121 sha512, SHA512, and SHA2-512. 123 For the purpose of this document, the following are equivalent: 124 aes128, AES128, AES-128; aes192, AES192, and AES-192; aes256, AES256, 125 and AES-256. 127 It is good to try to match the security strength of the public key 128 exchange algorithm with security strength of the symmetric cipher. 130 There are many possible symmetric ciphers available, with multiple 131 modes. The list in Table 1 is intended as a representative sample of 132 those which appear to be present in most SSH implementations. The 133 security strength estimates are generally available in [RFC4086] for 134 triple-DES and AES as well as [NIST.SP.800-57pt1r5] Section 5.6.1.1. 136 +========================+=============================+ 137 | Cipher Name (modes) | Estimated Security Strength | 138 +========================+=============================+ 139 | 3des (cbc) | 112 bits | 140 +------------------------+-----------------------------+ 141 | aes128 (cbc, ctr, gcm) | 128 bits | 142 +------------------------+-----------------------------+ 143 | aes192 (cbc, ctr, gcm) | 192 bits | 144 +------------------------+-----------------------------+ 145 | aes256 (cbc, ctr, gcm) | 256 bits | 146 +------------------------+-----------------------------+ 148 Table 1: Symmetric Cipher Security Strengths 150 The following subsections describe how to select each component of 151 the key exchange. 153 1.1. Selecting an appropriate hashing algorithm 155 The SHA-1 hash is in the process of being deprecated for many 156 reasons. 158 There have been attacks against SHA-1 and it is no longer strong 159 enough for SSH security requirements. Therefore, it is desirable to 160 move away from using it before attacks become more serious. 162 The SHA-1 hash provides for approximately 80 bits of security 163 strength. This means that the shared key being used has at most 80 164 bits of security strength which may not be sufficient for most users. 166 For purposes of key exchange methods, attacks against SHA-1 are 167 collision attacks that usually rely on human help, rather than a pre- 168 image attack. SHA-1 resistance against second pre-image is still at 169 160 bits, but SSH does not depend on second pre-image resistance, but 170 rather on chosen-prefix collision resistance. 172 Transcript Collision attacks are documented in [TRANS-COLL]. This 173 paper shows that an on-path attacker does not tamper with the Diffie- 174 Hellman values and does not know the connection keys. The attack 175 could be used to tamper with both I_C and I_S (as defined in section 176 7.3 of [RFC4253]), and might potentially be able to downgrade the 177 negotiated ciphersuite to a weak cryptographic algorithm that the 178 attacker knows how to break. 180 These attacks are still computationally very difficult to perform, 181 but it is desirable that any key exchange using SHA-1 be phased out 182 as soon as possible. 184 If there is a need for using SHA-1 in a key exchange for 185 compatibility, it would be desirable to list it last in the 186 preference list of key exchanges. 188 Use of the SHA-2 family of hashes found in [RFC6234] rather than the 189 SHA-1 hash is strongly advised. 191 When it comes to the SHA-2 family of Secure Hashing functions, 192 SHA2-256 has 128 bits of security strength; SHA2-384 has 192 bits of 193 security strength; and SHA2-512 has 256 bits of security strength. 194 It is suggested that the minimum secure hashing function that should 195 be used for key exchange methods is SHA2-256 with 128 bits of 196 security strength. Other hashing functions may also have the same 197 number of bits of security strength, but none are as yet defined in 198 any RFC for use in a KEX for SSH. 200 To avoid combinatorial explosion of key exchange names, newer key 201 exchanges are generally restricted to *-sha256 and *-sha512. The 202 exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-* which are 203 defined to use SHA2-384 for the hash algorithm. 205 Table 2 provides a summary of security strength for hashing functions 206 for collision resistance. You may consult [NIST.SP.800-107r1] for 207 more information on hash algorithm security strength. 209 +===========+=============================+ 210 | Hash Name | Estimated Security Strength | 211 +===========+=============================+ 212 | sha1 | 80 bits (before attacks) | 213 +-----------+-----------------------------+ 214 | sha256 | 128 bits | 215 +-----------+-----------------------------+ 216 | sha384 | 192 bits | 217 +-----------+-----------------------------+ 218 | sha512 | 256 bits | 219 +-----------+-----------------------------+ 221 Table 2: Hashing Function Security 222 Strengths 224 1.2. Selecting an appropriate Public key Algorithm 226 SSH uses mathematically hard problems for doing key exchanges: 228 * Elliptic Curve Cryptography (ECC) has families of curves for key 229 exchange methods for SSH. NIST prime curves with names and other 230 curves are available using an object identifier (OID) with 231 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 232 and Curve448 key exchanges are used with ECDH via [RFC8731]. 234 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) 235 key exchange with "safe primes" either from a specified list found 236 in [RFC3526] or generated dynamically via [RFC4419] as updated by 237 [RFC8270]. 239 * Integer Factorization Cryptography (IFC) using the RSA algorithm 240 is provided for in [RFC4432]. 242 It is desirable that the security strength of the key exchange be 243 chosen to be comparable with the security strength of the other 244 elements of the SSH handshake. Attackers can target the weakest 245 element of the SSH handshake. 247 It is desirable to select a minimum of 112 bits of security strength 248 to match the weakest of the symmetric cipher (3des-cbc) available. 249 Based on implementer security needs, a stronger minimum may be 250 desired. 252 The larger the MODP group, the ECC curve size, or the RSA key length, 253 the more computation power will be required to perform the key 254 exchange. 256 1.2.1. Elliptic Curve Cryptography (ECC) 258 For ECC, across all of the named curves the minimum security strength 259 is approximately 128 bits. The [RFC5656] key exchanges for the named 260 curves use a hashing function with a matching security strength. 261 Likewise, the [RFC8731] key exchanges use a hashing function which 262 has more security strength than the curves. The minimum strength 263 will be the security strength of the curve. Table 3 contains a 264 breakdown of just the ECC security strength by curve name and not 265 including the hashing algorithm used. The curve* security level 266 numbers are in [RFC7748]. The nist* numbers are in [RFC5656]. The 267 hashing algorithm designated for use with the individual curves have 268 approximately the same number of bits of security as the named curve. 270 +============+=============================+ 271 | Curve Name | Estimated Security Strength | 272 +============+=============================+ 273 | nistp256 | 128 bits | 274 +------------+-----------------------------+ 275 | nistp384 | 192 bits | 276 +------------+-----------------------------+ 277 | nistp521 | 512 bits | 278 +------------+-----------------------------+ 279 | Curve25519 | 128 bits | 280 +------------+-----------------------------+ 281 | Curve448 | 224 bits | 282 +------------+-----------------------------+ 284 Table 3: ECC Security Strengths 286 1.2.2. Finite Field Cryptography (FFC) 288 For FFC, it is recommended to use a modulus with a minimum of 2048 289 bits (approximately 112 bits of security strength) with a hash that 290 has at least as many bits of security as the FFC. The security 291 strength of the FFC and the hash together will be the minimum of 292 those two values. This is sufficient to provide a consistent 293 security strength for the 3des-cbc cipher. [RFC3526] section 1 notes 294 that the Advanced Encryption Standard (AES) cipher, which has more 295 strength, needs stronger groups. For the 128-bit AES we need about a 296 3200-bit group. The 192 and 256-bit keys would need groups that are 297 about 8000 and 15400 bits respectively. Table 4 provides the 298 security strength of the MODP group. When paired with a hashing 299 algorithm, the security strength will be the minimum of the two 300 algorithms. 302 +==================+=============================+============+ 303 | Prime Field Size | Estimated Security Strength | Example | 304 | | | MODP Group | 305 +==================+=============================+============+ 306 | 2048-bit | 112 bits | group14 | 307 +------------------+-----------------------------+------------+ 308 | 3072-bit | 128 bits | group15 | 309 +------------------+-----------------------------+------------+ 310 | 4096-bit | 152 bits | group16 | 311 +------------------+-----------------------------+------------+ 312 | 6144-bit | 176 bits | group17 | 313 +------------------+-----------------------------+------------+ 314 | 8192-bit | 200 bits | group18 | 315 +------------------+-----------------------------+------------+ 317 Table 4: FFC MODP Security Strengths 319 The minimum MODP group is the 2048-bit MODP group14. When used with 320 sha1, this group provides approximately 80 bits of security. When 321 used with sha256, this group provides approximately 112 bits of 322 security. The 3des-cbc cipher itself provides at most 112 bits of 323 security, so the group14-sha256 key exchanges is sufficient to keep 324 all of the 3des-cbc key, for 112 bits of security. 326 A 3072-bit MODP group with sha256 hash will provide approximately 128 327 bits of security. This is desirable when using a cipher such as 328 aes128 or chacha20-poly1305 that provides approximately 128 bits of 329 security. 331 The 8192-bit group18 MODP group when used with sha512 provides 332 approximately 200 bits of security which is sufficient to protect 333 aes192 with 192 bits of security. 335 1.2.3. Integer Factorization Cryptography (IFC) 337 The only IFC algorithm for key exchange is the RSA algorithm 338 specified in [RFC4432]. RSA 1024-bit keys have approximately 80 bits 339 of security strength. RSA 2048-bit keys have approximately 112 bits 340 of security strength. It is worth noting that the IFC types of key 341 exchange do not provide Forward Secrecy which both FFC and ECC do 342 provide. 344 In order to match the 112 bits of security strength needed for 3des- 345 cbc, an RSA 2048-bit key matches the security strength. The use of a 346 SHA-2 Family hash with RSA 2048-bit keys has sufficient security to 347 match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange 348 has approximately 80 bits of security strength and is not desirable. 350 Table 5 summarizes the security strengths of these key exchanges 351 without including the hashing algorithm strength. Guidance for these 352 strengths are in [NIST.SP.800-57pt1r5] Section 5.6.1.1. 354 +=====================+=============================+ 355 | Key Exchange Method | Estimated Security Strength | 356 +=====================+=============================+ 357 | rsa1024-sha1 | 80 bits | 358 +---------------------+-----------------------------+ 359 | rsa2048-sha256 | 112 bits | 360 +---------------------+-----------------------------+ 362 Table 5: IFC Security Strengths 364 2. Requirements Language 366 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 367 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 368 "OPTIONAL" in this document are to be interpreted as described in 369 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 370 capitals, as shown here. 372 3. Key Exchange Methods 374 This document adopts the style and conventions of [RFC4253] in 375 specifying how the use of data key exchange is indicated in SSH. 377 This RFC also collects key exchange method names in various existing 378 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 379 [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a 380 suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD 381 NOT, and MUST NOT. Any method not explicitly listed MAY be 382 implemented. 384 [RFC4253] section 7.2 "Output of Key Exchange" defines generation of 385 a shared secret K (really the output of the KDF) and an exchange key 386 hash H. Each key exchange method uses a specified HASH function 387 which must be the same for both key exchange and Key Derivation. H 388 is used for key exchange integrity across the SSH session as it is 389 computed only once. It is noted at the end of the 7.2 section that 390 "This process will lose entropy if the amount of entropy in K is 391 larger than the internal state size of HASH." so care must be taken 392 that the hashing algorithm used is well chosen ("reasonable") for the 393 key exchange algorithms being used. 395 This document is intended to provide guidance as to what key exchange 396 algorithms are to be considered for new or updated SSH 397 implementations. 399 In general, key exchange methods which are considered 'weak' are 400 being moved to either deprecated ("SHOULD NOT"), or disallowed ("MUST 401 NOT"). Methods which are newer or considered to be stronger usually 402 require more device resources than many administrators and/or 403 developers need are to be allowed ("MAY"). (Eventually, some of 404 these methods could be moved by consensus to "SHOULD" to increase 405 interoperability and security.) Methods which are not 'weak' and 406 have implementation consensus are encouraged ("SHOULD"). There needs 407 to be at least one consensus method promoted to a mandatory to 408 implement (MTI). This should help to provide continued 409 interoperability even with the loss of one of the now disallowed MTI 410 methods. 412 For this document, 112 bits of security strength is the minimum. Use 413 of either or both of SHA-1 and RSA 1024-bits at an approximate 80 414 bits of security fall below this minimum and should be deprecated and 415 moved to disallowed as quickly as possible in configured deployments 416 of SSH. It seems plausible that this minimum may be increased over 417 time, so authors and administrators may wish to prepare for a switch 418 to algorithms that provide more security strength. 420 3.1. Elliptic Curve Cryptography (ECC) 422 The EC key exchange algorithms used with SSH include the ECDH and EC 423 Menezes-Qu-Vanstone (ecmqv). 425 The ECC curves defined for the key exchange algorithms above include; 426 curve25519, curve448, the NIST prime curves (nistp256, nistp384, 427 nistp521) as well as other curves allowed for by [RFC5656] section 6. 428 There are GSSAPI-based key-exchange mechanisms that use these curves 429 as well which have a 'gss-' prefix. 431 3.1.1. curve25519-sha256 and gss-curve25519-sha256-* 433 Curve25519 is efficient on a wide range of architectures with 434 properties that allow higher performance implementations compared to 435 the patented elliptic curve parameters purchased by NIST for the 436 general public to use and described in [RFC5656]. The corresponding 437 key exchange methods use SHA2-256 (also known as SHA-256) defined in 438 [RFC6234]. SHA2-256 is a reasonable hash for use in both the KDF and 439 session integrity. It is reasonable for both gss and non-gss uses of 440 curve25519 key exchange methods. These key exchange methods are 441 described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key 442 agreement described in [RFC8031]. The curve25519-sha256 key exchange 443 method has multiple implementations and SHOULD be implemented. The 444 gss-curve25519-sha256-* key exchange method SHOULD also be 445 implemented because it shares the same performance and security 446 characteristics as curve25519-sha256. 448 Table 6 contains a summary of the recommendations for curve25519 449 based key exchanges. 451 +==========================+==========+ 452 | Key Exchange Method Name | Guidance | 453 +==========================+==========+ 454 | curve25519-sha256 | SHOULD | 455 +--------------------------+----------+ 456 | gss-curve25519-sha256-* | SHOULD | 457 +--------------------------+----------+ 459 Table 6: Curve25519 Implementation 460 Guidance 462 3.1.2. curve448-sha512 and gss-curve448-sha512-* 464 Curve448 provides more security strength than Curve25519 at a higher 465 computational and bandwidth cost. The corresponding key exchange 466 methods use SHA2-512 (also known as SHA-512) defined in [RFC6234]. 467 SHA2-512 is a reasonable hash for use in both the KDF and session 468 integrity. It is reasonable for both gss and non-gss uses of 469 curve448 key exchange methods. These key exchange methods are 470 described in [RFC8731] and [RFC8732] and are similar to the IKEv2 key 471 agreement described in [RFC8031]. The curve448-sha512 key exchange 472 method MAY be implemented. The gss-curve448-sha512-* key exchange 473 method MAY also be implemented because it shares the same performance 474 and security characteristics as curve448-sha512. 476 Table 7 contains a summary of the recommendations for curve448 based 477 key exchanges. 479 +==========================+==========+ 480 | Key Exchange Method Name | Guidance | 481 +==========================+==========+ 482 | curve448-sha512 | MAY | 483 +--------------------------+----------+ 484 | gss-curve448-sha512-* | MAY | 485 +--------------------------+----------+ 487 Table 7: Curve448 Implementation 488 Guidance 490 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* 492 The ecdh-sha2-* name-space allows for both the named NIST prime 493 curves (nistp256, nistp384, nistp521) as well as other curves to be 494 defined for the Elliptic-curve Diffie-Hellman key exchange. At the 495 time of this writing, there are three named curves in this name-space 496 which SHOULD be supported. They appear in [RFC5656] in section 10.1 497 ("Required Curves"). If implemented, the named curves SHOULD always 498 be enabled unless specifically disabled by local security policy. In 500 [RFC5656], section 6.1, the method to name other ECDH curves using 501 OIDs is specified. These other curves MAY be implemented. 503 The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms 504 used by ecdh-sha2-* names. They are described in [RFC8732]. 506 ECDH reduces bandwidth of key exchanges compared to FFC DH at a 507 similar security strength. 509 Table 8 lists algorithms as SHOULD where implementations may be more 510 efficient or widely deployed. The items listed as MAY in Table 8 are 511 potentially less efficient. 513 +==========================+==========+ 514 | Key Exchange Method Name | Guidance | 515 +==========================+==========+ 516 | ecdh-sha2-* | MAY | 517 +--------------------------+----------+ 518 | ecdh-sha2-nistp256 | SHOULD | 519 +--------------------------+----------+ 520 | gss-nistp256-sha256-* | SHOULD | 521 +--------------------------+----------+ 522 | ecdh-sha2-nistp384 | SHOULD | 523 +--------------------------+----------+ 524 | gss-nistp384-sha384-* | SHOULD | 525 +--------------------------+----------+ 526 | ecdh-sha2-nistp521 | SHOULD | 527 +--------------------------+----------+ 528 | gss-nistp521-sha512-* | SHOULD | 529 +--------------------------+----------+ 530 | ecmqv-sha2 | MAY | 531 +--------------------------+----------+ 533 Table 8: ECDH Implementation Guidance 535 It is advisable to match the ECDSA and ECDH algorithms to use the 536 same curve for both to maintain the same security strength in the 537 connection. 539 3.2. Finite Field Cryptography (FFC) 540 3.2.1. FFC diffie-hellman using generated MODP groups 542 [RFC4419] defines two key exchange methods that use a random 543 selection from a set of pre-generated moduli for key exchange: the 544 diffie-hellman-group-exchange-sha1 method, and the diffie-hellman- 545 group-exchange-sha256 method. Per [RFC8270], implementations SHOULD 546 use a MODP group whose modulus size is equal to or greater than 2048 547 bits. MODP groups with a modulus size less than 2048 bits are weak 548 and MUST NOT be used. 550 The diffie-hellman-group-exchange-sha1 key exchange method SHOULD NOT 551 be used. This method uses SHA-1, which is being deprecated. 553 The diffie-hellman-group-exchange-sha256 key exchange method MAY be 554 used. This method uses SHA-256, which is reasonable for MODP groups 555 less than 4000 bits. 557 Care should be taken in the pre-generation of the moduli P and 558 generator G such that the generator provides a Q-ordered subgroup of 559 P. Otherwise, the parameter set may leak one bit of the shared 560 secret. 562 Table 9 provides a summary of the Guidance for these exchanges. 564 +======================================+============+ 565 | Key Exchange Method Name | Guidance | 566 +======================================+============+ 567 | diffie-hellman-group-exchange-sha1 | SHOULD NOT | 568 +--------------------------------------+------------+ 569 | diffie-hellman-group-exchange-sha256 | MAY | 570 +--------------------------------------+------------+ 572 Table 9: FFC Generated MODP Group Implementation 573 Guidance 575 3.2.2. FFC diffie-hellman using named MODP groups 577 The diffie-hellman-group14-sha256 key exchange method is defined in 578 [RFC8268] and represents a key exchange which has approximately 112 579 bits of security strength that matches 3des-cbc symmetric cipher 580 security strength. It is a reasonably simple transition from SHA-1 581 to SHA-2 and given that diffie-hellman-group14-sha1 and diffie- 582 hellman-group14-sha256 share a MODP group and only differ in the hash 583 function used for the KDF and integrity, it is a correspondingly 584 simple transition from implementing diffie-hellman-group14-sha1 to 585 implementing diffie-hellman-group14-sha256. Given that diffie- 586 hellman-group14-sha1 is being removed from mandatory to implement 587 (MTI) status, the diffie-hellman-group14-sha256 method MUST be 588 implemented. The rest of the FFC MODP group from [RFC8268] have a 589 larger number of security bits and are suitable for symmetric ciphers 590 that also have a similar number of security bits. 592 Table 10 below provides explicit guidance by name. 594 +===============================+==========+ 595 | Key Exchange Method Name | Guidance | 596 +===============================+==========+ 597 | diffie-hellman-group14-sha256 | MUST | 598 +-------------------------------+----------+ 599 | gss-group14-sha256-* | SHOULD | 600 +-------------------------------+----------+ 601 | diffie-hellman-group15-sha512 | MAY | 602 +-------------------------------+----------+ 603 | gss-group15-sha512-* | MAY | 604 +-------------------------------+----------+ 605 | diffie-hellman-group16-sha512 | SHOULD | 606 +-------------------------------+----------+ 607 | gss-group16-sha512-* | MAY | 608 +-------------------------------+----------+ 609 | diffie-hellman-group17-sha512 | MAY | 610 +-------------------------------+----------+ 611 | gss-group17-sha512-* | MAY | 612 +-------------------------------+----------+ 613 | diffie-hellman-group18-sha512 | MAY | 614 +-------------------------------+----------+ 615 | gss-group18-sha512-* | MAY | 616 +-------------------------------+----------+ 618 Table 10: FFC Named Group Implementation 619 Guidance 621 3.3. Integer Factorization Cryptography (IFC) 623 The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses 624 an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does 625 NOT meet security requirements. This method MUST NOT be implemented. 627 The rsa2048-sha256 key exchange method is defined in [RFC4432] and 628 uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange 629 meets 112 bit minimum security strength. This method MAY be 630 implemented. 632 Table 11 provide a summary of the guidance for IFC key exchanges. 634 +==========================+==========+ 635 | Key Exchange Method Name | Guidance | 636 +==========================+==========+ 637 | rsa1024-sha1 | MUST NOT | 638 +--------------------------+----------+ 639 | rsa2048-sha256 | MAY | 640 +--------------------------+----------+ 642 Table 11: IFC Implementation Guidance 644 3.4. KDFs and Integrity Hashing 646 The SHA-1 and SHA-2 family of hashing algorithms are combined with 647 the FFC, ECC, and IFC algorithms to comprise a key exchange method 648 name. 650 The selected hash algorithm is used both in the KDF as well as for 651 the integrity of the response. 653 All of the key exchange methods using the SHA-1 hashing algorithm 654 should be deprecated and phased out due to security concerns for SHA- 655 1, as documented in [RFC6194]. 657 Unconditionally deprecating and/or disallowing SHA-1 everywhere will 658 hasten the day when it may be simply removed from implementations 659 completely. Leaving partially-broken algorithms lying around is not 660 a good thing to do. 662 The SHA-2 Family of hashes [RFC6234] is more secure than SHA-1. They 663 have been standardized for use in SSH with many of the currently 664 defined key exchanges. 666 Please note that at the present time, there is no key exchange method 667 for Secure Shell which uses the SHA-3 family of Secure Hashing 668 functions or the Extendable Output Functions. 670 Prior to the changes made by this document, diffie-hellman- 671 group1-sha1 and diffie-hellman-group14-sha1 were MTI. diffie- 672 hellman-group14-sha1 is the stronger of the two. Group14 (a 2048-bit 673 MODP group) is defined in [RFC3526]. The group1 MODP group with 674 approximately 80 bits of security is too weak to be retained. 675 However, rather than jumping from the MTI to making it disallowed, 676 many implementers suggested that it should transition to deprecated 677 first and be disallowed at a later time. The group14 MODP group 678 using a sha1 hash for the KDF is not as weak as the group1 MODP 679 group. There are some legacy situations where it will still provide 680 administrators with value, such as small hardware IOT devices which 681 have insufficient compute and memory resources to use larger MODP 682 groups before a timeout of the session occurs. Transitioning from 683 MTI to a requirement status that provides for continued use with the 684 expectation of deprecating or disallowing it in the future was able 685 to find consensus. Therefore, it is considered reasonable to retain 686 the diffie-hellman-group14-sha1 exchange for interoperability with 687 legacy implementations. The diffie-hellman-group14-sha1 key exchange 688 MAY be implemented, but should be put at the end of the list of 689 negotiated key exchanges. 691 The diffie-hellman-group1-sha1 and diffie-hellman-group-exchange-sha1 692 SHOULD NOT be implemented. The gss-group1-sha1-*, gss- 693 group14-sha1-*, and gss-gex-sha1-* key exchanges are already 694 specified as SHOULD NOT be implemented by [RFC8732]. 696 3.5. Secure Shell Extension Negotiation 698 There are two methods, ext-info-c and ext-info-s, defined in 699 [RFC8308]. They provide a mechanism to support other Secure Shell 700 negotiations. Being able to extend functionality is desirable. Both 701 ext-info-c and ext-info-s SHOULD be implemented. 703 4. Summary Guidance for Key Exchange Method Names Implementations 705 The Implement column is the current recommendations of this RFC. 706 Table 12 provides the existing key exchange method names listed 707 alphabetically. 709 +==========================+===========+================+===========+ 710 | Key Exchange Method | Reference | Previous | RFCxxxxx | 711 | Name | | Recommendation | Implement | 712 +==========================+===========+================+===========+ 713 | curve25519-sha256 | RFC8731 | none | SHOULD | 714 +--------------------------+-----------+----------------+-----------+ 715 | curve448-sha512 | RFC8731 | none | MAY | 716 +--------------------------+-----------+----------------+-----------+ 717 | diffie-hellman-group- | RFC4419 | none | SHOULD | 718 | exchange-sha1 | RFC8270 | | NOT | 719 +--------------------------+-----------+----------------+-----------+ 720 | diffie-hellman-group- | RFC4419 | none | MAY | 721 | exchange-sha256 | RFC8720 | | | 722 +--------------------------+-----------+----------------+-----------+ 723 | diffie-hellman- | RFC4253 | MUST | SHOULD | 724 | group1-sha1 | | | NOT | 725 +--------------------------+-----------+----------------+-----------+ 726 | diffie-hellman- | RFC4253 | MUST | MAY | 727 | group14-sha1 | | | | 728 +--------------------------+-----------+----------------+-----------+ 729 | diffie-hellman- | RFC8268 | none | MUST | 730 | group14-sha256 | | | | 731 +--------------------------+-----------+----------------+-----------+ 732 | diffie-hellman- | RFC8268 | none | MAY | 733 | group15-sha512 | | | | 734 +--------------------------+-----------+----------------+-----------+ 735 | diffie-hellman- | RFC8268 | none | SHOULD | 736 | group16-sha512 | | | | 737 +--------------------------+-----------+----------------+-----------+ 738 | diffie-hellman- | RFC8268 | none | MAY | 739 | group17-sha512 | | | | 740 +--------------------------+-----------+----------------+-----------+ 741 | diffie-hellman- | RFC8268 | none | MAY | 742 | group18-sha512 | | | | 743 +--------------------------+-----------+----------------+-----------+ 744 | ecdh-sha2-* | RFC5656 | MAY | MAY | 745 +--------------------------+-----------+----------------+-----------+ 746 | ecdh-sha2-nistp256 | RFC5656 | MUST | SHOULD | 747 +--------------------------+-----------+----------------+-----------+ 748 | ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD | 749 +--------------------------+-----------+----------------+-----------+ 750 | ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD | 751 +--------------------------+-----------+----------------+-----------+ 752 | ecmqv-sha2 | RFC5656 | MAY | MAY | 753 +--------------------------+-----------+----------------+-----------+ 754 | ext-info-c | RFC8308 | SHOULD | SHOULD | 755 +--------------------------+-----------+----------------+-----------+ 756 | ext-info-s | RFC8308 | SHOULD | SHOULD | 757 +--------------------------+-----------+----------------+-----------+ 758 | gss- | RFC4462 | reserved | reserved | 759 +--------------------------+-----------+----------------+-----------+ 760 | gss- | RFC8732 | SHOULD | SHOULD | 761 | curve25519-sha256-* | | | | 762 +--------------------------+-----------+----------------+-----------+ 763 | gss-curve448-sha512-* | RFC8732 | MAY | MAY | 764 +--------------------------+-----------+----------------+-----------+ 765 | gss-gex-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | 766 | | RFC8732 | | NOT | 767 +--------------------------+-----------+----------------+-----------+ 768 | gss-group1-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | 769 | | RFC8732 | | NOT | 770 +--------------------------+-----------+----------------+-----------+ 771 | gss-group14-sha1-* | RFC4462/ | SHOULD NOT | SHOULD | 772 | | RFC8732 | | NOT | 773 +--------------------------+-----------+----------------+-----------+ 774 | gss-group14-sha256-* | RFC8732 | SHOULD | SHOULD | 775 +--------------------------+-----------+----------------+-----------+ 776 | gss-group15-sha512-* | RFC8732 | MAY | MAY | 777 +--------------------------+-----------+----------------+-----------+ 778 | gss-group16-sha512-* | RFC8732 | SHOULD | MAY | 779 +--------------------------+-----------+----------------+-----------+ 780 | gss-group17-sha512-* | RFC8732 | MAY | MAY | 781 +--------------------------+-----------+----------------+-----------+ 782 | gss-group18-sha512-* | RFC8732 | MAY | MAY | 783 +--------------------------+-----------+----------------+-----------+ 784 | gss-nistp256-sha256-* | RFC8732 | SHOULD | SHOULD | 785 +--------------------------+-----------+----------------+-----------+ 786 | gss-nistp384-sha384-* | RFC8732 | MAY | SHOULD | 787 +--------------------------+-----------+----------------+-----------+ 788 | gss-nistp521-sha512-* | RFC8732 | MAY | SHOULD | 789 +--------------------------+-----------+----------------+-----------+ 790 | rsa1024-sha1 | RFC4432 | MAY | MUST NOT | 791 +--------------------------+-----------+----------------+-----------+ 792 | rsa2048-sha256 | RFC4432 | MAY | MAY | 793 +--------------------------+-----------+----------------+-----------+ 795 Table 12: IANA guidance for key exchange method name implementations 797 The full set of official [IANA-KEX] key algorithm method names not 798 otherwise mentioned in this document MAY be implemented. 800 [TO BE REMOVED: This registration should take place at the following 801 location URL: https://www.iana.org/assignments/ssh-parameters/ssh- 802 parameters.xhtml#ssh-parameters-16 It is hoped that the Table 12 in 803 section 4 of this draft provide guidance information to be merged 804 into the IANA ssh-parameters-16 table. Future RFCs may update the 805 these Implementation Guidance notations. ] 807 5. Acknowledgements 809 Thanks to the following people for review and comments: Denis Bider, 810 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 811 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 812 Tero Kivinen, and Travis Finkenauer. 814 Thanks to the following people for code to implement interoperable 815 exchanges using some of these groups as found in this draft: Darren 816 Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks to 817 Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) and 818 Poderosa implementations also adopting new Diffie-Hellman groups 819 based on this draft. 821 6. Security Considerations 823 This SSH protocol provides a secure encrypted channel over an 824 insecure network. It performs server host authentication, key 825 exchange, encryption, and integrity checks. It also derives a unique 826 session ID that may be used by higher-level protocols. The key 827 exchange itself generates a shared secret and uses the hash function 828 for both the KDF and integrity. 830 Full security considerations for this protocol are provided in 831 [RFC4251] continue to apply. In addition, the security 832 considerations provided in [RFC4432] apply. Note that Forward 833 Secrecy is NOT available with the rsa1024-sha1 or rsa2048-sha256 key 834 exchanges. 836 It is desirable to deprecate or disallow key exchange methods that 837 are considered weak, so they are not in still actively in operation 838 when they are broken. 840 A key exchange method is considered weak when the security strength 841 is insufficient to match the symmetric cipher or the algorithm has 842 been broken. 844 The 1024-bit MODP group used by diffie-hellman-group1-sha1 is too 845 small for the symmetric ciphers used in SSH. 847 MODP groups with a modulus size less than 2048 bits are too small for 848 the symmetric ciphers used in SSH. If the diffie-hellman-group- 849 exchange-sha256 or diffie-hellman-group-exchange-sha1 key exchange 850 method is used, the modulus size of the MODP group used needs to be 851 at least 2048 bits. 853 At this time, the rsa1024-sha1 key exchange is too small for the 854 symmetric ciphers used in SSH. 856 The use of SHA-1 for use with any key exchange may not yet be 857 completely broken, but it is time to retire all uses of this 858 algorithm as soon as possible. 860 The diffie-hellman-group14-sha1 algorithm is not yet completely 861 deprecated. This is to provide a practical transition from the MTI 862 algorithms to a new one. However, it would be best to only be as a 863 last resort in key exchange negotiations. All key exchange methods 864 using the SHA-1 hash are to be considered as deprecated. 866 7. IANA Considerations 868 IANA is requested to add a new column to [IANA-KEX] with heading "OK 869 to Implement", and to annotate entries therein with the 870 implementation guidance provided in section 4 "Summary Guidance for 871 Key Exchange Method Names Implementation" in this document. A 872 summary may be found in Table 12 in section 4. IANA is additionally 873 requested to include this document as an additional reference for the 874 with the suggested implementation guidance provided in section 4 875 "Summary Guidance for Key Exchange Method Names Implementation" in 876 this document. [IANA-KEX] registry. Registry entries annotated with 877 "MUST NOT" are considered disallowed. Registry entries annotated 878 with "SHOULD NOT" are deprecated and may be disallowed in the future. 880 8. References 882 8.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 890 Protocol Assigned Numbers", RFC 4250, 891 DOI 10.17487/RFC4250, January 2006, 892 . 894 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 895 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 896 January 2006, . 898 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 899 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 900 May 2017, . 902 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 903 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 904 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 905 . 907 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 908 Minimum Recommended Diffie-Hellman Modulus Size to 2048 909 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 910 . 912 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 913 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 914 2018, . 916 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 917 Shell (SSH) Key Exchange Method Using Curve25519 and 918 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 919 . 921 8.2. Informative References 923 [IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key 924 Exchange Method Names", July 2021, 925 . 928 [NIST.SP.800-107r1] 929 Dang, Q., "Recommendation for applications using approved 930 hash algorithms", DOI 10.6028/NIST.SP.800-107r1, August 931 2012, . 933 [NIST.SP.800-57pt1r5] 934 Barker, E., "Recommendation for Key Management - Part 1 - 935 General", DOI 10.6028/NIST.SP.800-57pt1r5, May 2020, 936 . 938 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 939 Diffie-Hellman groups for Internet Key Exchange (IKE)", 940 RFC 3526, DOI 10.17487/RFC3526, May 2003, 941 . 943 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 944 "Randomness Requirements for Security", BCP 106, RFC 4086, 945 DOI 10.17487/RFC4086, June 2005, 946 . 948 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 949 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 950 January 2006, . 952 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 953 Group Exchange for the Secure Shell (SSH) Transport Layer 954 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 955 . 957 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 958 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 959 March 2006, . 961 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 962 "Generic Security Service Application Program Interface 963 (GSS-API) Authentication and Key Exchange for the Secure 964 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 965 2006, . 967 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 968 Integration in the Secure Shell Transport Layer", 969 RFC 5656, DOI 10.17487/RFC5656, December 2009, 970 . 972 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 973 Considerations for the SHA-0 and SHA-1 Message-Digest 974 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 975 . 977 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 978 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 979 DOI 10.17487/RFC6234, May 2011, 980 . 982 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 983 for Security", RFC 7748, DOI 10.17487/RFC7748, January 984 2016, . 986 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 987 Internet Key Exchange Protocol Version 2 (IKEv2) Key 988 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 989 . 991 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 992 Application Program Interface (GSS-API) Key Exchange with 993 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 994 . 996 [TRANS-COLL] 997 Bhargavan, K. and G. Leurent, "Transcript Collision 998 Attacks: Breaking Authentication in TLS, IKE, and SSH", 999 Network and Distributed System Security Symposium - NDSS 1000 2016, Feb 2016, San Diego, United 1001 States. 10.14722/ndss.2016.23418 . hal-01244855, 1002 . 1004 Author's Address 1006 Mark D. Baushke 1008 Email: mbaushke.ietf@gmail.com