idnits 2.17.00 (12 Aug 2021) /tmp/idnits18968/draft-ietf-curdle-ssh-kex-sha2-14.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 (10 February 2021) is 464 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) 10 February 2021 5 Intended status: Standards Track 6 Expires: 14 August 2021 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-14 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 14 August 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 . . . . . . 4 55 1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4 56 1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 5 57 1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 59 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 6 60 3.1. SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . . 6 61 3.2. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 6 62 3.2.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 7 63 3.2.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 7 64 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and 65 gss-nistp* . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 8 67 3.3.1. FFC diffie-hellman using generated MODP groups . . . 8 68 3.3.2. FFC diffie-hellman using named MODP groups . . . . . 8 69 3.4. Integer Factorization Cryptography (IFC) . . . . . . . . 9 70 3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 9 71 4. Summary Guidance for Key Exchange Method Names 72 Implementations . . . . . . . . . . . . . . . . . . . . . 9 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Overview and Rationale 83 Secure Shell (SSH) is a common protocol for secure communication on 84 the Internet. In [RFC4253], SSH originally defined two Key Exchange 85 (KEX) Method Names that MUST be implemented. Over time what was once 86 considered secure is no longer considered secure. The purpose of 87 this RFC is to recommend that some published key exchanges be 88 deprecated as well as recommending some that SHOULD and one that MUST 89 be adopted. This document updates [RFC4250] [RFC4253] [RFC4432] 90 [RFC4462] by changing the requirement level ("MUST" moving to 91 "SHOULD" or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or 92 "SHOULD" or "SHOULD NOT" or "MUST NOT") of various key-exchange 93 mechanisms. 95 A key exchange has two components, a hashing algorithm and a public 96 key algorithm. The following subsections describe how to select each 97 component. 99 1.1. Selecting an appropriate hashing algorithm 101 The SHA-1 hash is in the process of being deprecated for many 102 reasons. There have been attacks against SHA-1 that have shown there 103 are weaknesses in the algorithm. Therefore, it is desirable to move 104 away from using it before attacks become more serious. 106 At present, the attacks against SHA-1 are collision attacks that 107 usually rely on human help, rather than a pre-image attack. SHA-1 108 resistance against second pre-image is still at 160 bits, but SSH 109 does not depend on second pre-image resistance, but rather on chosen- 110 prefix collision resistance. 112 Transcript Collision attacks are documented in [TRANS-COLL]. This 113 paper shows that the man in the middle does not tamper with the 114 Diffie-Hellman values and does not know the connection keys. 115 However, it manages to tamper with both I_C and I_S, and can 116 therefore downgrade the negotiated ciphersuite to a weak 117 cryptographic algorithm that the attacker knows how to break. 119 These attacks are still computationally very difficult to perform, 120 but is is desirable that any Key Exchanging using SHA-1 be phased out 121 as soon as possible. 123 These attacks are potentially slightly easier when the server 124 provides the Diffie-Hellman parameters such as using the [RFC4419] 125 generated set of diffie-hellman parameters with SHA-1 hashing. If 126 there is a need for using SHA-1 in a Key Exchange for compatibility, 127 it would be desirable it be listed last in the preference list of key 128 exchanges. 130 Use of the SHA-2 family of hashes found in [RFC6234] rather than the 131 SHA-1 hash is strongly advised. 133 When it comes to the SHA-2 family of Secure Hashing functions, 134 SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of 135 security strength; SHA2-384 has 192 bits of security strength; and 136 SHA2-512 has 256 bits of security strength. As the same compute 137 power is needed for both SHA2-224 and SHA2-256 and currently no KeX 138 uses SHA2-224, it is suggested that the minimum secure hashing 139 function that should be used for Key Exchange Methods is SHA2-256. 141 To avoid combinatorial explosion of key exchange names, newer key 142 exchanges are restricting to the use of *-sha256 and *-sha512. 144 1.2. Selecting an appropriate Public Key Algorithm 146 SSH uses mathematically hard problems for doing Key Exchange: 148 * Elliptic Curve Cryptography (ECC) has families of curves for Key 149 Exchange Methods for SSH. NIST prime curves with names and other 150 curves are available using an object identifier (OID) with 151 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 152 and Curve448 key exchanges are used with ECDH via [RFC8731]. 154 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) 155 key exchange with "safe primes" either from a specified list found 156 in [RFC3526] or generated dynamically via [RFC4419] as updated by 157 [RFC8270]. 159 * Integer Factorization Cryptography (IFC) using the RSA algorithm 160 is provided for in [RFC4432]. 162 It is desirable for the security strength of the key exchange be 163 chosen to be comparable with the security strength of the other 164 elements of the SSH handshake. Attackers can target the weakest 165 element of the SSH handshake. 167 It is desirable to select a minimum of 112 bits of security strength. 168 Based on implementer security needs, a stronger minimum may be 169 desired. 171 1.2.1. Elliptic Curve Cryptography (ECC) 173 For ECC, it is recommended to select a curve with approximately 128 174 bits of security strength. 176 +============+=============================+ 177 | Curve Name | Estimated Security Strength | 178 +============+=============================+ 179 | nistp256 | 128 bits | 180 +------------+-----------------------------+ 181 | nistp384 | 192 bits | 182 +------------+-----------------------------+ 183 | nistp521 | 512 bits | 184 +------------+-----------------------------+ 185 | Curve25519 | 128 bits | 186 +------------+-----------------------------+ 187 | Curve448 | 224 bits | 188 +------------+-----------------------------+ 190 Table 1: ECC Security Strengths 192 1.2.2. Finite Field Cryptography (FFC) 194 For FFC, it is recommended to use a modulus with 2048 bits (112 bits 195 of security strength). 197 +==================+=============================+============+ 198 | Prime Field Size | Estimated Security Strength | Example | 199 | | | MODP Group | 200 +==================+=============================+============+ 201 | 2048-bit | 112 bits | group14 | 202 +------------------+-----------------------------+------------+ 203 | 3072-bit | 128 bits | group15 | 204 +------------------+-----------------------------+------------+ 205 | 4096-bit | 152 bits | group16 | 206 +------------------+-----------------------------+------------+ 207 | 6144-bit | 176 bits | group17 | 208 +------------------+-----------------------------+------------+ 209 | 8192-bit | 200 bits | group18 | 210 +------------------+-----------------------------+------------+ 212 Table 2: FFC MODP Security Strengths 214 The minimum MODP group that MAY be used is the 2048-bit MODP group14. 215 Implementations SHOULD support a 3072-bit MODP group or larger. 217 1.2.3. Integer Factorization Cryptography (IFC) 219 The only IFC algorithm for key exchange is the RSA algorithm 220 specified in [RFC4432]. The minimum modulus size is 2048 bits. The 221 use of a SHA-2 Family hash with RSA 2048-bit keys has sufficient 222 security. The rsa1024-sha1 key exchange has less than 2048 bits and 223 MUST NOT be implemented. 225 +=====================+=============================+ 226 | Key Exchange Method | Estimated Security Strength | 227 +=====================+=============================+ 228 | rsa1024-sha1 | 80 bits | 229 +---------------------+-----------------------------+ 230 | rsa2048-sha256 | 112 bits | 231 +---------------------+-----------------------------+ 233 Table 3: IFC Security Strengths 235 2. Requirements Language 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in 240 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 241 capitals, as shown here. 243 3. Key Exchange Methods 245 This memo adopts the style and conventions of [RFC4253] in specifying 246 how the use of data key exchange is indicated in SSH. 248 This RFC also collects key exchange method names in various existing 249 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 250 [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a 251 suggested suitability for implementation of MUST, SHOULD, SHOULD NOT, 252 and MUST NOT. Any method not explicitly listed MAY be implemented. 254 This document is intended to provide guidance as to what key exchange 255 algorithms are to be considered for new or updated SSH 256 implementations. 258 3.1. SHA-1 and SHA-2 Hashing 260 All of the key exchanges using the SHA-1 hashing algorithm should be 261 deprecated and phased out of use because SHA-1 has security concerns, 262 as documented in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is 263 the only one which is more secure than SHA-1 and has been 264 standardized for use with SSH key exchanges. 266 Prior to the changes made by this document, diffie-hellman- 267 group1-sha1 and diffie-hellman-group14-sha1 were mandatory to 268 implement (MTI). diffie-hellman-group14-sha1 is the stronger of the 269 two. Group14 (a 2048-bit MODP group) is defined in [RFC3526]. It is 270 reasonable to retain the diffie-hellman-group14-sha1 exchange for 271 interoperability with legacy implementations. The diffie-hellman- 272 group14-sha1 key exchange MAY be implemented. 274 The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, 275 gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be 276 implemented. 278 3.2. Elliptic Curve Cryptography (ECC) 279 3.2.1. curve25519-sha256 and gss-curve25519-sha256-* 281 Curve25519 is efficient on a wide range of architectures with 282 properties that allow higher performance implementations compared to 283 traditional elliptic curves. The use of SHA2-256 (also known as 284 SHA-256 and sha256) as defined in [RFC6234] for integrity is a 285 reasonable one for this method. These key exchange methods are 286 described in [RFC8731] and [RFC8732] and are similar to the IKEv2 Key 287 Agreement described in [RFC8031]. The curve25519-sha256 key exchange 288 method has multiple implementations and SHOULD be implemented. The 289 gss-curve25519-sha256-* key exchange method SHOULD also be 290 implemented because it shares the same performance and security 291 characteristics as curve25519-sha2. 293 3.2.2. curve448-sha512 and gss-curve448-sha512-* 295 Curve448 provides more security strength than Curve25519 at a higher 296 computational and bandwidth cost. It uses SHA2-512 (also known as 297 SHA-512) defined in [RFC6234] for integrity. These Key Exchange 298 Methods are described in [RFC8731] and [RFC8732] and are similar to 299 the IKEv2 Key Agreement described in [RFC8031]. The curve448-sha512 300 key exchange method MAY be implemented. The gss-curve448-sha512-* 301 key exchange method MAY also be implemented because it shares the 302 same performance and security characteristics as curve448-sha512. 304 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp* 306 The ecdh-sha2-* name-space allows for other curves to be defined for 307 the elliptic curve Diffie Hellman key exchange. At the time of this 308 writing, there are three named curves in this name-space which SHOULD 309 be supported. They appear in [RFC5656] in section 10.1 ("Required 310 Curves"). All of the NISTP curves named therein are mandatory to 311 implement if any of that RFC is implemented. If implemented, the 312 named curves SHOULD always be enabled unless specifically disabled by 313 local security policy. In [RFC5656], section 6.1, the method to name 314 other ECDH curves using OIDs is specified. These other curves MAY be 315 implemented. 317 The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms 318 used by ecdh-sha2-* names. The are described in [RFC8732]. The 319 table provides guidance for implementation. 321 ECDH reduces bandwidth of key exchanges compared to FFC DH at a 322 similar security strength. 324 The following table lists algorithms as SHOULD where implementations 325 may be more efficient or widely deployed. The items listed as MAY 326 are potentially less efficient. 328 +==========================+==========+ 329 | Key Exchange Method Name | Guidance | 330 +==========================+==========+ 331 | ecdh-sha2-* | MAY | 332 +--------------------------+----------+ 333 | ecdh-sha2-nistp256 | SHOULD | 334 +--------------------------+----------+ 335 | gss-nistp256-sha256-* | SHOULD | 336 +--------------------------+----------+ 337 | ecdh-sha2-nistp384 | SHOULD | 338 +--------------------------+----------+ 339 | gss-nistp384-sha384-* | SHOULD | 340 +--------------------------+----------+ 341 | ecdh-sha2-nistp521 | SHOULD | 342 +--------------------------+----------+ 343 | gss-nistp521-sha512-* | SHOULD | 344 +--------------------------+----------+ 345 | ecmqv-sha2 | MAY | 346 +--------------------------+----------+ 348 Table 4: ECDH Implementation Guidance 350 It is advisable to match the ECDSA and ECDH algorithms to use the 351 same curve for both to maintain the same security strength in the 352 connection. 354 3.3. Finite Field Cryptography (FFC) 356 3.3.1. FFC diffie-hellman using generated MODP groups 358 This random selection from a set of pre-generated moduli for key 359 exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates 360 that implementations avoid any MODP group whose modulus size is less 361 than 2048 bits. Care should be taken in the pre-generation of the 362 moduli P and generator G such that the generator provides a Q-ordered 363 subgroup of P. Otherwise, the parameter set may leak one bit of the 364 shared secret leaving the MODP group half as strong. This key 365 exchange MAY be used. 367 3.3.2. FFC diffie-hellman using named MODP groups 369 diffie-hellman-group14-sha256 represents the smallest FFC DH key 370 exchange method considered to be secure. It is a reasonably simple 371 transition from SHA-1 to SHA-2. The diffie-hellman-group14-sha256 372 method MUST be implemented. The rest of the FFC MODP groups MAY be 373 implemented. The table below provides explicit guidance by name. 375 +===============================+==========+ 376 | Key Exchange Method Name | Guidance | 377 +===============================+==========+ 378 | diffie-hellman-group14-sha256 | MUST | 379 +-------------------------------+----------+ 380 | gss-group14-sha256-* | SHOULD | 381 +-------------------------------+----------+ 382 | diffie-hellman-group15-sha512 | MAY | 383 +-------------------------------+----------+ 384 | gss-group15-sha512-* | MAY | 385 +-------------------------------+----------+ 386 | diffie-hellman-group16-sha512 | SHOULD | 387 +-------------------------------+----------+ 388 | gss-group16-sha512-* | MAY | 389 +-------------------------------+----------+ 390 | diffie-hellman-group17-sha512 | MAY | 391 +-------------------------------+----------+ 392 | gss-group17-sha512-* | MAY | 393 +-------------------------------+----------+ 394 | diffie-hellman-group18-sha512 | MAY | 395 +-------------------------------+----------+ 396 | gss-group18-sha512-* | MAY | 397 +-------------------------------+----------+ 399 Table 5: FFC Implementation Guidance 401 3.4. Integer Factorization Cryptography (IFC) 403 The rsa2048-sha256 key exchange method is defined in [RFC4432]. It 404 uses an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange 405 meets 112 bit minimum security strength. This method MAY be 406 implemented. 408 3.5. Secure Shell Extension Negotiation 410 There are two key exchange methods, ext-info-c and ext-info-s, 411 defined in [RFC8308] which are not actually key exchanges. They 412 provide a method to support other Secure Shell negotiations. Being 413 able to extend functionality is desirable. This method SHOULD be 414 implemented. 416 4. Summary Guidance for Key Exchange Method Names Implementations 418 The Implement column is the current recommendations of this RFC. Key 419 Exchange Method Names are listed alphabetically. 421 +======================================+===========+============+ 422 | Key Exchange Method Name | Reference | Implement | 423 +======================================+===========+============+ 424 | curve25519-sha256 | RFC8731 | SHOULD | 425 +--------------------------------------+-----------+------------+ 426 | curve448-sha512 | RFC8731 | MAY | 427 +--------------------------------------+-----------+------------+ 428 | diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT | 429 +--------------------------------------+-----------+------------+ 430 | diffie-hellman-group-exchange-sha256 | RFC4419 | MAY | 431 +--------------------------------------+-----------+------------+ 432 | diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT | 433 +--------------------------------------+-----------+------------+ 434 | diffie-hellman-group14-sha1 | RFC4253 | MAY | 435 +--------------------------------------+-----------+------------+ 436 | diffie-hellman-group14-sha256 | RFC8268 | MUST | 437 +--------------------------------------+-----------+------------+ 438 | diffie-hellman-group15-sha512 | RFC8268 | MAY | 439 +--------------------------------------+-----------+------------+ 440 | diffie-hellman-group16-sha512 | RFC8268 | SHOULD | 441 +--------------------------------------+-----------+------------+ 442 | diffie-hellman-group17-sha512 | RFC8268 | MAY | 443 +--------------------------------------+-----------+------------+ 444 | diffie-hellman-group18-sha512 | RFC8268 | MAY | 445 +--------------------------------------+-----------+------------+ 446 | ecdh-sha2-* | RFC5656 | MAY | 447 +--------------------------------------+-----------+------------+ 448 | ecdh-sha2-nistp256 | RFC5656 | SHOULD | 449 +--------------------------------------+-----------+------------+ 450 | ecdh-sha2-nistp384 | RFC5656 | SHOULD | 451 +--------------------------------------+-----------+------------+ 452 | ecdh-sha2-nistp521 | RFC5656 | SHOULD | 453 +--------------------------------------+-----------+------------+ 454 | ecmqv-sha2 | RFC5656 | MAY | 455 +--------------------------------------+-----------+------------+ 456 | ext-info-c | RFC8308 | SHOULD | 457 +--------------------------------------+-----------+------------+ 458 | ext-info-s | RFC8308 | SHOULD | 459 +--------------------------------------+-----------+------------+ 460 | gss-* | RFC4462 | MAY | 461 +--------------------------------------+-----------+------------+ 462 | gss-curve25519-sha256-* | RFC8732 | SHOULD | 463 +--------------------------------------+-----------+------------+ 464 | gss-curve448-sha512-* | RFC8732 | MAY | 465 +--------------------------------------+-----------+------------+ 466 | gss-gex-sha1-* | RFC4462 | SHOULD NOT | 467 +--------------------------------------+-----------+------------+ 468 | gss-group1-sha1-* | RFC4462 | SHOULD NOT | 469 +--------------------------------------+-----------+------------+ 470 | gss-group14-sha256-* | RFC8732 | SHOULD | 471 +--------------------------------------+-----------+------------+ 472 | gss-group15-sha512-* | RFC8732 | MAY | 473 +--------------------------------------+-----------+------------+ 474 | gss-group16-sha512-* | RFC8732 | MAY | 475 +--------------------------------------+-----------+------------+ 476 | gss-group17-sha512-* | RFC8732 | MAY | 477 +--------------------------------------+-----------+------------+ 478 | gss-group18-sha512-* | RFC8732 | MAY | 479 +--------------------------------------+-----------+------------+ 480 | gss-nistp256-sha256-* | RFC8732 | SHOULD | 481 +--------------------------------------+-----------+------------+ 482 | gss-nistp384-sha384-* | RFC8732 | SHOULD | 483 +--------------------------------------+-----------+------------+ 484 | gss-nistp521-sha512-* | RFC8732 | SHOULD | 485 +--------------------------------------+-----------+------------+ 486 | rsa1024-sha1 | RFC4432 | MUST NOT | 487 +--------------------------------------+-----------+------------+ 488 | rsa2048-sha256 | RFC4432 | MAY | 489 +--------------------------------------+-----------+------------+ 491 Table 6: IANA guidance for key exchange method name 492 implementations 494 The full set of official [IANA-KEX] key algorithm method names not 495 otherwise mentioned in this document MAY be implemented. 497 [TO BE REMOVED: This registration should take place at the following 498 location URL: http://www.iana.org/assignments/ssh-parameters/ssh- 499 parameters.xhtml#ssh-parameters-16 ] 501 5. Acknowledgements 503 Thanks to the following people for review and comments: Denis Bider, 504 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 505 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 506 Tero Kivinen, and Travis Finkenauer. 508 Thanks to the following people for code to implement interoperable 509 exchanges using some of these groups as found in an this draft: 510 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 511 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 512 and Poderosa implementations also adopting new Diffie-Hellman groups 513 based on this draft. 515 6. Security Considerations 517 This SSH protocol provides a secure encrypted channel over an 518 insecure network. It performs server host authentication, key 519 exchange, encryption, and integrity checks. It also derives a unique 520 session ID that may be used by higher-level protocols. 522 Full security considerations for this protocol are provided in 523 [RFC4251]. 525 It is desirable to deprecate or remove key exchange method name that 526 are considered weak. A key exchange method may be weak because too 527 few bits are used, or the hashing algorithm is considered too weak, 528 or for other reasons. 530 7. IANA Considerations 532 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 533 implemented as being deprecated by this document. 535 8. References 537 8.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 545 Diffie-Hellman groups for Internet Key Exchange (IKE)", 546 RFC 3526, DOI 10.17487/RFC3526, May 2003, 547 . 549 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 550 Protocol Assigned Numbers", RFC 4250, 551 DOI 10.17487/RFC4250, January 2006, 552 . 554 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 555 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 556 January 2006, . 558 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 559 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 560 May 2017, . 562 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 563 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 564 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 565 . 567 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 568 Minimum Recommended Diffie-Hellman Modulus Size to 2048 569 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 570 . 572 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 573 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 574 2018, . 576 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 577 Shell (SSH) Key Exchange Method Using Curve25519 and 578 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 579 . 581 8.2. Informative References 583 [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell 584 (SSH) Protocol Parameters: Key Exchange Method Names", 585 December 2020, . 588 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 589 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 590 January 2006, . 592 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 593 Group Exchange for the Secure Shell (SSH) Transport Layer 594 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 595 . 597 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 598 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 599 March 2006, . 601 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 602 "Generic Security Service Application Program Interface 603 (GSS-API) Authentication and Key Exchange for the Secure 604 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 605 2006, . 607 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 608 Integration in the Secure Shell Transport Layer", 609 RFC 5656, DOI 10.17487/RFC5656, December 2009, 610 . 612 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 613 Considerations for the SHA-0 and SHA-1 Message-Digest 614 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 615 . 617 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 618 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 619 DOI 10.17487/RFC6234, May 2011, 620 . 622 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 623 Internet Key Exchange Protocol Version 2 (IKEv2) Key 624 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 625 . 627 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 628 Application Program Interface (GSS-API) Key Exchange with 629 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 630 . 632 [TRANS-COLL] 633 Bhargavan, K. and G. Leurent, "Transcript Collision 634 Attacks: Breaking Authentication in TLS, IKE, and SSH", 635 Network and Distributed System Security Symposium - NDSS 636 2016, Feb 2016, San Diego, United 637 States. 10.14722/ndss.2016.23418 . hal-01244855, 638 . 640 Author's Address 642 Mark D. Baushke 643 Juniper Networks, Inc. 645 Email: mdb@juniper.net