idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-13.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 (14 January 2021) is 1198 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) 14 January 2021 5 Intended status: Standards Track 6 Expires: 18 July 2021 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-13 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 July 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 . . . . . . 3 55 1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4 56 1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 4 57 1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 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-* . . . . 6 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 2nd pre-image is still at 160 bits, but SSH does 109 not depend on that, but rather on chosen prefix resistance. 111 Transcript Collision attacks are documented in [TRANS-COLL]. This 112 paper shows that the man in the middle does not tamper with the 113 Diffie-Hellman values and does not know the connection keys. 114 However, it manages to tamper with both Ic and Is, and can therefore 115 downgrade the negotiated ciphersuite to a weak cryptographic 116 algorithm that the attacker knows how to break. 118 These attacks are still computationally very difficult to perform, 119 but is is desirable that any Key Exchanging using SHA-1 be phased out 120 as soon as possible. 122 These attacks are potentially slightly easier when the server 123 provides the Diffie-Hellman parameters such as using the [RFC4419] 124 generated set of diffie-hellman parameters with SHA-1 hashing. If 125 there is a need for using SHA-1 in a Key Exchange for compatibility, 126 it would be desirable it be listed last in the preference list of key 127 exchanges. 129 Use of the SHA-2 family of hashes found in [RFC6234] rather than the 130 SHA-1 hash is strongly advised. 132 When it comes to the SHA-2 family of Secure Hashing functions, 133 SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of 134 security strength; SHA2-384 has 192 bits of security strength; and 135 SHA2-512 has 256 bits of security strength. As the same compute 136 power is needed for both SHA2-224 and SHA2-256 and currently no KeX 137 uses SHA2-224, it is suggested that the minimum secure hashing 138 function that should be used for Key Exchange Methods is SHA2-256. 140 To avoid combinatorial explosion of key exchange names, newer key 141 exchanges are restricting to the use of *-sha256 and *-sha512. 143 1.2. Selecting an appropriate Public Key Algorithm 145 SSH uses mathematically hard problems for doing Key Exchange: 147 * Elliptic Curve Cryptography (ECC) has families of curves for Key 148 Exchange Methods for SSH. NIST prime curves with names and other 149 curves are available using an object identifier (OID) with 150 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 151 and Curve448 key exchanges are used with ECDH via [RFC8731]. 153 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) 154 key exchange with "safe primes" either from a specified list found 155 in [RFC3526] or generated dynamically via [RFC4419] as updated by 156 [RFC8270]. 158 * Integer Factorization Cryptography (IFC) using the RSA algorithm 159 is provided for in [RFC4432]. 161 It is desirable for the security strength of the key exchange be 162 chosen to be comparable with the security strength of the other 163 elements of the SSH handshake. Attackers can target the weakest 164 element of the SSH handshake. 166 It is desirable to select a minimum of 112 bits of security strength. 167 Based on implementer security needs, a stronger minimum may be 168 desired. 170 1.2.1. Elliptic Curve Cryptography (ECC) 172 For ECC, it is recommended to select one with approximately 128 bits 173 of security strength. 175 +============+=============================+ 176 | Curve Name | Estimated Security Strength | 177 +============+=============================+ 178 | nistp256 | 128 bits | 179 +------------+-----------------------------+ 180 | nistp384 | 192 bits | 181 +------------+-----------------------------+ 182 | nistp521 | 512 bits | 183 +------------+-----------------------------+ 184 | Curve25519 | 128 bits | 185 +------------+-----------------------------+ 186 | Curve448 | 224 bits | 187 +------------+-----------------------------+ 189 Table 1: ECC Security Strengths 191 1.2.2. Finite Field Cryptography (FFC) 193 For FFC, a modulus 2048 bits (112 bits of security strength). 195 +==================+=============================+============+ 196 | Prime Field Size | Estimated Security Strength | Example | 197 | | | MODP Group | 198 +==================+=============================+============+ 199 | 2048-bit | 112 bits | group14 | 200 +------------------+-----------------------------+------------+ 201 | 3072-bit | 128 bits | group15 | 202 +------------------+-----------------------------+------------+ 203 | 4096-bit | 152 bits | group16 | 204 +------------------+-----------------------------+------------+ 205 | 6144-bit | 176 bits | group17 | 206 +------------------+-----------------------------+------------+ 207 | 8192-bit | 200 bits | group18 | 208 +------------------+-----------------------------+------------+ 210 Table 2: FFC MODP Security Strengths 212 The minimum MODP group that MAY be used is the 2048-bit MODP group14. 213 Implementations SHOULD support a 3072-bit MODP group or larger. 215 1.2.3. Integer Factorization Cryptography (IFC) 217 The only IFC algorithm for key exchange is the RSA algorithm via 218 [RFC4432]. The minimum modulus size is 2048 bits. The use of a 219 SHA-2 Family hash with RSA 2048-bit keys has sufficient security. 220 The rsa1024-sha1 key exchange has less than 2048 bits and MUST NOT be 221 implemented. 223 +=====================+=============================+ 224 | Key Exchange Method | Estimated Security Strength | 225 +=====================+=============================+ 226 | rsa1024-sha1 | 80 bits | 227 +---------------------+-----------------------------+ 228 | rsa2048-sha256 | 112 bits | 229 +---------------------+-----------------------------+ 231 Table 3: IFC Security Strengths 233 2. Requirements Language 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 237 "OPTIONAL" in this document are to be interpreted as described in 238 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 239 capitals, as shown here. 241 3. Key Exchange Methods 243 This memo adopts the style and conventions of [RFC4253] in specifying 244 how the use of data key exchange is indicated in SSH. 246 This RFC also collects key exchange method names in various existing 247 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 248 [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a 249 suggested suitability for implementation of MUST, SHOULD, SHOULD NOT, 250 and MUST NOT. Any method not explicitly listed MAY be implemented. 252 This document is intended to provide guidance as to what key exchange 253 algorithms are to be considered for new or updated SSH 254 implementations. 256 3.1. SHA-1 and SHA-2 Hashing 258 All of the key exchanges using the SHA-1 hashing algorithm should be 259 deprecated and phased out of use because SHA-1 has security concerns 260 provided in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is the 261 only one which is more secure than SHA-1 and has been standardized 262 for use with SSH key exchanges. 264 diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are 265 currently mandatory to implement (MTI). diffie-hellman-group14-sha1 266 is the stronger of the two. Group14 (a 2048-bit MODP group) is 267 defined in [RFC3526]. It is reasonable to retain the diffie-hellman- 268 group14-sha1 exchange for interoperability with legacy 269 implementations. The diffie-hellman-group14-sha1 key exchange MAY be 270 implemented. 272 The diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, 273 gss-gex-sha1-*, and gss-group1-sha1-* key exchanges SHOULD NOT be 274 implemented. 276 3.2. Elliptic Curve Cryptography (ECC) 278 3.2.1. curve25519-sha256 and gss-curve25519-sha256-* 280 Curve25519 is efficient on a wide range of architectures with 281 properties that allow higher performance implementations compared to 282 traditional elliptic curves. The use of SHA2-256 (also known as 283 SHA-256 and sha256) as defined in [RFC6234] for integrity is a 284 reasonable one for this method. These key exchange methods are 285 described in [RFC8731] and [RFC8732] and is similar to the IKEv2 Key 286 Agreement described in [RFC8031]. The curve25519-sha256 key exchange 287 method has multiple implementations and SHOULD be implemented. The 288 gss-curve25519-sha256-* key exchange method SHOULD also be 289 implemented because it shares the same performance and security 290 characteristics as curve25519-sha2. 292 3.2.2. curve448-sha512 and gss-curve448-sha512-* 294 Curve448 provides more security strength than Curve25519 at a higher 295 computational and bandwidth cost. It uses SHA2-512 (also known as 296 SHA-512) defined in [RFC6234] for integrity. This Key Exchange 297 Method is described in [RFC8731] and is similar to the IKEv2 Key 298 Agreement described in [RFC8031]. This method MAY be implemented. 299 The gss-curve448-sha512-* key exchange method MAY also be implemented 300 because it shares the same performance and security characteristics 301 as curve448-sha512. 303 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp* 305 The ecdh-sha2-* name-space allows for other curves to be defined for 306 the elliptic curve Diffie Hellman key exchange. At present, there 307 are three named curves in this name-space which SHOULD be supported. 308 They appear in [RFC5656] in section 10.1 Required Curves all of the 309 NISTP curves named are mandatory to implement if any of this RFC is 310 implemented. This set of methods MAY be implemented. If 311 implemented, the named curves SHOULD always be enabled unless 312 specifically disabled by local security policy. In [RFC5656], 313 section 6.1, the method to name other ECDH curves using OIDs is 314 specified. These other curves MAY be implemented. 316 The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms 317 used by ecdh-sha2-* names. The table provides guidance for 318 implementation. 320 ECDH reduces bandwidth of key exchanges compared to FFC DH at a 321 similar security strength. 323 The following table lists algorithms as SHOULD where implementations 324 may be more efficient or widely deployed. The items listed as MAY 325 are potentially less efficient. 327 +==========================+==========+ 328 | Key Exchange Method Name | Guidance | 329 +==========================+==========+ 330 | ecdh-sha2-* | MAY | 331 +--------------------------+----------+ 332 | ecdh-sha2-nistp256 | SHOULD | 333 +--------------------------+----------+ 334 | gss-nistp256-sha256-* | SHOULD | 335 +--------------------------+----------+ 336 | ecdh-sha2-nistp384 | SHOULD | 337 +--------------------------+----------+ 338 | gss-nistp384-sha384-* | SHOULD | 339 +--------------------------+----------+ 340 | ecdh-sha2-nistp521 | SHOULD | 341 +--------------------------+----------+ 342 | gss-nistp521-sha512-* | SHOULD | 343 +--------------------------+----------+ 344 | ecmqv-sha2 | MAY | 345 +--------------------------+----------+ 347 Table 4: ECDH Implementation Guidance 349 It is advisable to match the ECDSA and ECDH algorithms to use the 350 same curve for both to maintain the same security strength in the 351 connection. 353 3.3. Finite Field Cryptography (FFC) 355 3.3.1. FFC diffie-hellman using generated MODP groups 357 This random selection from a set of pre-generated moduli for key 358 exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates 359 implementations avoid any MODP group whose modulus size is less than 360 2048 bits. Care should be taken in the pre-generation of the moduli 361 P and generator G such that the generator provides a Q-ordered 362 subgroup of P. Otherwise, the parameter set may leak one bit of the 363 shared secret leaving the MODP group half as strong. This key 364 exchange MAY be used. 366 3.3.2. FFC diffie-hellman using named MODP groups 368 diffie-hellman-group14-sha256 represents the smallest FFC DH key 369 exchange method considered to be secure. It is a reasonably simple 370 transition from SHA-1 to SHA-2. diffie-hellman-group14-sha256 method 371 MUST be implemented. The rest of the FFC MODP groups MAY be 372 implemented. The table below provides explicit guidance by name. 374 +===============================+==========+ 375 | Key Exchange Method Name | Guidance | 376 +===============================+==========+ 377 | diffie-hellman-group14-sha256 | MUST | 378 +-------------------------------+----------+ 379 | gss-group14-sha256-* | SHOULD | 380 +-------------------------------+----------+ 381 | diffie-hellman-group15-sha512 | MAY | 382 +-------------------------------+----------+ 383 | gss-group15-sha512-* | MAY | 384 +-------------------------------+----------+ 385 | diffie-hellman-group16-sha512 | SHOULD | 386 +-------------------------------+----------+ 387 | gss-group16-sha512-* | MAY | 388 +-------------------------------+----------+ 389 | diffie-hellman-group17-sha512 | MAY | 390 +-------------------------------+----------+ 391 | gss-group17-sha512-* | MAY | 392 +-------------------------------+----------+ 393 | diffie-hellman-group18-sha512 | MAY | 394 +-------------------------------+----------+ 395 | gss-group18-sha512-* | MAY | 396 +-------------------------------+----------+ 398 Table 5: FFC Implementation Guidance 400 3.4. Integer Factorization Cryptography (IFC) 402 The rsa2048-sha256 key exchange method is defined in [RFC4432]. Uses 403 an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange 404 meets 112 bit minimum security strength. This method MAY be 405 implemented. 407 3.5. Secure Shell Extension Negotiation 409 There are two key exchange methods, ext-info-c and ext-info-s, 410 defined in [RFC8308] which are not actually key exchanges. They 411 provide a method to support other Secure Shell negotiations. Being 412 able to extend functionality is desirable. This method SHOULD be 413 implemented. 415 4. Summary Guidance for Key Exchange Method Names Implementations 417 The Implement column is the current recommendations of this RFC. Key 418 Exchange Method Names are listed alphabetically. 420 +======================================+===========+============+ 421 | Key Exchange Method Name | Reference | Implement | 422 +======================================+===========+============+ 423 | curve25519-sha256 | RFC8731 | SHOULD | 424 +--------------------------------------+-----------+------------+ 425 | curve448-sha512 | RFC8731 | MAY | 426 +--------------------------------------+-----------+------------+ 427 | diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT | 428 +--------------------------------------+-----------+------------+ 429 | diffie-hellman-group-exchange-sha256 | RFC4419 | MAY | 430 +--------------------------------------+-----------+------------+ 431 | diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT | 432 +--------------------------------------+-----------+------------+ 433 | diffie-hellman-group14-sha1 | RFC4253 | MAY | 434 +--------------------------------------+-----------+------------+ 435 | diffie-hellman-group14-sha256 | RFC8268 | MUST | 436 +--------------------------------------+-----------+------------+ 437 | diffie-hellman-group15-sha512 | RFC8268 | MAY | 438 +--------------------------------------+-----------+------------+ 439 | diffie-hellman-group16-sha512 | RFC8268 | SHOULD | 440 +--------------------------------------+-----------+------------+ 441 | diffie-hellman-group17-sha512 | RFC8268 | MAY | 442 +--------------------------------------+-----------+------------+ 443 | diffie-hellman-group18-sha512 | RFC8268 | MAY | 444 +--------------------------------------+-----------+------------+ 445 | ecdh-sha2-* | RFC5656 | MAY | 446 +--------------------------------------+-----------+------------+ 447 | ecdh-sha2-nistp256 | RFC5656 | SHOULD | 448 +--------------------------------------+-----------+------------+ 449 | ecdh-sha2-nistp384 | RFC5656 | SHOULD | 450 +--------------------------------------+-----------+------------+ 451 | ecdh-sha2-nistp521 | RFC5656 | SHOULD | 452 +--------------------------------------+-----------+------------+ 453 | ecmqv-sha2 | RFC5656 | MAY | 454 +--------------------------------------+-----------+------------+ 455 | ext-info-c | RFC8308 | SHOULD | 456 +--------------------------------------+-----------+------------+ 457 | ext-info-s | RFC8308 | SHOULD | 458 +--------------------------------------+-----------+------------+ 459 | gss-* | RFC4462 | MAY | 460 +--------------------------------------+-----------+------------+ 461 | gss-curve25519-sha256-* | RFC8732 | SHOULD | 462 +--------------------------------------+-----------+------------+ 463 | gss-curve448-sha512-* | RFC8732 | MAY | 464 +--------------------------------------+-----------+------------+ 465 | gss-gex-sha1-* | RFC4462 | SHOULD NOT | 466 +--------------------------------------+-----------+------------+ 467 | gss-group1-sha1-* | RFC4462 | SHOULD NOT | 468 +--------------------------------------+-----------+------------+ 469 | gss-group14-sha256-* | RFC8732 | SHOULD | 470 +--------------------------------------+-----------+------------+ 471 | gss-group15-sha512-* | RFC8732 | MAY | 472 +--------------------------------------+-----------+------------+ 473 | gss-group16-sha512-* | RFC8732 | SHOULD | 474 +--------------------------------------+-----------+------------+ 475 | gss-group17-sha512-* | RFC8732 | MAY | 476 +--------------------------------------+-----------+------------+ 477 | gss-group18-sha512-* | RFC8732 | MAY | 478 +--------------------------------------+-----------+------------+ 479 | gss-nistp256-sha256-* | RFC8732 | SHOULD | 480 +--------------------------------------+-----------+------------+ 481 | gss-nistp384-sha384-* | RFC8732 | SHOULD | 482 +--------------------------------------+-----------+------------+ 483 | gss-nistp521-sha512-* | RFC8732 | SHOULD | 484 +--------------------------------------+-----------+------------+ 485 | rsa1024-sha1 | RFC4432 | MUST NOT | 486 +--------------------------------------+-----------+------------+ 487 | rsa2048-sha256 | RFC4432 | MAY | 488 +--------------------------------------+-----------+------------+ 490 Table 6: IANA guidance for key exchange method name 491 implementations 493 The full set of official [IANA-KEX] key algorithm method names not 494 otherwise mentioned in this document MAY be implemented. 496 [TO BE REMOVED: This registration should take place at the following 497 location URL: http://www.iana.org/assignments/ssh-parameters/ssh- 498 parameters.xhtml#ssh-parameters-16 ] 500 5. Acknowledgements 502 Thanks to the following people for review and comments: Denis Bider, 503 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 504 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 505 Tero Kivinen, and Travis Finkenauer. 507 Thanks to the following people for code to implement interoperable 508 exchanges using some of these groups as found in an this draft: 509 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 510 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 511 and Poderosa implementations also adopting new Diffie-Hellman groups 512 based on this draft. 514 6. Security Considerations 516 This SSH protocol provides a secure encrypted channel over an 517 insecure network. It performs server host authentication, key 518 exchange, encryption, and integrity checks. It also derives a unique 519 session ID that may be used by higher-level protocols. 521 Full security considerations for this protocol are provided in 522 [RFC4251]. 524 It is desirable to deprecate or remove key exchange method name that 525 are considered weak. A key exchange method may be weak because too 526 few bits are used, or the hashing algorithm is considered too weak. 528 7. IANA Considerations 530 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 531 implemented as being deprecated by this document. 533 8. References 535 8.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 543 Diffie-Hellman groups for Internet Key Exchange (IKE)", 544 RFC 3526, DOI 10.17487/RFC3526, May 2003, 545 . 547 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 548 Protocol Assigned Numbers", RFC 4250, 549 DOI 10.17487/RFC4250, January 2006, 550 . 552 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 553 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 554 January 2006, . 556 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 557 Internet Key Exchange Protocol Version 2 (IKEv2) Key 558 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 566 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 567 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 568 . 570 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 571 Minimum Recommended Diffie-Hellman Modulus Size to 2048 572 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 573 . 575 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 576 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 577 2018, . 579 8.2. Informative References 581 [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell 582 (SSH) Protocol Parameters: Key Exchange Method Names", 583 December 2020, . 586 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 587 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 588 January 2006, . 590 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 591 Group Exchange for the Secure Shell (SSH) Transport Layer 592 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 593 . 595 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 596 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 597 March 2006, . 599 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 600 "Generic Security Service Application Program Interface 601 (GSS-API) Authentication and Key Exchange for the Secure 602 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 603 2006, . 605 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 606 Integration in the Secure Shell Transport Layer", 607 RFC 5656, DOI 10.17487/RFC5656, December 2009, 608 . 610 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 611 Considerations for the SHA-0 and SHA-1 Message-Digest 612 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 613 . 615 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 616 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 617 DOI 10.17487/RFC6234, May 2011, 618 . 620 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 621 Shell (SSH) Key Exchange Method Using Curve25519 and 622 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 623 . 625 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 626 Application Program Interface (GSS-API) Key Exchange with 627 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 628 . 630 [TRANS-COLL] 631 Bhargavan, K. and G. Leurent, "Transcript Collision 632 Attacks: Breaking Authentication in TLS, IKE, and SSH", 633 Network and Distributed System Security Symposium - NDSS 634 2016, Feb 2016, San Diego, United 635 States. 10.14722/ndss.2016.23418 . hal-01244855, 636 . 638 Author's Address 640 Mark D. Baushke 641 Juniper Networks, Inc. 643 Email: mdb@juniper.net