idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-12.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 : ---------------------------------------------------------------------------- No issues found here. 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) -- 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 (23 November 2020) is 1222 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 (==), 2 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 (if approved) 23 November 2020 5 Intended status: Standards Track 6 Expires: 27 May 2021 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-12 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. 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 27 May 2021. 36 Copyright Notice 38 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 5 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]. 91 A key exchange has two components, a hashing algorithm and a public 92 key algorithm. The following subsections describe how to select each 93 component. 95 1.1. Selecting an appropriate hashing algorithm 97 The SHA-1 hash is in the process of being deprecated for many 98 reasons. There have been attacks against SHA-1 that have shown there 99 are weaknesses in the algorithm. Therefore, it is desirable to move 100 away from using it before attacks become more serious. 102 At present, the attacks against SHA-1 are collision attacks that rely 103 on human help rather than a pre-image attack. So, it is still 104 possible to allow time backward compatibility use of SHA-1 during a 105 SSH key-exchange for a transition to stronger hashing. However, any 106 such key exchanges should be listed last in the preference list. 108 Use of the SHA-2 family of hashes found in [RFC6234] rather than the 109 SHA-1 hash is strongly advised. 111 When it comes to the SHA-2 family of Secure Hashing functions, 112 SHA2-224 has 112 bits of security strength; SHA2-256 has 128 bits of 113 security strength; SHA2-384 has 192 bits of security strength; and 114 SHA2-512 has 256 bits of security strength. As the same compute 115 power is needed for both SHA2-224 and SHA2-256 and currently no KeX 116 uses SHA2-224, it is suggested that the minimum secure hashing 117 function that should be used for Key Exchange Methods is SHA2-256. 119 To avoid combinatorial explosion of key exchange names, newer key 120 exchanges are restricting to the use of *-sha256 and *-sha512. 122 1.2. Selecting an appropriate Public Key Algorithm 124 SSH uses mathematically hard problems for doing Key Exchange: 126 * Elliptic Curve Cryptography (ECC) has families of curves for Key 127 Exchange Methods for SSH. NIST prime curves with names and other 128 curves are available using an object identifier (OID) with 129 Elliptic Curve Diffie-Hellman (ECDH) via [RFC5656]. Curve25519 130 and Curve448 key exchanges are used with ECDH via [RFC8731]. 132 * Finite Field Cryptography (FFC) is used for Diffie-Hellman (DH) 133 key exchange with "safe primes" either from a specified list found 134 in [RFC3526] or generated dynamically via [RFC4419] as updated by 135 [RFC8270]. 137 * Integer Factorization Cryptography (IFC) using the RSA algorithm 138 is provided for in [RFC4432]. 140 It is desirable for the security strength of the key exchange be 141 chosen to be comparable with the security strength of the other 142 elements of the SSH handshake. Attackers can target the weakest 143 element of the SSH handshake. 145 It is desirable to select a minimum of 112 bits of security strength. 146 Based on implementer security needs, a stronger minimum may be 147 desired. 149 1.2.1. Elliptic Curve Cryptography (ECC) 151 For ECC, it is recommended to select one with approximately 128 bits 152 of security strength. 154 +============+=============================+ 155 | Curve Name | Estimated Security Strength | 156 +============+=============================+ 157 | nistp256 | 128 bits | 158 +------------+-----------------------------+ 159 | nistp384 | 192 bits | 160 +------------+-----------------------------+ 161 | nistp521 | 512 bits | 162 +------------+-----------------------------+ 163 | Curve25519 | 128 bits | 164 +------------+-----------------------------+ 165 | Curve448 | 224 bits | 166 +------------+-----------------------------+ 168 Table 1: ECC Security Strengths 170 1.2.2. Finite Field Cryptography (FFC) 172 For FFC, a modulus 2048 bits (112 bits of security strength). 174 +==================+=============================+============+ 175 | Prime Field Size | Estimated Security Strength | Example | 176 | | | MODP Group | 177 +==================+=============================+============+ 178 | 2048-bit | 112 bits | group14 | 179 +------------------+-----------------------------+------------+ 180 | 3072-bit | 128 bits | group15 | 181 +------------------+-----------------------------+------------+ 182 | 4096-bit | 152 bits | group16 | 183 +------------------+-----------------------------+------------+ 184 | 6144-bit | 176 bits | group17 | 185 +------------------+-----------------------------+------------+ 186 | 8192-bit | 200 bits | group18 | 187 +------------------+-----------------------------+------------+ 189 Table 2: FFC MODP Security Strengths 191 The minimum MODP group that MAY be used is the 2048-bit MODP group14. 192 Implementations SHOULD support a 3072-bit MODP group or larger. 194 1.2.3. Integer Factorization Cryptography (IFC) 196 The only IFC algorithm for key exchange is the RSA algorithm via 197 [RFC4432]. The minimum modulus size is 2048 bits. The use of a 198 SHA-2 Family hash with RSA 2048-bit keys has sufficient security. 200 +=====================+=============================+ 201 | Key Exchange Method | Estimated Security Strength | 202 +=====================+=============================+ 203 | rsa1024-sha1 | 80 bits | 204 +---------------------+-----------------------------+ 205 | rsa2048-sha256 | 112 bits | 206 +---------------------+-----------------------------+ 208 Table 3: IFC Security Strengths 210 2. Requirements Language 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 214 "OPTIONAL" in this document are to be interpreted as described in 215 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 3. Key Exchange Methods 220 This memo adopts the style and conventions of [RFC4253] in specifying 221 how the use of data key exchange is indicated in SSH. 223 This RFC also collects key exchange method names in various existing 224 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 225 [RFC8268], [RFC8731], [RFC8732], and [RFC8308], and provides a 226 suggested suitability for implementation of MUST, SHOULD, SHOULD NOT, 227 and MUST NOT. Any method not explicitly listed MAY be implemented. 229 This document is intended to provide guidance as to what key exchange 230 algorithms are to be considered for new or updated SSH 231 implementations. 233 3.1. SHA-1 and SHA-2 Hashing 235 All of the key exchanges using the SHA-1 hashing algorithm should be 236 deprecated and phased out of use because SHA-1 has security concerns 237 provided in [RFC6194]. The SHA-2 Family of hashes [RFC6234] is the 238 only one which is more secure than SHA-1 and has been standardized 239 for use with SSH key exchanges. 241 diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 are 242 currently mandatory to implement (MTI). diffie-hellman-group14-sha1 243 is the stronger of the two. Group14 (a 2048-bit MODP group) is 244 defined in [RFC3526]. It is reasonable to retain the diffie-hellman- 245 group14-sha1 exchange for interoperability with legacy 246 implementations. Therefore, diffie-hellman-group14-sha1 SHOULD be 247 implemented and all other *-sha1 key exchanges SHOULD NOT be 248 implemented. 250 3.2. Elliptic Curve Cryptography (ECC) 252 3.2.1. curve25519-sha256 and gss-curve25519-sha256-* 254 Curve25519 is efficient on a wide range of architectures with 255 properties that allow higher performance implementations compared to 256 traditional elliptic curves. The use of SHA2-256 (also known as 257 SHA-256 and sha256) as defined in [RFC6234] for integrity is a 258 reasonable one for this method. These key exchange methods are 259 described in [RFC8731] and [RFC8732] and is similar to the IKEv2 Key 260 Agreement described in [RFC8031]. The curve25519-sha256 key exchange 261 method has multiple implementations and SHOULD be implemented. The 262 gss-curve25519-sha256-* key exchange method SHOULD also be 263 implemented because it shares the same performance and security 264 characteristics as curve25519-sha2. 266 3.2.2. curve448-sha512 and gss-curve448-sha512-* 268 Curve448 provides more security strength than Curve25519 at a higher 269 computational and bandwidth cost. It uses SHA2-512 (also known as 270 SHA-512) defined in [RFC6234] for integrity. This Key Exchange 271 Method is described in [RFC8731] and is similar to the IKEv2 Key 272 Agreement described in [RFC8031]. This method MAY be implemented. 273 The gss-curve448-sha512-* key exchange method MAY also be implemented 274 because it shares the same performance and security characteristics 275 as curve448-sha512. 277 3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and gss-nistp* 279 The ecdh-sha2-* name-space allows for other curves to be defined for 280 the elliptic curve Diffie Hellman key exchange. At present, there 281 are three named curves in this name-space which SHOULD be supported. 282 They appear in [RFC5656] in section 10.1 Required Curves all of the 283 NISTP curves named are mandatory to implement if any of this RFC is 284 implemented. This set of methods MAY be implemented. If 285 implemented, the named curves SHOULD always be enabled unless 286 specifically disabled by local security policy. In [RFC5656], 287 section 6.1, the method to name other ECDH curves using OIDs is 288 specified. These other curves MAY be implemented. 290 The GSS-API name-space with gss-nistp*-sha* mirrors the algorithms 291 used by ecdh-sha2-* names. The table provides guidance for 292 implementation. 294 ECDH reduces bandwidth of key exchanges compared to FFC DH at a 295 similar security strength. 297 The following table lists algorithms as SHOULD where implementations 298 may be more efficient or widely deployed. The items listed as MAY 299 are potentially less efficient. 301 +==========================+==========+ 302 | Key Exchange Method Name | Guidance | 303 +==========================+==========+ 304 | ecdh-sha2-* | MAY | 305 +--------------------------+----------+ 306 | ecdh-sha2-nistp256 | SHOULD | 307 +--------------------------+----------+ 308 | gss-nistp256-sha256-* | SHOULD | 309 +--------------------------+----------+ 310 | ecdh-sha2-nistp384 | SHOULD | 311 +--------------------------+----------+ 312 | gss-nistp384-sha384-* | SHOULD | 313 +--------------------------+----------+ 314 | ecdh-sha2-nistp521 | SHOULD | 315 +--------------------------+----------+ 316 | gss-nistp521-sha512-* | SHOULD | 317 +--------------------------+----------+ 318 | ecmqv-sha2 | MAY | 319 +--------------------------+----------+ 321 Table 4: ECDH Implementation Guidance 323 It is advisable to match the ECDSA and ECDH algorithms to use the 324 same curve for both to maintain the same security strength in the 325 connection. 327 3.3. Finite Field Cryptography (FFC) 329 3.3.1. FFC diffie-hellman using generated MODP groups 331 This random selection from a set of pre-generated moduli for key 332 exchange uses SHA2-256 as defined in [RFC4419]. [RFC8270] mandates 333 implementations avoid any MODP group whose modulus size is less than 334 2048 bits. Care should be taken in the pre-generation of the moduli 335 P and generator G such that the generator provides a Q-ordered 336 subgroup of P. Otherwise, the parameter set may leak one bit of the 337 shared secret leaving the MODP group half as strong. This key 338 exchange MAY be used. 340 3.3.2. FFC diffie-hellman using named MODP groups 342 diffie-hellman-group14-sha256 represents the smallest FFC DH key 343 exchange method considered to be secure. It is a reasonably simple 344 transition from SHA-1 to SHA-2. diffie-hellman-group14-sha256 method 345 MUST be implemented. The rest of the FFC MODP groups MAY be 346 implemented. The table below provides explicit guidance by name. 348 +===============================+==========+ 349 | Key Exchange Method Name | Guidance | 350 +===============================+==========+ 351 | diffie-hellman-group14-sha256 | MUST | 352 +-------------------------------+----------+ 353 | gss-group14-sha256-* | SHOULD | 354 +-------------------------------+----------+ 355 | diffie-hellman-group15-sha512 | MAY | 356 +-------------------------------+----------+ 357 | gss-group15-sha512-* | MAY | 358 +-------------------------------+----------+ 359 | diffie-hellman-group16-sha512 | SHOULD | 360 +-------------------------------+----------+ 361 | gss-group16-sha512-* | MAY | 362 +-------------------------------+----------+ 363 | diffie-hellman-group17-sha512 | MAY | 364 +-------------------------------+----------+ 365 | gss-group17-sha512-* | MAY | 366 +-------------------------------+----------+ 367 | diffie-hellman-group18-sha512 | MAY | 368 +-------------------------------+----------+ 369 | gss-group18-sha512-* | MAY | 370 +-------------------------------+----------+ 372 Table 5: FFC Implementation Guidance 374 3.4. Integer Factorization Cryptography (IFC) 376 The rsa2048-sha256 key exchange method is defined in [RFC4432]. Uses 377 an RSA 2048-bit modulus with a SHA2-256 hash. This key exchange 378 meets 112 bit minimum security strength. This method MAY be 379 implemented. 381 3.5. Secure Shell Extension Negotiation 383 There are two key exchange methods, ext-info-c and ext-info-s, 384 defined in [RFC8308] which are not actually key exchanges. They 385 provide a method to support other Secure Shell negotiations. Being 386 able to extend functionality is desirable. This method SHOULD be 387 implemented. 389 4. Summary Guidance for Key Exchange Method Names Implementations 391 The Implement column is the current recommendations of this RFC. Key 392 Exchange Method Names are listed alphabetically. 394 +======================================+===========+============+ 395 | Key Exchange Method Name | Reference | Implement | 396 +======================================+===========+============+ 397 | curve25519-sha256 | RFC8731 | SHOULD | 398 +--------------------------------------+-----------+------------+ 399 | curve448-sha512 | RFC8731 | MAY | 400 +--------------------------------------+-----------+------------+ 401 | diffie-hellman-group-exchange-sha1 | RFC4419 | SHOULD NOT | 402 +--------------------------------------+-----------+------------+ 403 | diffie-hellman-group-exchange-sha256 | RFC4419 | MAY | 404 +--------------------------------------+-----------+------------+ 405 | diffie-hellman-group1-sha1 | RFC4253 | SHOULD NOT | 406 +--------------------------------------+-----------+------------+ 407 | diffie-hellman-group14-sha1 | RFC4253 | SHOULD | 408 +--------------------------------------+-----------+------------+ 409 | diffie-hellman-group14-sha256 | RFC8268 | MUST | 410 +--------------------------------------+-----------+------------+ 411 | diffie-hellman-group15-sha512 | RFC8268 | MAY | 412 +--------------------------------------+-----------+------------+ 413 | diffie-hellman-group16-sha512 | RFC8268 | SHOULD | 414 +--------------------------------------+-----------+------------+ 415 | diffie-hellman-group17-sha512 | RFC8268 | MAY | 416 +--------------------------------------+-----------+------------+ 417 | diffie-hellman-group18-sha512 | RFC8268 | MAY | 418 +--------------------------------------+-----------+------------+ 419 | ecdh-sha2-* | RFC5656 | MAY | 420 +--------------------------------------+-----------+------------+ 421 | ecdh-sha2-nistp256 | RFC5656 | SHOULD | 422 +--------------------------------------+-----------+------------+ 423 | ecdh-sha2-nistp384 | RFC5656 | SHOULD | 424 +--------------------------------------+-----------+------------+ 425 | ecdh-sha2-nistp521 | RFC5656 | SHOULD | 426 +--------------------------------------+-----------+------------+ 427 | ecmqv-sha2 | RFC5656 | MAY | 428 +--------------------------------------+-----------+------------+ 429 | ext-info-c | RFC8308 | SHOULD | 430 +--------------------------------------+-----------+------------+ 431 | ext-info-s | RFC8308 | SHOULD | 432 +--------------------------------------+-----------+------------+ 433 | gss-* | RFC4462 | MAY | 434 +--------------------------------------+-----------+------------+ 435 | gss-curve25519-sha256-* | RFC8732 | SHOULD | 436 +--------------------------------------+-----------+------------+ 437 | gss-curve448-sha512-* | RFC8732 | MAY | 438 +--------------------------------------+-----------+------------+ 439 | gss-gex-sha1-* | RFC4462 | SHOULD NOT | 440 +--------------------------------------+-----------+------------+ 441 | gss-group1-sha1-* | RFC4462 | SHOULD NOT | 442 +--------------------------------------+-----------+------------+ 443 | gss-group14-sha256-* | RFC8732 | SHOULD | 444 +--------------------------------------+-----------+------------+ 445 | gss-group15-sha512-* | RFC8732 | MAY | 446 +--------------------------------------+-----------+------------+ 447 | gss-group16-sha512-* | RFC8732 | SHOULD | 448 +--------------------------------------+-----------+------------+ 449 | gss-group17-sha512-* | RFC8732 | MAY | 450 +--------------------------------------+-----------+------------+ 451 | gss-group18-sha512-* | RFC8732 | MAY | 452 +--------------------------------------+-----------+------------+ 453 | gss-nistp256-sha256-* | RFC8732 | SHOULD | 454 +--------------------------------------+-----------+------------+ 455 | gss-nistp384-sha384-* | RFC8732 | SHOULD | 456 +--------------------------------------+-----------+------------+ 457 | gss-nistp521-sha512-* | RFC8732 | MAY | 458 +--------------------------------------+-----------+------------+ 459 | rsa1024-sha1 | RFC4432 | MUST NOT | 460 +--------------------------------------+-----------+------------+ 461 | rsa2048-sha256 | RFC4432 | MAY | 462 +--------------------------------------+-----------+------------+ 464 Table 6: IANA guidance for key exchange method name 465 implementations 467 The full set of official [IANA-KEX] key algorithm method names not 468 otherwise mentioned in this document MAY be implemented. 470 [TO BE REMOVED: This registration should take place at the following 471 location URL: http://www.iana.org/assignments/ssh-parameters/ssh- 472 parameters.xhtml#ssh-parameters-16 ] 474 5. Acknowledgements 476 Thanks to the following people for review and comments: Denis Bider, 477 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 478 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 479 Tero Kivinen, and Travis Finkenauer. 481 Thanks to the following people for code to implement interoperable 482 exchanges using some of these groups as found in an this draft: 483 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 484 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 485 and Poderosa implementations also adopting new Diffie-Hellman groups 486 based on this draft. 488 6. Security Considerations 490 This SSH protocol provides a secure encrypted channel over an 491 insecure network. It performs server host authentication, key 492 exchange, encryption, and integrity checks. It also derives a unique 493 session ID that may be used by higher-level protocols. 495 Full security considerations for this protocol are provided in 496 [RFC4251]. 498 It is desirable to deprecate or remove key exchange method name that 499 are considered weak. A key exchange method may be weak because too 500 few bits are used, or the hashing algorithm is considered too weak. 502 7. IANA Considerations 504 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 505 implemented as being deprecated by this document. 507 8. References 509 8.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, 513 DOI 10.17487/RFC2119, March 1997, 514 . 516 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 517 Diffie-Hellman groups for Internet Key Exchange (IKE)", 518 RFC 3526, DOI 10.17487/RFC3526, May 2003, 519 . 521 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 522 Protocol Assigned Numbers", RFC 4250, 523 DOI 10.17487/RFC4250, January 2006, 524 . 526 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 527 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 528 January 2006, . 530 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 531 Internet Key Exchange Protocol Version 2 (IKEv2) Key 532 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 533 . 535 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 536 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 537 May 2017, . 539 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 540 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 541 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 542 . 544 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 545 Minimum Recommended Diffie-Hellman Modulus Size to 2048 546 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 547 . 549 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 550 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 551 2018, . 553 8.2. Informative References 555 [IANA-KEX] Internet Assigned Numbers Authority (IANA), "Secure Shell 556 (SSH) Protocol Parameters: Key Exchange Method Names", 557 July 2020, . 560 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 561 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 562 January 2006, . 564 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 565 Group Exchange for the Secure Shell (SSH) Transport Layer 566 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 567 . 569 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 570 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 571 March 2006, . 573 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 574 "Generic Security Service Application Program Interface 575 (GSS-API) Authentication and Key Exchange for the Secure 576 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 577 2006, . 579 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 580 Integration in the Secure Shell Transport Layer", 581 RFC 5656, DOI 10.17487/RFC5656, December 2009, 582 . 584 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 585 Considerations for the SHA-0 and SHA-1 Message-Digest 586 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 587 . 589 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 590 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 591 DOI 10.17487/RFC6234, May 2011, 592 . 594 [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 595 Shell (SSH) Key Exchange Method Using Curve25519 and 596 Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020, 597 . 599 [RFC8732] Sorce, S. and H. Kario, "Generic Security Service 600 Application Program Interface (GSS-API) Key Exchange with 601 SHA-2", RFC 8732, DOI 10.17487/RFC8732, February 2020, 602 . 604 Author's Address 606 Mark D. Baushke 607 Juniper Networks, Inc. 609 Email: mdb@juniper.net