idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-15.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 (17 March 2021) is 1108 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 Juniper Networks, Inc. 4 Updates: 4250 4253 4432 4462 (if approved) 17 March 2021 5 Intended status: Standards Track 6 Expires: 18 September 2021 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-15 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 18 September 2021. 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 . . . . . . . 3 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) . . . . . . . . . . . 6 57 1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 7 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 59 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 8 61 3.1.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 9 62 3.1.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 9 63 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* . . . . . . . . . 10 64 3.2. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 11 65 3.2.1. FFC diffie-hellman using generated MODP groups . . . 11 66 3.2.2. FFC diffie-hellman using named MODP groups . . . . . 12 67 3.3. Integer Factorization Cryptography (IFC) . . . . . . . . 13 68 3.4. KDFs and Integrity Hashing . . . . . . . . . . . . . . . 14 69 3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 15 70 4. Summary Guidance for Key Exchange Method Names 71 Implementations . . . . . . . . . . . . . . . . . . . . . 15 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 8.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 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. 95 [RFC4253] section 7.2 says the following: 97 "The key exchange produces two values: a shared secret K, and an 98 exchange hash H. Encryption and authentication keys are derived from 99 these. The exchange hash H from the first key exchange is 100 additionally used as the session identifier, which is a unique 101 identifier for this connection. It is used by authentication methods 102 as a part of the data that is signed as a proof of possession of a 103 private key. Once computed, the session identifier is not changed, 104 even if keys are later re-exchanged." 106 The security strength of the public key exchange algorithm and the 107 hash used in the Key Derivation Function (KDF) both impact the 108 security of the shared secret K being used. 110 The hashing algorithms used by key exchange methods described in this 111 document are: sha1, sha256, sha384, and sha512. In many cases, the 112 hash name is explicitly appended to the public key exchange algorithm 113 name. However, some of them are implicit and defined in the RFC that 114 defines the key exchange algorithm name. 116 It is good to try to match the security strength of the public key 117 exchange algorithm with security strength of the symmetric cipher. 119 There are many possible symmetric ciphers available, with multiple 120 modes. The list in Table 1 is intended as a representative sample of 121 those which appear to be present in most SSH implementations. 123 +========================+=============================+ 124 | Cipher Name (modes) | Estimated Security Strength | 125 +========================+=============================+ 126 | 3des (cbc) | 112 bits | 127 +------------------------+-----------------------------+ 128 | aes128 (cbc, ctr, gcm) | 128 bits | 129 +------------------------+-----------------------------+ 130 | aes192 (cbc, ctr, gcm) | 192 bits | 131 +------------------------+-----------------------------+ 132 | aes256 (cbc, ctr, gcm) | 256 bits | 133 +------------------------+-----------------------------+ 135 Table 1: Symmetric Cipher Security Strengths 137 The following subsections describe how to select each component of 138 the key exchange. 140 1.1. Selecting an appropriate hashing algorithm 142 The SHA-1 hash is in the process of being deprecated for many 143 reasons. 145 There have been attacks against SHA-1 and it is no longer strong 146 enough for SSH security requirements. Therefore, it is desirable to 147 move away from using it before attacks become more serious. 149 The SHA-1 hash provides for approximately 80 bits of security 150 strength. This means that the shared key being used has at most 80 151 bits of security strength which may not be sufficient for most users. 153 At present, the attacks against SHA-1 are collision attacks that 154 usually rely on human help, rather than a pre-image attack. SHA-1 155 resistance against second pre-image is still at 160 bits, but SSH 156 does not depend on second pre-image resistance, but rather on chosen- 157 prefix collision resistance. 159 Transcript Collision attacks are documented in [TRANS-COLL]. This 160 paper shows that the man in the middle does not tamper with the 161 Diffie-Hellman values and does not know the connection keys. The 162 attack could be used to tamper with both I_C and I_S (as defined in 163 section 7.3 of [RFC4253]), and might potentially be able to downgrade 164 the negotiated ciphersuite to a weak cryptographic algorithm that the 165 attacker knows how to break. 167 These attacks are still computationally very difficult to perform, 168 but is is desirable that any key exchanging using SHA-1 be phased out 169 as soon as possible. 171 If there is a need for using SHA-1 in a key exchange for 172 compatibility, it would be desirable it be listed last in the 173 preference list of key exchanges. 175 Use of the SHA-2 family of hashes found in [RFC6234] rather than the 176 SHA-1 hash is strongly advised. 178 When it comes to the SHA-2 family of Secure Hashing functions, 179 SHA2-256 has 128 bits of security strength; SHA2-384 has 192 bits of 180 security strength; and SHA2-512 has 256 bits of security strength. 181 It is suggested that the minimum secure hashing function that should 182 be used for key exchange methods is SHA2-256. 184 To avoid combinatorial explosion of key exchange names, newer key 185 exchanges are generally restricted to *-sha256 and *-sha512. The 186 exceptions are ecdh-sha2-nistp384 and gss-nistp384-sha384-* which are 187 defined to use SHA2-384 for the hash algorithm. 189 Table 2 provides a summary of security strength for hashing 190 functions. 192 +===========+=============================+ 193 | Hash Name | Estimated Security Strength | 194 +===========+=============================+ 195 | sha1 | 80 bits (before attacks) | 196 +-----------+-----------------------------+ 197 | sha256 | 128 bits | 198 +-----------+-----------------------------+ 199 | sha384 | 192 bits | 200 +-----------+-----------------------------+ 201 | sha512 | 256 bits | 202 +-----------+-----------------------------+ 204 Table 2: Hashing Function Security 205 Strengths 207 1.2. Selecting an appropriate Public key Algorithm 209 SSH uses mathematically hard problems for doing key exchanges: 211 * Elliptic Curve Cryptography (ECC) has families of curves for key 212 exchange methods for SSH. NIST prime curves with names and other 213 curves are available using an object identifier (OID) with 214 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 215 and Curve448 key exchanges are used with ECDH via [RFC8731]. 217 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) 218 key exchange with "safe primes" either from a specified list found 219 in [RFC3526] or generated dynamically via [RFC4419] as updated by 220 [RFC8270]. 222 * Integer Factorization Cryptography (IFC) using the RSA algorithm 223 is provided for in [RFC4432]. 225 It is desirable for the security strength of the key exchange be 226 chosen to be comparable with the security strength of the other 227 elements of the SSH handshake. Attackers can target the weakest 228 element of the SSH handshake. 230 It is desirable to select a minimum of 112 bits of security strength 231 to match the weakest of the symmetric cipher (3des-cbc) available. 232 Based on implementer security needs, a stronger minimum may be 233 desired. 235 The larger the MODP group, the ECC curve size, or the RSA key length, 236 the more computation power will be required to perform the key 237 exchange. 239 1.2.1. Elliptic Curve Cryptography (ECC) 241 For ECC, across all of the named curves the minimum security strength 242 is approximately 128 bits. The [RFC5656] key exchanges for the named 243 curves use a hashing function with a matching security strength. 244 Likewise, the [RFC8731] key exchanges use a hashing function which 245 has more security strength than the curves. The minimum strength 246 will be the security strength of the curve. Table 3 contains a 247 breakdown of just the ECC security strength by curve name and not 248 including the hashing algorithm used. The hashing algorithm defined 249 have approximately the same number of bits of security as the named 250 curve. 252 +============+=============================+ 253 | Curve Name | Estimated Security Strength | 254 +============+=============================+ 255 | nistp256 | 128 bits | 256 +------------+-----------------------------+ 257 | nistp384 | 192 bits | 258 +------------+-----------------------------+ 259 | nistp521 | 512 bits | 260 +------------+-----------------------------+ 261 | Curve25519 | 128 bits | 262 +------------+-----------------------------+ 263 | Curve448 | 224 bits | 264 +------------+-----------------------------+ 266 Table 3: ECC Security Strengths 268 1.2.2. Finite Field Cryptography (FFC) 270 For FFC, it is recommended to use a modulus with a minimum of 2048 271 bits (approximately 112 bits of security strength) with a hash that 272 has at least as many bits of security as the FFC. The security 273 strength of the FFC and the hash together will be the minimum of 274 those two values. This is sufficient to provide a consistent 275 security strength for the 3des-cbc cipher. [RFC3526] section 1 notes 276 that the Advanced Encryption Standard (AES) cipher, which has more 277 strength, needs stronger groups. For the 128-bit AES we need about a 278 3200-bit group. The 192 and 256-bit keys would need groups that are 279 about 8000 and 15400 bits respectively. Table 4 provides the 280 security strength of the MODP group. When paired with a hashing 281 algorithm, the security strength will be the minimum of the two 282 algorithms. 284 +==================+=============================+============+ 285 | Prime Field Size | Estimated Security Strength | Example | 286 | | | MODP Group | 287 +==================+=============================+============+ 288 | 2048-bit | 112 bits | group14 | 289 +------------------+-----------------------------+------------+ 290 | 3072-bit | 128 bits | group15 | 291 +------------------+-----------------------------+------------+ 292 | 4096-bit | 152 bits | group16 | 293 +------------------+-----------------------------+------------+ 294 | 6144-bit | 176 bits | group17 | 295 +------------------+-----------------------------+------------+ 296 | 8192-bit | 200 bits | group18 | 297 +------------------+-----------------------------+------------+ 299 Table 4: FFC MODP Security Strengths 301 The minimum MODP group is the 2048-bit MODP group14. When used with 302 sha1, this group provides approximately 80 bits of security. When 303 used with sha256, this group provides approximately 112 bits of 304 security. The 3des-cbc cipher itself provides at most 112 bits of 305 security, so the group14-sha256 key exchanges is sufficient to keep 306 all of the 3des-cbc key at 112 bits of security. 308 A 3072-bit MODP group with sha256 hash will provide approximately 128 309 bits of security. This is desirable when using a Cipher such as 310 aes128 or chacha20-poly1305 that provides approximately 128 bits of 311 security. 313 The 8192-bit group18 MODP group when used with sha512 provides 314 approximately 200 bits of security which is sufficient to protect 315 aes192 with 192 bits of security. 317 1.2.3. Integer Factorization Cryptography (IFC) 319 The only IFC algorithm for key exchange is the RSA algorithm 320 specified in [RFC4432]. RSA 1024 bit keys have approximately 80 bits 321 of security strength. RSA 2048 bit keys have approximately 112 bits 322 of security strength. It is worth noting that the IFC types of key 323 exchange do not provide Forward Secrecy which both FFC and ECC do 324 provide. 326 In order to match the 112 bits of security strength needed for 3des- 327 cbc, an RSA 2048 bit key matches the security strength. The use of a 328 SHA-2 Family hash with RSA 2048-bit keys has sufficient security to 329 match the 3des-cbc symmetric cipher. The rsa1024-sha1 key exchange 330 has approximately 80 bits of security strength and is not desirable. 332 Table 5 summarizes the security strengths of these key exchanges 333 without including the hashing algorithm strength. 335 +=====================+=============================+ 336 | Key Exchange Method | Estimated Security Strength | 337 +=====================+=============================+ 338 | rsa1024-sha1 | 80 bits | 339 +---------------------+-----------------------------+ 340 | rsa2048-sha256 | 112 bits | 341 +---------------------+-----------------------------+ 343 Table 5: IFC Security Strengths 345 2. Requirements Language 347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 349 "OPTIONAL" in this document are to be interpreted as described in 350 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 351 capitals, as shown here. 353 3. Key Exchange Methods 355 This memo adopts the style and conventions of [RFC4253] in specifying 356 how the use of data key exchange is indicated in SSH. 358 This RFC also collects key exchange method names in various existing 359 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 360 [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a 361 suggested suitability for implementation of MUST, SHOULD, MAY, SHOULD 362 NOT, and MUST NOT. Any method not explicitly listed MAY be 363 implemented. 365 This document is intended to provide guidance as to what key exchange 366 algorithms are to be considered for new or updated SSH 367 implementations. 369 3.1. Elliptic Curve Cryptography (ECC) 371 The EC key exchange algorithms used with SSH include the ECDH and EC 372 Menezes-Qu-Vanstone (ecmqv). 374 The ECC curves defined for the key exchange algorithms above include; 375 curve25519, curve448, the NIST prime curves (nistp256, nistp384, 376 nistp521) as well as other curves allowed for by [RFC5656] section 6. 377 There are GSSAPI forms for these curves as well which have a 'gss-' 378 prefix. 380 3.1.1. curve25519-sha256 and gss-curve25519-sha256-* 382 Curve25519 is efficient on a wide range of architectures with 383 properties that allow higher performance implementations compared to 384 traditional elliptic curves. The use of hash SHA2-256 (also known as 385 SHA-256 and sha256) as defined in [RFC6234] for integrity is a 386 reasonable one for both the KDF and integrity for use with both gss 387 and non-gss uses of curve25519 key exchange methods. These key 388 exchange methods are described in [RFC8731] and [RFC8732] and are 389 similar to the IKEv2 key agreement described in [RFC8031]. The 390 curve25519-sha256 key exchange method has multiple implementations 391 and SHOULD be implemented. The gss-curve25519-sha256-* key exchange 392 method SHOULD also be implemented because it shares the same 393 performance and security characteristics as curve25519-sha256. 395 Table 6 contains a summary of the recommendations for curve25519 396 based key exchanges. 398 +==========================+==========+ 399 | Key Exchange Method Name | Guidance | 400 +==========================+==========+ 401 | curve25519-sha256 | SHOULD | 402 +--------------------------+----------+ 403 | gss-curve25519-sha256-* | SHOULD | 404 +--------------------------+----------+ 406 Table 6: Curve25519 Implementation 407 Guidance 409 3.1.2. curve448-sha512 and gss-curve448-sha512-* 411 Curve448 provides more security strength than Curve25519 at a higher 412 computational and bandwidth cost. The corresponding key exchange 413 methods use SHA2-512 (also known as SHA-512) defined in [RFC6234] for 414 integrity is a reasonable one for both the KDF and integrity for use 415 with both gss and non-gss uses of curve448 key exchange methods. 416 These key exchange methods are described in [RFC8731] and [RFC8732] 417 and are similar to the IKEv2 key agreement described in [RFC8031]. 418 The curve448-sha512 key exchange method MAY be implemented. The gss- 419 curve448-sha512-* key exchange method MAY also be implemented because 420 it shares the same performance and security characteristics as 421 curve448-sha512. 423 Table 7 contains a summary of the recommendations for curve448 based 424 key exchanges. 426 +==========================+==========+ 427 | Key Exchange Method Name | Guidance | 428 +==========================+==========+ 429 | curve448-sha512 | MAY | 430 +--------------------------+----------+ 431 | gss-curve448-sha512-* | MAY | 432 +--------------------------+----------+ 434 Table 7: Curve448 Implementation 435 Guidance 437 3.1.3. ecdh-*, ecmqv-sha2, and gss-nistp* 439 The ecdh-sha2-* name-space allows for both the named NIST prime 440 curves (nistp256, nistp384, nistp521) as well as other curves to be 441 defined for the Elliptic-curve Diffie-Hellman key exchange. At the 442 time of this writing, there are three named curves in this name-space 443 which SHOULD be supported. They appear in [RFC5656] in section 10.1 444 ("Required Curves"). If implemented, the named curves SHOULD always 445 be enabled unless specifically disabled by local security policy. In 446 [RFC5656], section 6.1, the method to name other ECDH curves using 447 OIDs is specified. These other curves MAY be implemented. 449 The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms 450 used by ecdh-sha2-* names. They are described in [RFC8732]. 452 ECDH reduces bandwidth of key exchanges compared to FFC DH at a 453 similar security strength. 455 Table 8 lists algorithms as SHOULD where implementations may be more 456 efficient or widely deployed. The items listed as MAY in Table 8 are 457 potentially less efficient. 459 +==========================+==========+ 460 | Key Exchange Method Name | Guidance | 461 +==========================+==========+ 462 | ecdh-sha2-* | MAY | 463 +--------------------------+----------+ 464 | ecdh-sha2-nistp256 | SHOULD | 465 +--------------------------+----------+ 466 | gss-nistp256-sha256-* | SHOULD | 467 +--------------------------+----------+ 468 | ecdh-sha2-nistp384 | SHOULD | 469 +--------------------------+----------+ 470 | gss-nistp384-sha384-* | SHOULD | 471 +--------------------------+----------+ 472 | ecdh-sha2-nistp521 | SHOULD | 473 +--------------------------+----------+ 474 | gss-nistp521-sha512-* | SHOULD | 475 +--------------------------+----------+ 476 | ecmqv-sha2 | MAY | 477 +--------------------------+----------+ 479 Table 8: ECDH Implementation Guidance 481 It is advisable to match the ECDSA and ECDH algorithms to use the 482 same curve for both to maintain the same security strength in the 483 connection. 485 3.2. Finite Field Cryptography (FFC) 487 3.2.1. FFC diffie-hellman using generated MODP groups 489 This random selection from a set of pre-generated moduli for key 490 exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates 491 that implementations avoid any MODP group whose modulus size is less 492 than 2048 bits. Care should be taken in the pre-generation of the 493 moduli P and generator G such that the generator provides a Q-ordered 494 subgroup of P. Otherwise, the parameter set may leak one bit of the 495 shared secret. The diffie-hellman-group-exchange-sha1 uses SHA-1 496 which is being deprecated. This key exchange SHOULD NOT be used. 497 The diffie-hellman-group-exchange-sha256 uses SHA2-256 which is 498 reasonable for MODP groups less than 4K bits. The diffie-hellman- 499 group-exchange-sha256 key exchange MAY be used. 501 Table 9 provides a summary of the Guidance for these exchanges. 503 +======================================+============+ 504 | Key Exchange Method Name | Guidance | 505 +======================================+============+ 506 | diffie-hellman-group-exchange-sha1 | SHOULD NOT | 507 +--------------------------------------+------------+ 508 | diffie-hellman-group-exchange-sha256 | MAY | 509 +--------------------------------------+------------+ 511 Table 9: FFC Generated MODP Group Implementation 512 Guidance 514 3.2.2. FFC diffie-hellman using named MODP groups 516 The diffie-hellman-group14-sha256 key exchange method is defined in 517 [RFC8268] and represents a key exchange which has approximately 112 518 bits of security strength that matches 3des-cbc symmetric cipher 519 security strength. It is a reasonably simple transition from SHA-1 520 to SHA-2 and given that diffie-hellman-group14-sha1 and diffie- 521 hellman-group14-sha256 share a MODP group and only differ in the hash 522 function used for the KDF and integrity. Given that diffie-hellman- 523 group14-sha1 is being removed from MTI status, the diffie-hellman- 524 group14-sha256 method MUST be implemented. The rest of the FFC MODP 525 group from [RFC8268] have a larger number of security bits and are 526 suitable for symmetric ciphers that also have a similar number of 527 security bits. 529 Table 10 below provides explicit guidance by name. 531 +===============================+==========+ 532 | Key Exchange Method Name | Guidance | 533 +===============================+==========+ 534 | diffie-hellman-group14-sha256 | MUST | 535 +-------------------------------+----------+ 536 | gss-group14-sha256-* | SHOULD | 537 +-------------------------------+----------+ 538 | diffie-hellman-group15-sha512 | MAY | 539 +-------------------------------+----------+ 540 | gss-group15-sha512-* | MAY | 541 +-------------------------------+----------+ 542 | diffie-hellman-group16-sha512 | SHOULD | 543 +-------------------------------+----------+ 544 | gss-group16-sha512-* | MAY | 545 +-------------------------------+----------+ 546 | diffie-hellman-group17-sha512 | MAY | 547 +-------------------------------+----------+ 548 | gss-group17-sha512-* | MAY | 549 +-------------------------------+----------+ 550 | diffie-hellman-group18-sha512 | MAY | 551 +-------------------------------+----------+ 552 | gss-group18-sha512-* | MAY | 553 +-------------------------------+----------+ 555 Table 10: FFC Named Group Implementation 556 Guidance 558 3.3. Integer Factorization Cryptography (IFC) 560 The rsa1024-sha1 key exchange method is defined in [RFC4432] and uses 561 an RSA 1024-bit modulus with a SHA-1 hash. This key exchange does 562 NOT meet security requirements. This method MUST NOT be implemented. 564 The rsa2048-sha256 key exchange method is defined in [RFC4432] and 565 uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange 566 meets 112 bit minimum security strength. This method MAY be 567 implemented. 569 Table 11 provide a summary of the guidance for IFC key exchanges. 571 +==========================+==========+ 572 | Key Exchange Method Name | Guidance | 573 +==========================+==========+ 574 | rsa1024-sha1 | MUST NOT | 575 +--------------------------+----------+ 576 | rsa2048-sha256 | MAY | 577 +--------------------------+----------+ 579 Table 11: IFC Implementation Guidance 581 3.4. KDFs and Integrity Hashing 583 The SHA-1 and SHA-2 family of hashing algorithms are combined with 584 the FFC, ECC, and IFC algorithms to comprise a key exchange method 585 name. 587 The selected hash algorithm is used both in the KDF as well as for 588 the integrity of the response. 590 All of the key exchanges methods using the SHA-1 hashing algorithm 591 should be deprecated and phased out due to security concerns for SHA- 592 1, as documented in [RFC6194]. 594 Unconditionally deprecating and/or disallowing SHA-1 everywhere will 595 hasten the day when it may be simply removed from implementations 596 completely. Leaving partially-broken algorithms laying around is not 597 a good thing to do. 599 The SHA-2 Family of hashes [RFC6234] is more secure than SHA-1. They 600 have been standardized for use in SSH with many of the currently 601 defined key exchanges. 603 Please note that at the present time, there is no key exchange method 604 for Secure Shell which uses the SHA-3 family of Secure Hashing 605 functions or the Extendable Output Functions. 607 Prior to the changes made by this document, diffie-hellman- 608 group1-sha1 and diffie-hellman-group14-sha1 were mandatory to 609 implement (MTI). diffie-hellman-group14-sha1 is the stronger of the 610 two. Group14 (a 2048-bit MODP group) is defined in [RFC3526]. The 611 group1 MODP group with approximately 80 bits of security is too weak 612 to be retained. However, rather than jumping from the MTI to making 613 it disallowed, many implementers suggested that it should transition 614 to deprecated first and be disallowed at a later time. The group14 615 MODP group using a sha1 hash for the KDF is not as weak as the group1 616 MODP group. There are some legacy situations where it will still 617 provide administrators with value. Transitioning from MTI to one 618 that provides for continued use with the expectation of deprecating 619 or disallowing it in the future was able to find consensus. 620 Therefore, it is considered reasonable to retain the diffie-hellman- 621 group14-sha1 exchange for interoperability with legacy 622 implementations. The diffie-hellman-group14-sha1 key exchange MAY be 623 implemented, but should be put at the end of the list of negotiated 624 key exchanges. 626 The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, 627 gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be 628 implemented. 630 3.5. Secure Shell Extension Negotiation 632 There are two methods, ext-info-c and ext-info-s, defined in 633 [RFC8308]. They provide a mechanism to support other Secure Shell 634 negotiations. Being able to extend functionality is desirable. Both 635 ext-info-c and ext-info-s SHOULD be implemented. 637 4. Summary Guidance for Key Exchange Method Names Implementations 639 The Implement column is the current recommendations of this RFC. 640 Table 12 provides the existing key exchange method names listed 641 alphabetically. 643 +==========================+===========+================+===========+ 644 | Key Exchange Method | Reference | Previous | RFCxxxxx | 645 | Name | | Recommendation | Implement | 646 +==========================+===========+================+===========+ 647 | curve25519-sha256 | RFC8731 | none | SHOULD | 648 +--------------------------+-----------+----------------+-----------+ 649 | curve448-sha512 | RFC8731 | none | MAY | 650 +--------------------------+-----------+----------------+-----------+ 651 | diffie-hellman-group- | RFC4419 | none | SHOULD | 652 | exchange-sha1 | RFC8270 | | NOT | 653 +--------------------------+-----------+----------------+-----------+ 654 | diffie-hellman-group- | RFC4419 | none | MAY | 655 | exchange-sha256 | RFC8720 | | | 656 +--------------------------+-----------+----------------+-----------+ 657 | diffie-hellman- | RFC4253 | MUST | SHOULD | 658 | group1-sha1 | | | NOT | 659 +--------------------------+-----------+----------------+-----------+ 660 | diffie-hellman- | RFC4253 | MUST | MAY | 661 | group14-sha1 | | | | 662 +--------------------------+-----------+----------------+-----------+ 663 | diffie-hellman- | RFC8268 | none | MUST | 664 | group14-sha256 | | | | 665 +--------------------------+-----------+----------------+-----------+ 666 | diffie-hellman- | RFC8268 | none | MAY | 667 | group15-sha512 | | | | 668 +--------------------------+-----------+----------------+-----------+ 669 | diffie-hellman- | RFC8268 | none | SHOULD | 670 | group16-sha512 | | | | 671 +--------------------------+-----------+----------------+-----------+ 672 | diffie-hellman- | RFC8268 | none | MAY | 673 | group17-sha512 | | | | 674 +--------------------------+-----------+----------------+-----------+ 675 | diffie-hellman- | RFC8268 | none | MAY | 676 | group18-sha512 | | | | 677 +--------------------------+-----------+----------------+-----------+ 678 | ecdh-sha2-* | RFC5656 | MAY | MAY | 679 +--------------------------+-----------+----------------+-----------+ 680 | ecdh-sha2-nistp256 | RFC5656 | MUST | SHOULD | 681 +--------------------------+-----------+----------------+-----------+ 682 | ecdh-sha2-nistp384 | RFC5656 | MUST | SHOULD | 683 +--------------------------+-----------+----------------+-----------+ 684 | ecdh-sha2-nistp521 | RFC5656 | MUST | SHOULD | 685 +--------------------------+-----------+----------------+-----------+ 686 | ecmqv-sha2 | RFC5656 | MAY | MAY | 687 +--------------------------+-----------+----------------+-----------+ 688 | ext-info-c | RFC8308 | SHOULD | SHOULD | 689 +--------------------------+-----------+----------------+-----------+ 690 | ext-info-s | RFC8308 | SHOULD | SHOULD | 691 +--------------------------+-----------+----------------+-----------+ 692 | gss-* | RFC4462 | none | MAY | 693 +--------------------------+-----------+----------------+-----------+ 694 | gss- | RFC8732 | SHOULD | SHOULD | 695 | curve25519-sha256-* | | | | 696 +--------------------------+-----------+----------------+-----------+ 697 | gss-curve448-sha512-* | RFC8732 | MAY | MAY | 698 +--------------------------+-----------+----------------+-----------+ 699 | gss-gex-sha1-* | RFC4462 | none | SHOULD | 700 | | | | NOT | 701 +--------------------------+-----------+----------------+-----------+ 702 | gss-group1-sha1-* | RFC4462 | none | SHOULD | 703 | | | | NOT | 704 +--------------------------+-----------+----------------+-----------+ 705 | gss-group14-sha256-* | RFC8732 | none | SHOULD | 706 +--------------------------+-----------+----------------+-----------+ 707 | gss-group15-sha512-* | RFC8732 | none | MAY | 708 +--------------------------+-----------+----------------+-----------+ 709 | gss-group16-sha512-* | RFC8732 | none | MAY | 710 +--------------------------+-----------+----------------+-----------+ 711 | gss-group17-sha512-* | RFC8732 | none | MAY | 712 +--------------------------+-----------+----------------+-----------+ 713 | gss-group18-sha512-* | RFC8732 | none | MAY | 714 +--------------------------+-----------+----------------+-----------+ 715 | gss-nistp256-sha256-* | RFC8732 | none | SHOULD | 716 +--------------------------+-----------+----------------+-----------+ 717 | gss-nistp384-sha384-* | RFC8732 | none | SHOULD | 718 +--------------------------+-----------+----------------+-----------+ 719 | gss-nistp521-sha512-* | RFC8732 | none | SHOULD | 720 +--------------------------+-----------+----------------+-----------+ 721 | rsa1024-sha1 | RFC4432 | none | MUST NOT | 722 +--------------------------+-----------+----------------+-----------+ 723 | rsa2048-sha256 | RFC4432 | none | MAY | 724 +--------------------------+-----------+----------------+-----------+ 726 Table 12: IANA guidance for key exchange method name implementations 728 The full set of official [IANA-KEX] key algorithm method names not 729 otherwise mentioned in this document MAY be implemented. 731 [TO BE REMOVED: This registration should take place at the following 732 location URL: http://www.iana.org/assignments/ssh-parameters/ssh- 733 parameters.xhtml#ssh-parameters-16 It is hoped that the Table 12 in 734 section 4 of this draft provide guidance information to be merged 735 into the IANA ssh-parameters-16 table. Future RFCs may update the 736 these Implementation Guidance notations. ] 738 5. Acknowledgements 740 Thanks to the following people for review and comments: Denis Bider, 741 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 742 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 743 Tero Kivinen, and Travis Finkenauer. 745 Thanks to the following people for code to implement interoperable 746 exchanges using some of these groups as found in an this draft: 747 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 748 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 749 and Poderosa implementations also adopting new Diffie-Hellman groups 750 based on this draft. 752 6. Security Considerations 754 This SSH protocol provides a secure encrypted channel over an 755 insecure network. It performs server host authentication, key 756 exchange, encryption, and integrity checks. It also derives a unique 757 session ID that may be used by higher-level protocols. The key 758 exchange itself, generates a shared secret and uses the hash function 759 for both the KDF and integrity. 761 Full security considerations for this protocol are provided in 762 [RFC4251]. In addition, the security considerations provided in 763 [RFC4432]. Note that Forward Secrecy is NOT available with the 764 rsa1024-sha1 or rsa2048-sha256 key exchanges. 766 It is desirable to deprecate or disallow key exchange methods that 767 are considered weak so they are not in still actively in operation 768 when they are broken. 770 A key exchange method is considered weak when the security strength 771 is insufficient to match the symmetric cipher or the algorithm has 772 been broken. 774 At this time, the 1024-bit MODP group used by diffie-hellman- 775 group1-sha1 is too small for the symmetric ciphers used in SSH. 777 At this time, the rsa1024-sha1 key exchange is too small for the 778 symmetric ciphers used in SSH. 780 The use of SHA-1 for use with any key exchange may not yet be 781 completely broken, but it is time to retire all uses of this 782 algorithm as soon as possible. 784 The diffie-hellman-group14-sha1 algorithm is not yet completely 785 deprecated. This is to provide a practical transition from the MTI 786 algorithms to a new one. However, it would be best to only be as a 787 last resort in key exchange negotiations. All key exchanges methods 788 using the SHA-1 hash are to be considered as deprecated. 790 7. IANA Considerations 792 IANA is requested to annotate entries in [IANA-KEX] with the 793 suggested implementation guidance provided in section 4 "Summary 794 Guidance for Key Exchange Method Names Implementation" in this 795 document. A summary may be found in Table 12 in section 4. The 796 entry with "MUST NOT" should be considered disallowed. An entry with 797 "SHOULD NOT" is deprecated and may be disallowed in the future. 799 8. References 801 8.1. Normative References 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, 805 DOI 10.17487/RFC2119, March 1997, 806 . 808 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 809 Protocol Assigned Numbers", RFC 4250, 810 DOI 10.17487/RFC4250, January 2006, 811 . 813 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 814 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 815 January 2006, . 817 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 818 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 819 May 2017, . 821 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 822 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 823 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 824 . 826 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 827 Minimum Recommended Diffie-Hellman Modulus Size to 2048 828 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 829 . 831 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 832 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 833 2018, . 835 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 836 Shell (SSH) Key Exchange Method Using Curve25519 and 837 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 838 . 840 8.2. Informative References 842 [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell 843 (SSH) Protocol Parameters: Key Exchange Method Names", 844 December 2020, . 847 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 848 Diffie-Hellman groups for Internet Key Exchange (IKE)", 849 RFC 3526, DOI 10.17487/RFC3526, May 2003, 850 . 852 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 853 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 854 January 2006, . 856 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 857 Group Exchange for the Secure Shell (SSH) Transport Layer 858 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 859 . 861 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 862 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 863 March 2006, . 865 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 866 "Generic Security Service Application Program Interface 867 (GSS-API) Authentication and Key Exchange for the Secure 868 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 869 2006, . 871 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 872 Integration in the Secure Shell Transport Layer", 873 RFC 5656, DOI 10.17487/RFC5656, December 2009, 874 . 876 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 877 Considerations for the SHA-0 and SHA-1 Message-Digest 878 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 879 . 881 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 882 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 883 DOI 10.17487/RFC6234, May 2011, 884 . 886 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 887 Internet Key Exchange Protocol Version 2 (IKEv2) Key 888 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 889 . 891 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 892 Application Program Interface (GSS-API) Key Exchange with 893 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 894 . 896 [TRANS-COLL] 897 Bhargavan, K. and G. Leurent, "Transcript Collision 898 Attacks: Breaking Authentication in TLS, IKE, and SSH", 899 Network and Distributed System Security Symposium - NDSS 900 2016, Feb 2016, San Diego, United 901 States. 10.14722/ndss.2016.23418 . hal-01244855, 902 . 904 Author's Address 906 Mark D. Baushke 907 Juniper Networks, Inc. 909 Email: mdb@juniper.net