idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-07.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([NEWGSSAPI], [IANASSH], [I-D.ietf-curdle-ssh-curves], [RFC4250], [RFC4253], [I-D.ietf-curdle-ssh-modp-dh-sha2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4250, but the abstract doesn't seem to directly say this. It does mention RFC4250 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 (March 27, 2017) is 2580 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 (-12) exists of draft-ietf-curdle-ssh-curves-00 == Outdated reference: A later version (-09) exists of draft-ietf-curdle-ssh-modp-dh-sha2-03 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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, 4253 (if approved) March 27, 2017 5 Intended status: Standards Track 6 Expires: September 28, 2017 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-07 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 RFC updates [RFC4253] 17 MUST algorithms. This RFC also notes that the [IANASSH] has replaced 18 [RFC4250] as the primary reference document for SSH Protocol Assigned 19 Numbers. 21 This document adds recommendations for adoption of Key Exchange 22 Methods which MUST, SHOULD+, SHOULD, SHOULD-, MAY, SHOULD NOT, and 23 MUST NOT be implemented. New key exchange methods will use the SHA-2 24 family of hashes and are drawn from these from 25 [I-D.ietf-curdle-ssh-curves] and new-modp from the 26 [I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex [NEWGSSAPI]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 28, 2017. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 65 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 66 3.2. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 67 3.3. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 68 3.4. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4 69 3.5. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 4 70 3.6. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 4 71 3.7. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5 72 3.8. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 5 73 3.9. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 5 74 3.10. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 5 75 3.11. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 5 76 3.12. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 6 77 3.13. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 6 78 3.14. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Summary Guidance for Key Exchange Method Names . . . . . . . 6 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 84 7.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Overview and Rationale 89 Secure Shell (SSH) is a common protocol for secure communication on 90 the Internet. In [RFC4253], SSH originally defined two Key Exchange 91 Method Names that MUST be implemented. Over time, what was once 92 considered secure, is no longer considered secure. The purpose of 93 this RFC is to recommend that some published key exchanges be adopted 94 or reclassified and others retired. 96 [TO BE REMOVED: Please send comments on this draft to 97 curdle@ietf.org.] 99 2. Requirements Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 When used in the tables in this document, these terms indicate that 106 the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be 107 implemented as part of a Secure Shell implementation. Additional 108 terms used in this document are: 110 SHOULD+ This term means the same as SHOULD. However, it is likely 111 that an algorithm marked as SHOULD+ will be promoted at 112 some future time to be a MUST. 113 SHOULD- This term means the same as SHOULD. However, an algorithm 114 marked as SHOULD- may be deprecated to a MAY in a future 115 version of this document. 117 3. Key Exchange Methods 119 This memo adopts the style and conventions of [RFC4253] in specifying 120 how the use of data key exchange is indicated in SSH. 122 This RFC also collects Key Exchange Method Names in various existing 123 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 124 [I-D.ietf-curdle-ssh-modp-dh-sha2], [NEWGSSAPI], and 125 [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for 126 implementation of MUST, SHOULD+, SHOULD, SHOULD-, SHOULD NOT, and 127 MUST NOT. 129 This document is intended to provide guidance as to what Key Exchange 130 Algorithms are to be considered for new or updated SSH 131 implementations. This document will be superseded when one or more 132 of the listed algorithms are considered too weak to continue to use 133 securely, or when newer methods have been analyzed and found to be 134 secure with wide enough adoption to upgrade their recommendation from 135 MAY to SHOULD or MUST. 137 3.1. curve25519-sha256 139 The Curve25519 provides strong security and is efficient on a wide 140 range of architectures with properties that allow better 141 implementation properties compared to traditional elliptic curves. 142 The use of SHA2-256 for integrity is a reasonable one for this 143 method. This Key Exchange Method has a few implementations and 144 SHOULD+ be implemented in any SSH interested in using elliptic curve 145 based key exchanges. 147 3.2. diffie-hellman-group-exchange-sha1 149 This set of ephemerally generated key exchange groups uses SHA-1 150 which has security concerns [RFC6194]. It is recommended that these 151 key exchange groups NOT be used. This key exchange MUST NOT be 152 implemented. 154 3.3. diffie-hellman-group1-sha1 156 This method uses [RFC2409] Oakley Group 2 (a 1024-bit MODP group) and 157 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 158 [RFC6194] and with MODP groups with less than 2048 bits 159 [NIST-SP-800-131Ar1], this method is considered insecure. This 160 method is being moved from MUST to MUST NOT. 162 3.4. diffie-hellman-group14-sha1 164 This generated key exchange groups uses SHA-1 which has security 165 concerns [RFC6194]. However, this group is still strong enough and 166 is widely deployed. This method is being moved from MUST to SHOULD- 167 to aid in transition to stronger SHA-2 based hashes. This method 168 will transition to MUST NOT when SHA-2 alternatives are more 169 generally available. 171 3.5. diffie-hellman-group14-sha256 173 This generated key exchange uses a 2048-bit sized MODP group along 174 with a SHA-2 (SHA2-256) hash. This represents the smallest Finite 175 Field cryptography Diffie-Hellman key exchange method. It is a 176 reasonably simple transition to move from SHA-1 to SHA-2. This 177 method MUST be implemented. 179 3.6. diffie-hellman-group16-sha512 181 The use of FFC DH is well understood and trusted. Adding larger 182 modulus sizes and protecting with SHA2-512 should give enough head 183 room to be ready for the next scare that someone has pre-computed. 184 This modulus is larger than that required by [CNSA-SUITE] and should 185 be sufficient to inter-operate with more paranoid nation-states. 186 This method SHOULD+ be implemented. 188 3.7. ecdh-sha2-nistp256 190 Elliptic Curve Diffie-Hellman (ECDH) are often implemented because 191 they are smaller and faster than using large FFC primes with 192 traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and 193 [safe-curves], this curve may not be as useful and strong as desired. 194 The SSH development community is divided on this and many 195 implementations do exist. However, there are good implementations of 196 this along with a constant-time SHA2-256 implementation. If an 197 implementer does not have a constant-time SHA2-384 implementation 198 (which helps avoid side-channel attacks), then this is the correct 199 ECDH to implement. This method SHOULD- be implemented. 201 3.8. ecdh-sha2-nistp384 203 This ECDH method should be implemented because it is smaller and 204 faster than using large FFC primes with traditional Diffie-Hellman 205 (DH). Given [CNSA-SUITE], it is considered good enough for TOP 206 SECRET for now. This really needs a constant-time implementation of 207 SHA2-384 to be useful. This method SHOULD+ be implemented. 209 3.9. gss-gex-sha1-* 211 This set of ephemerally generated key exchange groups uses SHA-1 212 which has security concerns [RFC6194]. It is recommended that these 213 key exchange groups NOT be used. This key exchange MUST NOT be 214 implemented. 216 3.10. gss-group1-sha1-* 218 This method suffers from the same problems of diffie-hellman- 219 group1-sha1. It uses [RFC2409] Oakley Group 2 (a 1024-bit MODP 220 group) and SHA-1 [RFC3174]. Due to recent security concerns with 221 SHA-1 [RFC6194] and with MODP groups with less than 2048 bits 222 [NIST-SP-800-131Ar1], this method is considered insecure. This 223 method MUST NOT be implemented. 225 3.11. gss-group14-sha1-* 227 This generated key exchange groups uses SHA-1 which has security 228 concerns [RFC6194]. If GSS-API key exchange methods are being used, 229 then this one SHOULD- be implemented until such time as SHA-2 230 variants may be implemented and deployed. 232 3.12. gss-group14-sha256-* 234 If the GSS-API is to be used, then this method SHOULD be implemented. 236 3.13. gss-group16-sha512-* 238 If the GSS-API is to be used, then this method SHOULD+ be 239 implemented. 241 3.14. rsa1024-sha1 243 The security of RSA 1024-bit modulus keys is not good enough any 244 longer. A minimum bit size should be 2048-bit groups. This 245 generated key exchange groups uses SHA-1 which has security concerns 246 [RFC6194]. This method MUST NOT be implemented. 248 4. Summary Guidance for Key Exchange Method Names 250 The full set of official [IANASSH] key algorithm method names not 251 otherwise mentioned in this RFC MAY be implemented. 253 The Implement column is the current recommendations of this RFC. Key 254 Exchange Method Names are listed alphabetically. 256 Key Exchange Method Name Reference Implement 257 ---------------------------------- ---------- --------- 258 curve25519-sha256 ssh-curves SHOULD+ 259 diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT 260 diffie-hellman-group1-sha1 RFC4253 MUST NOT 261 diffie-hellman-group14-sha1 RFC4253 SHOULD- 262 diffie-hellman-group14-sha256 new-modp MUST 263 diffie-hellman-group16-sha512 new-modp SHOULD+ 264 ecdh-sha2-nistp256 RFC5656 SHOULD- 265 ecdh-sha2-nistp384 RFC5656 SHOULD+ 266 gss-gex-sha1-* RFC4462 MUST NOT 267 gss-group1-sha1-* RFC4462 MUST NOT 268 gss-group14-sha1-* RFC4462 SHOULD- 269 gss-group14-sha256-* gss-keyex SHOULD 270 gss-group16-sha512-* gss-keyex SHOULD+ 271 rsa1024-sha1 RFC4432 MUST NOT 273 The guidance of this RFC is that the SHA-1 algorithm hashing MUST NOT 274 be used. If it is used in implementations, it should only be 275 provided for backwards compatibility, should not be used in new 276 designs, and should be phased out of existing key exchanges as 277 quickly as possible because of its known weaknesses. Any key 278 exchange using SHA-1 MUST NOT be in a default key exchange list if at 279 all possible. If they are needed for backward compatibility, they 280 SHOULD be listed after all of the SHA-2 based key exchanges. 282 The RFC4253 MUST diffie-hellman-group14-sha1 method SHOULD- be 283 retained for compatibility with older Secure Shell implementations. 284 It is intended that this key exchange method be phased out as soon as 285 possible. 287 It is believed that all current SSH implementations should be able to 288 achieve an implementation of the "diffie-hellman-group14-sha256" 289 method. To that end, this is one method that MUST be implemented. 291 [TO BE REMOVED: This registration should take place at the following 292 location: ] 295 5. Acknowledgements 297 Thanks to the following people for review and comments: Denis Bider, 298 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 299 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston. 301 Thanks to the following people for code to implement inter-operable 302 exchanges using some of these groups as found in an this draft: 303 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 304 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 305 and Poderosa implementations also adopting new Diffie-Hellman groups 306 based on this draft. 308 6. Security Considerations 310 The security considerations of [RFC4253] apply to this RFC. 312 It is desirable to deprecate or remove key exchange method name that 313 are considered weak. A key exchange method may be weak because too 314 few bits are used, or the hashing algorithm is considered too weak. 316 The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. 317 This method used [RFC2409] Oakley Group 2 (a 1024-bit MODP group) and 318 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 319 [RFC6194] and with MODP groups with less than 2048 bits 320 [NIST-SP-800-131Ar1], this method is no longer considered secure. 322 The United States Information Assurance Directorate (IAD) at the 323 National Security Agency (NSA) has published a FAQ 324 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 325 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 326 less than SHA2-384 are no longer sufficient for transport of Top 327 Secret information. It is for this reason that this draft moves 328 ecdh-sha2-nistp256 from a MUST to MAY as a key exchange method. This 329 is the same reason that the stronger MODP groups being adopted. As 330 the MODP group14 is already present in most SSH implementations and 331 most implementations already have a SHA2-256 implementation, so 332 diffie-hellman-group14-sha256 is provided as an easy to implement and 333 faster to use key exchange. Small embedded applications may find 334 this KEX desirable to use. 336 The NSA Information Assurance Directorate (IAD) has also published 337 the Commercial National Security Algorithm Suite (CNSA Suite) 338 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is 339 explicitly mentioned as the minimum modulus to protect Top Secret 340 communications. 342 It has been observed in [safe-curves] that the NIST Elliptic Curve 343 Prime Curves (P-256, P-384, and P-521) are perhaps not the best 344 available for Elliptic Curve Cryptography (ECC) Security. For this 345 reason, none of the [RFC5656] curves are mandatory to implement. 346 However, the requirement that "every compliant SSH ECC implementation 347 MUST implement ECDH key exchange" is now taken to mean that if ecdsa- 348 sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be 349 implemented. 351 In a Post-Quantum Computing (PQC) world, it will be desirable to use 352 larger cyclic subgroups. To do this using Elliptic Curve 353 Cryptography will require much larger prime base fields, greatly 354 reducing their efficiency. Finite Field based Cryptography already 355 requires large enough base fields to accommodate larger cyclic 356 subgroups. 358 7. References 360 7.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 368 Diffie-Hellman groups for Internet Key Exchange (IKE)", 369 RFC 3526, DOI 10.17487/RFC3526, May 2003, 370 . 372 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 373 Protocol Assigned Numbers", RFC 4250, 374 DOI 10.17487/RFC4250, January 2006, 375 . 377 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 378 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 379 January 2006, . 381 7.2. Informative References 383 [CNSA-SUITE] 384 "Information Assurance by the National Security Agency", 385 "Commercial National Security Algorithm Suite", September 386 2016, . 389 [I-D.ietf-curdle-ssh-curves] 390 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 391 Exchange Method using Curve25519 and Curve448", draft- 392 ietf-curdle-ssh-curves-00 (work in progress), March 2016. 394 [I-D.ietf-curdle-ssh-modp-dh-sha2] 395 Baushke, M., "More Modular Exponential (MODP) Diffie- 396 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 397 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-03 (work in 398 progress), March 2017. 400 [IANASSH] "Internet Assigned Numbers Authority", "IANA, Secure Shell 401 (SSH) Protocol Parameters", March 2017, 402 . 405 [MFQ-U-OO-815099-15] 406 "National Security Agency/Central Security Service", "CNSA 407 Suite and Quantum Computing FAQ", January 2016, 408 . 412 [NEWGSSAPI] 413 Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", 414 December 2016, . 417 [NIST-SP-800-131Ar1] 418 Barker, and Roginsky, "Transitions: Recommendation for the 419 Transitioning of the Use of Cryptographic Algorithms and 420 Key Lengths", NIST Special Publication 800-131A Revision 421 1, November 2015, 422 . 425 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 426 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 427 . 429 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 430 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 431 . 433 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 434 Group Exchange for the Secure Shell (SSH) Transport Layer 435 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 436 . 438 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 439 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 440 March 2006, . 442 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 443 "Generic Security Service Application Program Interface 444 (GSS-API) Authentication and Key Exchange for the Secure 445 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 446 2006, . 448 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 449 Integration in the Secure Shell Transport Layer", 450 RFC 5656, DOI 10.17487/RFC5656, December 2009, 451 . 453 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 454 Considerations for the SHA-0 and SHA-1 Message-Digest 455 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 456 . 458 [safe-curves] 459 Bernstein, and Lange, "SafeCurves: choosing safe curves 460 for elliptic-curve cryptography.", February 2016, 461 . 463 Author's Address 465 Mark D. Baushke 466 Juniper Networks, Inc. 467 1133 Innovation Way 468 Sunnyvale, CA 94089-1228 469 US 471 Email: mdb@juniper.net 472 URI: http://www.juniper.net/