idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-10.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 (January 2, 2018) is 2277 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) == Outdated reference: A later version (-10) exists of draft-ietf-curdle-gss-keyex-sha2-03 == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Baushke 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 4250 (if approved) January 2, 2018 5 Intended status: Standards Track 6 Expires: July 6, 2018 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-10 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 July 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 56 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 57 3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 59 3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4 60 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 61 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5 62 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 63 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5 64 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 65 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5 66 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6 67 3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 6 68 3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6 69 3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6 70 3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 7 71 3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 7 72 3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 7 73 3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7 74 3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 8 75 3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 8 76 3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 8 77 3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 8 78 3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8 79 3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8 80 3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 9 81 3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 9 82 3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 9 83 3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 9 84 3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 9 85 4. Selecting an appropriate hashing algorithm . . . . . . . . . 9 86 5. Summary Guidance for Key Exchange Method Names . . . . . . . 10 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 9.2. Informative References . . . . . . . . . . . . . . . . . 13 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Overview and Rationale 97 Secure Shell (SSH) is a common protocol for secure communication on 98 the Internet. In [RFC4253], SSH originally defined two Key Exchange 99 Method Names that MUST be implemented. Over time, what was once 100 considered secure, is no longer considered secure. The purpose of 101 this RFC is to recommend that some published key exchanges be 102 deprecated as well as recommending some that SHOULD and one that MUST 103 be adopted. This document updates [RFC4250]. 105 This document adds recommendations for adoption of Key Exchange 106 Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be 107 implemented. New key exchange methods will use the SHA-2 family of 108 hashes found in [RFC6234] and are drawn from these ssh-curves from 109 [I-D.ietf-curdle-ssh-curves] and DH MODP primes from the [RFC8268] 110 and gss-keyex [I-D.ietf-curdle-gss-keyex-sha2]. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. Key Exchange Methods 120 This memo adopts the style and conventions of [RFC4253] in specifying 121 how the use of data key exchange is indicated in SSH. 123 This RFC also collects Key Exchange Method Names in various existing 124 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 125 [RFC8268], [I-D.ietf-curdle-gss-keyex-sha2], and 126 [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for 127 implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any method 128 not explicitly listed, MAY be implemented. 130 This document is intended to provide guidance as to what Key Exchange 131 Algorithms are to be considered for new or updated SSH 132 implementations. This document will be superseded when one or more 133 of the listed algorithms are considered too weak to continue to use 134 securely, in which case they will likely be downgraded to SHOULD NOT 135 or MUST NOT. Or, when newer methods have been analyzed and found to 136 be secure with wide enough adoption to upgrade their recommendation 137 from MAY to SHOULD or MUST. 139 3.1. curve25519-sha256 141 The Curve25519 provides strong security and is efficient on a wide 142 range of architectures with properties that allow better 143 implementation properties compared to traditional elliptic curves. 144 The use of SHA2-256 (also known as SHA-256) as defined in [RFC6234] 145 for integrity is a reasonable one for this method. This Key Exchange 146 Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to 147 the IKEv2 Key Agreement described in [RFC8031]. This Key Exchange 148 Method has multiple implementations and SHOULD be implemented in any 149 SSH interested in using elliptic curve based key exchanges. 151 3.2. curve448-sha512 153 The Curve448 provides very strong security. It uses SHA2-512 (also 154 known as SHA-256) defined in [RFC6234] for integrity. It is probably 155 stronger and more work than is currently needed. This Key Exchange 156 Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to 157 the IKEv2 Key Agreement described in [RFC8031]. This method MAY be 158 implemented. 160 3.3. diffie-hellman-group-exchange-sha1 162 This set of ephemerally generated key exchange groups uses SHA-1 as 163 defined in [RFC4419]. However, SHA-1 has security concerns provided 164 in [RFC6194], so it would be better to use a key exchange method 165 which uses a SHA-2 hash as in [RFC6234] for integrity. This key 166 exchange SHOULD NOT be used. 168 3.4. diffie-hellman-group-exchange-sha256 170 This set of ephemerally generated key exchange groups uses SHA2-256 171 as defined in [RFC4419]. [RFC8270] mandates implementations avoid 172 any MODP group with less than 2048 bits. This key exchange MAY be 173 used. 175 3.5. diffie-hellman-group1-sha1 177 This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group 178 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent 179 security concerns with SHA-1 [RFC6194] and with MODP groups with less 180 than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar1]), this method 181 is considered insecure. This method is being moved from MUST to 182 SHOULD NOT instead of MUST NOT only to allow a transition time to get 183 off of it. There are many old implementations out there that may 184 still need to use this key exchange, it should be removed from server 185 implementations as quickly as possible. 187 3.6. diffie-hellman-group14-sha1 189 This method uses [RFC3526] group14 (a 2048-bit MODP group) which is 190 still a reasonable size. This key exchange group uses SHA-1 which 191 has security concerns [RFC6194]. However, this group is still strong 192 enough and is widely deployed. This method is being moved from MUST 193 to SHOULD to aid in transition to stronger SHA-2 based hashes. This 194 method will transition to SHOULD NOT when SHA-2 alternatives are more 195 generally available. 197 3.7. diffie-hellman-group14-sha256 199 This key exchange method is defined in [RFC8268] and uses the group14 200 (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in 201 [RFC6234] for integrity. This represents the smallest Finite Field 202 Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered 203 to be secure. It is a reasonably simple transition to move from 204 SHA-1 to SHA-2. This method MUST be implemented. 206 3.8. diffie-hellman-group15-sha512 208 This key exchange method is defined in [RFC8268] and uses group15 209 along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 210 Note: The use of this 3072-bit MODP group would be equally justified 211 to use SHA2-384 as the hash rather than SHA2-512. However, some 212 small implementations would rather only worry about two rather than 213 three new hashing functions. This group does not really provide much 214 additional head room over the 2048-bit group14 FFC DH and the 215 predominate open source implementations are not adopting it. This 216 method MAY be implemented. 218 3.9. diffie-hellman-group16-sha512 220 This key exchange method is defined in [RFC8268] and uses group16 221 along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 222 The use of FFC DH is well understood and trusted. Adding larger 223 modulus sizes and protecting with SHA2-512 should give enough head 224 room to be ready for the next scare that someone has pre-computed it. 225 This modulus (4096-bit) is larger than that required by [CNSA-SUITE] 226 and should be sufficient to inter-operate with more paranoid nation- 227 states. This method SHOULD be implemented. 229 3.10. diffie-hellman-group17-sha512 231 This key exchange method is defined in [RFC8268] and uses group17 232 along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 233 The use of this 6144-bit MODP group is going to be slower than what 234 may be desirable. It is provided to help those who wish to avoid 235 using ECC algorithms. This method MAY be implemented. 237 3.11. diffie-hellman-group18-sha512 239 This key exchange method is defined in [RFC8268] and uses group18 240 along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity. 241 The use of this 8192-bit MODP group is going to be slower than what 242 may be desirable. It is provided to help those who wish to avoid 243 using ECC algorithms. This method MAY be implemented. 245 3.12. ecdh-sha2-nistp256 247 This key exchange method is defined in [RFC5656]. Elliptic Curve 248 Diffie-Hellman (ECDH) are often implemented because they are smaller 249 and faster than using large FFC primes with traditional Diffie- 250 Hellman (DH). However, given [CNSA-SUITE] and [safe-curves], this 251 curve may not be as useful and strong as desired for handling TOP 252 SECRET information for some applications. The SSH development 253 community is divided on this and many implementations do exist. If 254 traditional ECDH key exchange methods are implemented, then this 255 method SHOULD be implemented. 257 It is advisable to match the ECDSA and ECDH algorithms to use the 258 same curve for both. 260 3.13. ecdh-sha2-nistp384 262 This key exchange method is defined in [RFC5656]. This ECDH method 263 should be implemented because it is smaller and faster than using 264 large FFC primes with traditional Diffie-Hellman (DH). Given 265 [CNSA-SUITE], it is considered good enough for TOP SECRET. If 266 traditional ECDH key exchange methods are implemented, then this 267 method SHOULD be implemented. 269 Research into ways of breaking ECDSA continues. Papers such as 270 [ECDSA-Nonce-Leak] as well as concerns raised in [safe-curves] may 271 mean that this algorithm will need to be downgraded in the future 272 along the other ECDSA nistp curves. 274 3.14. ecdh-sha2-nistp521 276 This key exchange method is defined in [RFC5656]. This ECDH method 277 may be implemented because it is smaller and faster than using large 278 FFC primes with traditional Diffie-Hellman (DH). It is not listed in 279 [CNSA-SUITE], so it is not currently appropriate for TOP SECRET. It 280 is possible that the mismatch between the 521-bit key and the 512-bit 281 hash could mean that as many as nine bits of this key could be at 282 risk of leaking if appropriate padding measures are not taken. This 283 method MAY be implemented, but is not recommended. 285 3.15. gss-gex-sha1-* 287 This key exchange method is defined in [RFC4462]. This set of 288 ephemerally generated key exchange groups uses SHA-1 which has 289 security concerns [RFC6194]. It is recommended that these key 290 exchange groups NOT be used. This key exchange SHOULD NOT be used. 291 It is intended that it move to MUST NOT as soon as the majority of 292 server implementations no longer offer it. It should be removed from 293 server implementations as quickly as possible. 295 3.16. gss-group1-sha1-* 297 This key exchange method is defined in [RFC4462]. This method 298 suffers from the same problems of diffie-hellman-group1-sha1. It 299 uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1 300 [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and 301 with MODP groups with less than 2048 bits (see [LOGJAM] and 302 [NIST-SP-800-131Ar1]), this method is considered insecure. This 303 method SHOULD NOT be implemented. It is intended that it move to 304 MUST NOT as soon as the majority of server implementations no longer 305 offer it. It should be removed from server implementations as 306 quickly as possible. 308 3.17. gss-group14-sha1-* 310 This key exchange method is defined in [RFC4462]. This generated key 311 exchange groups uses SHA-1 which has security concerns [RFC6194]. If 312 GSS-API key exchange methods are being used, then this one SHOULD be 313 implemented until such time as SHA-2 variants may be implemented and 314 deployed. This method will transition to SHOULD NOT when SHA-2 315 alternatives are more generally available. No other standard 316 indicated that this method was anything other than optional even 317 though it was implemented in all GSS-API systems. This method MAY be 318 implemented. 320 3.18. gss-group14-sha256-* 322 This key exchange method is defined in 323 [I-D.ietf-curdle-gss-keyex-sha2]. This key exchange uses the group14 324 (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash. This 325 represents the smallest Finite Field Cryptography (FFC) Diffie- 326 Hellman (DH) key exchange method considered to be secure. It is a 327 reasonably simple transition to move from SHA-1 to SHA-2. If the 328 GSS-API is to be used, then this method SHOULD be implemented. 330 3.19. gss-group15-sha512-* 332 This key exchange method is defined in 333 [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 3072-bit MODP 334 group does not really provide much additional head room over the 335 2048-bit group14 FFC DH. If the GSS-API is to be used, then this 336 method MAY be implemented. 338 3.20. gss-group16-sha512-* 340 This key exchange method is defined in 341 [I-D.ietf-curdle-gss-keyex-sha2]. The use of FFC DH is well 342 understood and trusted. Adding larger modulus sizes and protecting 343 with SHA2-512 should give enough head room to be ready for the next 344 scare that someone has pre-computed. This modulus (4096-bit) is 345 larger than that required by [CNSA-SUITE] and should be sufficient to 346 inter-operate with more paranoid nation-states. If the GSS-API is to 347 be used, then this method SHOULD be implemented. 349 3.21. gss-group17-sha512-* 351 This key exchange method is defined in 352 [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 6144-bit MODP 353 group is going to be slower than what may be desirable. It is 354 provided to help those who wish to avoid using ECC algorithms. If 355 the GSS-API is to be used, then this method MAY be implemented. 357 3.22. gss-group18-sha512-* 359 This key exchange method is defined in 360 [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 8192-bit MODP 361 group is going to be slower than what may be desirable. It is 362 provided to help those who prefer to avoid using ECC algorithms. If 363 the GSS-API is to be used, then this method MAY be implemented. 365 3.23. gss-nistp256-sha256-* 367 This key exchange method is defined in 368 [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with 369 ECC algorithms, then this method SHOULD be implemented. 371 3.24. gss-nistp384-sha384-* 373 This key exchange method is defined in 374 [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with 375 ECC algorithms, then this method SHOULD be implemented to permit TOP 376 SECRET information to be communicated. 378 3.25. gss-nistp521-sha512-* 380 This key exchange method is defined in 381 [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with 382 ECC algorithms, then this method MAY be implemented. 384 3.26. gss-curve25519-sha256-* 386 This key exchange method is defined in 387 [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with 388 ECC algorithms, then this method SHOULD be implemented. 390 3.27. gss-curve448-sha512-* 392 This key exchange method is defined in 393 [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with 394 ECC algorithms, then this method MAY be implemented. 396 3.28. rsa1024-sha1 398 This key exchange method is defined in [RFC4432]. The security of 399 RSA 1024-bit modulus keys is not good enough any longer. A key size 400 should be 2048-bits. This generated key exchange groups uses SHA-1 401 which has security concerns [RFC6194]. This method MUST NOT be 402 implemented. 404 3.29. rsa2048-sha256 406 This key exchange method is defined in [RFC4432]. An RSA 2048-bit 407 modulus key with a SHA2-256 hash. At the present time, a 2048-bit 408 RSA key is considered to be suffiently strong in [NIST-SP-800-131Ar1] 409 to be permitted. In addition, the use of a SHA-2 hash as defined in 410 [RFC6234] is a good integrity measure. This method MAY be 411 implemented. 413 4. Selecting an appropriate hashing algorithm 415 As may be seen from the above, the Key Exchange Methods area all 416 using either SHA256 or SHA512 with the exception of the ecdh- 417 sha2-nistp384 which uses SHA384. 419 The cited CNSA Suite specifies the use of SHA384 and says that SHA256 420 is no longer good enough for TOP SECRET. Nothing is said about the 421 use of SHA512. It may be that the internal state of 1024 bits in 422 both SHA384 and SHA512 makes the SHA384 more secure because it does 423 not leak an additional 128 bits of state. Of course, the use of 424 SHA384 also reduces the security strength to 384 bits instead of 425 being 512 bits. This seems to contradict the desire to double the 426 symmetric key strength in order to try to be safe from Post Quantum 427 Computing (PQC) attacks given a session key derived from the key 428 exchange will be limited to the security strength of the hash being 429 used. 431 The move away from SHA256 to SHA512 for the newer key exchange 432 methods is more to try to slow Grover's algorithm (a PQC attack) 433 slightly. It is also the case that SHA2-512 may, in many modern 434 CPUs, be implemented more efficiently using 64-bit arithmetic than 435 SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs 436 SHA512 is more about reducing the number of code point alternatives 437 to negotiate. There seemed to be consensus in favor of SHA2-512 over 438 SHA2-384 for key exchanges. 440 5. Summary Guidance for Key Exchange Method Names 442 The Implement column is the current recommendations of this RFC. Key 443 Exchange Method Names are listed alphabetically. 445 Key Exchange Method Name Reference Implement 446 ---------------------------------- ---------- ---------- 447 curve25519-sha256 ssh-curves SHOULD 448 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 449 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 450 diffie-hellman-group14-sha1 RFC4253 SHOULD 451 diffie-hellman-group14-sha256 RFC8268 MUST 452 diffie-hellman-group16-sha512 RFC8268 SHOULD 453 ecdh-sha2-nistp256 RFC5656 SHOULD 454 ecdh-sha2-nistp384 RFC5656 SHOULD 455 gss-gex-sha1-* RFC4462 SHOULD NOT 456 gss-group1-sha1-* RFC4462 SHOULD NOT 457 gss-group14-sha256-* gss-keyex SHOULD 458 gss-group16-sha512-* gss-keyex SHOULD 459 gss-nistp256-sha256-* gss-keyex SHOULD 460 gss-nistp384-sha384-* gss-keyex SHOULD 461 gss-curve25519-sha256-* gss-keyex SHOULD 462 rsa1024-sha1 RFC4432 MUST NOT 464 The full set of official [IANA-KEX] key algorithm method names not 465 otherwise mentioned in this document MAY be implemented. 467 The guidance of this document is that the SHA-1 algorithm hashing 468 SHOULD NOT be used. If it is used in implementations, it should only 469 be provided for backwards compatibility, should not be used in new 470 designs, and should be phased out of existing key exchanges as 471 quickly as possible because of its known weaknesses. Any key 472 exchange using SHA-1 should not be in a default key exchange list if 473 at all possible. If they are needed for backward compatibility, they 474 SHOULD be listed after all of the SHA-2 based key exchanges. 476 The [RFC4253] MUST diffie-hellman-group14-sha1 method SHOULD be 477 retained for compatibility with older Secure Shell implementations. 478 It is intended that this key exchange method be phased out as soon as 479 possible. It SHOULD be listed after all possible SHA-2 based key 480 exchanges. 482 It is believed that all current SSH implementations should be able to 483 achieve an implementation of the "diffie-hellman-group14-sha256" 484 method. To that end, this is one method that MUST be implemented. 486 [TO BE REMOVED: This registration should take place at the following 487 location: ] 490 6. Acknowledgements 492 Thanks to the following people for review and comments: Denis Bider, 493 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 494 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston, 495 and Tero Kivinen. 497 Thanks to the following people for code to implement inter-operable 498 exchanges using some of these groups as found in an this draft: 499 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 500 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 501 and Poderosa implementations also adopting new Diffie-Hellman groups 502 based on this draft. 504 7. Security Considerations 506 This SSH protocol provides a secure encrypted channel over an 507 insecure network. It performs server host authentication, key 508 exchange, encryption, and integrity protection. It also derives a 509 unique session ID that may be used by higher-level protocols. 511 Full security considerations for this protocol are provided in 512 [RFC4251] 514 It is desirable to deprecate or remove key exchange method name that 515 are considered weak. A key exchange method may be weak because too 516 few bits are used, or the hashing algorithm is considered too weak. 518 The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. 519 This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 520 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 522 [RFC6194] and with MODP groups with less than 2048 bits 523 [NIST-SP-800-131Ar1], this method is no longer considered secure. 525 The United States Information Assurance Directorate (IAD) at the 526 National Security Agency (NSA) has published a FAQ 527 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 528 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 529 less than SHA2-384 are no longer sufficient for transport of TOP 530 SECRET information. If your systems need to be concerned with TOP 531 SECRET information, then the guidance for supporting lesser security 532 strength key exchanges may be omitted for your implementations. 534 The MODP group14 is already required for SSH implementations and most 535 implementations already have a SHA2-256 implementation, so diffie- 536 hellman-group14-sha256 is provided as an easy to implement and faster 537 to use key exchange. Small embedded applications may find this KEX 538 desirable to use. 540 The NSA Information Assurance Directorate (IAD) has also published 541 the Commercial National Security Algorithm Suite (CNSA Suite) 542 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is 543 explicitly mentioned as the minimum modulus to protect TOP SECRET 544 communications. 546 It has been observed in [safe-curves] that the NIST Elliptic Curve 547 Prime Curves (P-256, P-384, and P-521) are perhaps not the best 548 available for Elliptic Curve Cryptography (ECC) Security. For this 549 reason, none of the [RFC5656] curves are mandatory to implement. 550 However, the requirement that "every compliant SSH ECC implementation 551 MUST implement ECDH key exchange" is now taken to mean that if ecdsa- 552 sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be 553 implemented. 555 In a Post-Quantum Computing (PQC) world, it will be desirable to use 556 larger cyclic subgroups. To do this using Elliptic Curve 557 Cryptography will require much larger prime base fields, greatly 558 reducing their efficiency. Finite Field based Cryptography already 559 requires large enough base fields to accommodate larger cyclic 560 subgroups. Until such time as a PQC method of key exchange is 561 developed and adopted, it may be desirable to generate new and larger 562 DH groups to avoid pre-calculation attacks that are provably not 563 backdoored. 565 8. IANA Considerations 567 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 568 implemented as being deprecated by this document. 570 9. References 572 9.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 580 Diffie-Hellman groups for Internet Key Exchange (IKE)", 581 RFC 3526, DOI 10.17487/RFC3526, May 2003, 582 . 584 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 585 Protocol Assigned Numbers", RFC 4250, 586 DOI 10.17487/RFC4250, January 2006, 587 . 589 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 590 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 591 January 2006, . 593 [RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the 594 Internet Key Exchange Protocol Version 2 (IKEv2) Key 595 Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016, 596 . 598 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 599 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 600 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 601 . 603 [RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell 604 Minimum Recommended Diffie-Hellman Modulus Size to 2048 605 Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017, 606 . 608 9.2. Informative References 610 [CNSA-SUITE] 611 "Information Assurance by the National Security Agency", 612 "Commercial National Security Algorithm Suite", September 613 2016, . 616 [ECDSA-Nonce-Leak] 617 De Mulder, Hutter, Marson, and Pearson, "Using 618 Bleichenbacher's Solution to the Hidden Number Problem to 619 Attack Nonce Leaks in 384-Bit ECDSA", IACR Cryptology 620 ePrint Archive 2013, August 2013, 621 . 623 [I-D.ietf-curdle-gss-keyex-sha2] 624 Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", 625 draft-ietf-curdle-gss-keyex-sha2-03 (work in progress), 626 December 2017. 628 [I-D.ietf-curdle-ssh-curves] 629 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 630 Shell (SSH) Key Exchange Method using Curve25519 and 631 Curve448", draft-ietf-curdle-ssh-curves-06 (work in 632 progress), November 2017. 634 [IANA-KEX] 635 Internet Assigned Numbers Authority (IANA), "Secure Shell 636 (SSH) Protocol Parameters: Key Exchange Method Names", 637 January 2018, . 640 [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., 641 Green, M., Halderman, J., Heninger, N., Springall, D., 642 Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., 643 Zanella-Beguelin, S., and P. Zimmermann, "Imperfect 644 Forward Secrecy: How Diffie-Hellman Fails in Practice", 645 ACM Conference on Computer and Communications Security 646 (CCS) 2015, 2015, 647 . 649 [MFQ-U-OO-815099-15] 650 "National Security Agency/Central Security Service", "CNSA 651 Suite and Quantum Computing FAQ", January 2016, 652 . 656 [NIST-SP-800-131Ar1] 657 Barker and Roginsky, "Transitions: Recommendation for the 658 Transitioning of the Use of Cryptographic Algorithms and 659 Key Lengths", NIST Special Publication 800-131A Revision 660 1, November 2015, 661 . 664 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 665 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 666 . 668 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 669 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 670 January 2006, . 672 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 673 Group Exchange for the Secure Shell (SSH) Transport Layer 674 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 675 . 677 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 678 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 679 March 2006, . 681 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 682 "Generic Security Service Application Program Interface 683 (GSS-API) Authentication and Key Exchange for the Secure 684 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 685 2006, . 687 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 688 Integration in the Secure Shell Transport Layer", 689 RFC 5656, DOI 10.17487/RFC5656, December 2009, 690 . 692 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 693 Considerations for the SHA-0 and SHA-1 Message-Digest 694 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 695 . 697 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 698 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 699 DOI 10.17487/RFC6234, May 2011, 700 . 702 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 703 Kivinen, "Internet Key Exchange Protocol Version 2 704 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 705 2014, . 707 [safe-curves] 708 Bernstein and Lange, "SafeCurves: choosing safe curves for 709 elliptic-curve cryptography.", February 2016, 710 . 712 Author's Address 714 Mark D. Baushke 715 Juniper Networks, Inc. 716 1133 Innovation Way 717 Sunnyvale, CA 94089-1228 718 US 720 Email: mdb@juniper.net 721 URI: http://www.juniper.net/