idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-06.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 abstract seems to contain references ([RFC5656], [RFC4462], [I-D.ietf-curdle-ssh-curves], [RFC4253], [RFC4419], [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 RFC5656, but the abstract doesn't seem to directly say this. It does mention RFC5656 though, so this could be OK. -- The draft header indicates that this document updates RFC4432, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (September 20, 2016) is 2769 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' == 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-00 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 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: 4253, 4419, 4432, 4462, 5656 September 20, 2016 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 24, 2017 9 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 10 (SSH) 11 draft-ietf-curdle-ssh-kex-sha2-06 13 Abstract 15 This document adds recommendations for adoption of ssh-curves from 16 the [I-D.ietf-curdle-ssh-curves] and new-modp from the 17 [I-D.ietf-curdle-ssh-modp-dh-sha2], and deprecates some previously 18 specified Key Exchange Method algorithm names for the Secure Shell 19 (SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and 20 [RFC5656] by specifying the set key exchange algorithms that 21 currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be 22 implemented. New key exchange methods use the SHA-2 family of 23 hashes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 24, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Overview and Rationale 59 Secure Shell (SSH) is a common protocol for secure communication on 60 the Internet. In [RFC4253], SSH originally defined the Key Exchange 61 Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley 62 Group 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent 63 security concerns with SHA-1 [RFC6194] and with MODP groups with less 64 than 2048 bits [NIST-SP-800-131Ar1] implementer and users request 65 support for larger MODP group sizes with data integrity verification 66 using the SHA-2 family of secure hash algorithms as well as MODP 67 groups providing more security. 69 The United States Information Assurance Directorate (IAD) at the 70 National Security Agency (NSA) has published a FAQ 71 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 72 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 73 less than SHA2-384 are no longer sufficient for transport of Top 74 Secret information. It is for this reason that this draft moves 75 ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange 76 method. This is the same reason that the stronger MODP groups being 77 adopted. As the MODP group14 is already present in most SSH 78 implementations and most implementations already have a SHA2-256 79 implementation, so diffie-hellman-group14-sha256 is provided as an 80 easy to implement and faster to use key exchange. Small embedded 81 applications may find this KEX desirable to use. 83 The NSA Information Assurance Directorate (IAD) has also published 84 the Commercial National Security Algorithm Suite (CNSA Suite) 85 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in RFC 3526 is 86 explicitly mentioned as the minimum modulus to protect Top Secret 87 communications. 89 It has been observed in [safe-curves] that the NIST recommended 90 Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not 91 the best available for Elliptic Curve Cryptography (ECC) Security. 92 For this reason, none of the [RFC5656] curves are marked as a MUST 93 implement. However, the requirement that "every compliant SSH ECC 94 implementation MUST implement ECDH key exchange" is now taken to mean 95 that if ecdsa-sha2-[identifier] is implemented, then ecdh- 96 sha2-[identifier] MUST be implemented. 98 Please send comments on this draft to curdle@ietf.org. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Key Exchange Algorithms 108 This memo adopts the style and conventions of [RFC4253] in specifying 109 how the use of new data key exchange is indicated in SSH. 111 A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The 112 curve25519-sha256 MUST be adopted where possible. 114 As a hedge against uncertainty raised by the NSA IAD FAQ publication, 115 new MODP Diffie-Hellman based key exchanges are proposed for 116 inclusion in the set of key exchange method names as well as the 117 curve448-sha512 curve. 119 The following new key exchange algorithms are defined: 121 Key Exchange Method Name Note 122 ----------------------------- ------------------ 123 curve25519-sha256 MUST/REQUIRED 124 curve448-sha512 MAY/OPTIONAL 125 diffie-hellman-group14-sha256 MUST/REQUIRED 126 diffie-hellman-group15-sha512 MAY/OPTIONAL 127 diffie-hellman-group16-sha512 SHOULD/RECOMMENDED 128 diffie-hellman-group17-sha512 MAY/OPTIONAL 129 diffie-hellman-group18-sha512 MAY/OPTIONAL 130 gss-group14-sha256-* SHOULD/RECOMMENDED 131 gss-group15-sha512-* MAY/OPTIONAL 132 gss-group16-sha512-* SHOULD/RECOMMENDED 133 gss-group17-sha512-* MAY/OPTIONAL 134 gss-group18-sha512-* MAY/OPTIONAL 136 The SHA-2 family of secure hash algorithms are defined in 137 [FIPS-180-4]. 139 4. IANA Considerations 141 This RFC augments the Key Exchange Method Names in [RFC4253]. It 142 downgrades the use of SHA-1 hashing for key exchange methods in 143 [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to 144 SHOULD the ecdh-sha2-nistp256 given in [RFC5656]. 146 It adds a new set of named "gss-*" methods to [RFC4462] with a MAY 147 recommendation. 149 It is desirable to also include the new-modp from the 150 [I-D.ietf-curdle-ssh-modp-dh-sha2] in this list. 152 It is desirable to also include the ssh-curves from the 153 [I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256" 154 is currently available in some Secure Shell implementations under the 155 name "curve25519-sha256@libssh.org" and is the best candidate for a 156 fast, safe, and secure key exchange method. 158 IANA is requested to update the SSH algorithm registry to ensure that 159 all of the listed Key Exchange Method Name and References exist in 160 the following table. However, the Implement column is just the 161 current recommendations of this RFC. 163 Key Exchange Method Name Reference Implement 164 ------------------------------------ ---------- ---------- 165 curve25519-sha256 ssh-curves MUST 166 curve448-sha512 ssh-curves MAY 167 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 168 diffie-hellman-group-exchange-sha256 RFC4419 MAY 169 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 170 diffie-hellman-group14-sha1 RFC4253 SHOULD 171 diffie-hellman-group14-sha256 new-modp MUST 172 diffie-hellman-group15-sha512 new-modp MAY 173 diffie-hellman-group16-sha512 new-modp SHOULD 174 diffie-hellman-group17-sha512 new-modp MAY 175 diffie-hellman-group18-sha512 new-modp MAY 176 ecdh-sha2-nistp256 RFC5656 SHOULD 177 ecdh-sha2-nistp384 RFC5656 SHOULD 178 ecdh-sha2-nistp521 RFC5656 SHOULD 179 ecdh-sha2-* RFC5656 MAY 180 ecmqv-sha2 RFC5656 SHOULD NOT 181 gss-gex-sha1-* RFC4462 SHOULD NOT 182 gss-group1-sha1-* RFC4462 SHOULD NOT 183 gss-group14-sha1-* RFC4462 SHOULD 184 gss-group14-sha256-* new-modp SHOULD 185 gss-group15-sha512-* new-modp MAY 186 gss-group16-sha512-* new-modp SHOULD 187 gss-group17-sha512-* new-modp MAY 188 gss-group18-sha512-* new-modp MAY 189 gss-* RFC4462 MAY 190 rsa1024-sha1 RFC4432 SHOULD NOT 191 rsa2048-sha256 RFC4432 MAY 193 The Implement column in the above table is a suggestion/ 194 recommendation for the listed key exchange method to be implemented 195 in the default list of key exchange methods. It is up to the end- 196 user as to what algorithms they choose to be able to negotiate, so 197 the KEX algorithms should be configurable by the administrator of the 198 server as well as the user of the client. This RFC is intended to 199 provide IANA defined names for these groups for interoperability. 200 The Note column of the IANA table should probably continue to point 201 to the implementation detail sections of the Reference RFCs where 202 appropriate. 204 The guidance of his RFC is that the SHA-1 algorithm hashing SHOULD 205 NOT be used. If it is used, it should only be provided for backwards 206 compatibility, should not be used in new designs, and should be 207 phased out of existing key exchanges as quickly as possible because 208 of its known weaknesses. Any key exchange using SHA-1 SHOULD NOT be 209 in a default key exchange list if at all possible. If they are 210 needed for backward compatibility, they SHOULD be listed after all of 211 the SHA-2 based key exchanges. 213 The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be 214 retained for compatibility with older Secure Shell implementations. 215 It is intended that this key exchange method be phased out as soon as 216 possible. 218 It is believed that all current SSH implementations should be able to 219 achieve an implementation of the "diffie-hellman-group14-sha256" 220 method. To that end, this is one method that MUST be implemented. 222 If GSS-API methods are available, then the RFC4462 REQUIRED gss- 223 group14-sha1-* method SHOULD be retained for compatibility with older 224 Secure Shell implementations and the gss-groups14-sha256-* method 225 SHOULD be added as for "sha1". 227 [TO BE REMOVED: This registration should take place at the following 228 location: ] 231 5. Acknowledgements 233 Thanks to the following people for review and comments: Denis Bider, 234 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 235 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault. 237 Thanks to the following people for code to implement interoperable 238 exchanges using some of these groups as found in an this draft: 239 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 240 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 241 and Poderosa implementations also adopting new Diffie-Hellman groups 242 based on this draft. 244 6. Security Considerations 246 The security considerations of [RFC4253] apply to this RFC. 248 The security considerations of [RFC3526] suggest that these MODP 249 groups have security strengths given in this table. They are based 250 on [RFC3766] Determining Strengths For Public Keys Used For 251 Exchanging Symmetric Keys. 253 Group modulus security strength estimates (RFC3526) 255 +--------+----------+---------------------+---------------------+ 256 | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | 257 | | +----------+----------+----------+----------+ 258 | | | | exponent | | exponent | 259 | | | in bits | size | in bits | size | 260 +--------+----------+----------+----------+----------+----------+ 261 | 14 | 2048-bit | 110 | 220- | 160 | 320- | 262 | 15 | 3072-bit | 130 | 260- | 210 | 420- | 263 | 16 | 4096-bit | 150 | 300- | 240 | 480- | 264 | 17 | 6144-bit | 170 | 340- | 270 | 540- | 265 | 18 | 8192-bit | 190 | 380- | 310 | 620- | 266 +--------+----------+---------------------+---------------------+ 268 Figure 1 270 Many users seem to be interested in the perceived safety of using 271 larger MODP groups and hashing with SHA2-based algorithms. 273 7. References 275 7.1. Normative References 277 [FIPS-180-4] 278 National Institute of Standards and Technology, "Secure 279 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 280 . 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 289 Diffie-Hellman groups for Internet Key Exchange (IKE)", 290 RFC 3526, DOI 10.17487/RFC3526, May 2003, 291 . 293 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 294 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 295 January 2006, . 297 7.2. Informative References 299 [CNSA-SUITE] 300 "Information Assurance by the National Security Agency", 301 "Commercial National Security Algorithm Suite", September 302 2016, . 305 [I-D.ietf-curdle-ssh-curves] 306 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 307 Exchange Method using Curve25519 and Curve448", draft- 308 ietf-curdle-ssh-curves-00 (work in progress), March 2016. 310 [I-D.ietf-curdle-ssh-modp-dh-sha2] 311 Baushke, M., "More Modular Exponential (MODP) Diffie- 312 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 313 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-00 (work in 314 progress), September 2016. 316 [MFQ-U-OO-815099-15] 317 "National Security Agency/Central Security Service", "CNSA 318 Suite and Quantum Computing FAQ", January 2016, 319 . 323 [NIST-SP-800-131Ar1] 324 Barker, and Roginsky, "Transitions: Recommendation for the 325 Transitioning of the Use of Cryptographic Algorithms and 326 Key Lengths", NIST Special Publication 800-131A Revision 327 1, November 2015, 328 . 331 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 332 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 333 . 335 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 336 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 337 . 339 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 340 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 341 RFC 3766, DOI 10.17487/RFC3766, April 2004, 342 . 344 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 345 Group Exchange for the Secure Shell (SSH) Transport Layer 346 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 347 . 349 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 350 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 351 March 2006, . 353 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 354 "Generic Security Service Application Program Interface 355 (GSS-API) Authentication and Key Exchange for the Secure 356 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 357 2006, . 359 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 360 Integration in the Secure Shell Transport Layer", 361 RFC 5656, DOI 10.17487/RFC5656, December 2009, 362 . 364 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 365 Considerations for the SHA-0 and SHA-1 Message-Digest 366 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 367 . 369 [safe-curves] 370 Bernstein, and Lange, "SafeCurves: choosing safe curves 371 for elliptic-curve cryptography.", February 2016, 372 . 374 Author's Address 375 Mark D. Baushke 376 Juniper Networks, Inc. 377 1133 Innovation Way 378 Sunnyvale, CA 94089-1228 379 US 381 Phone: +1 408 745 2952 382 Email: mdb@juniper.net 383 URI: http://www.juniper.net/