idnits 2.17.00 (12 Aug 2021) /tmp/idnits10213/draft-ietf-curdle-ssh-kex-sha2-04.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]), 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 7, 2016) is 2081 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: draft-ietf-curdle-ssh-curves has been published as RFC 8731 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 1 error (**), 0 flaws (~~), 2 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 7, 2016 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 11, 2017 9 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 10 (SSH) 11 draft-ietf-curdle-ssh-kex-sha2-04 13 Abstract 15 This document adds recommendations for adoption of ssh-curves from 16 the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential 17 (MODP) Groups, and deprecates some previously specified Key Exchange 18 Method algorithm names for the Secure Shell (SSH) protocol. It also 19 updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying 20 the set key exchange algorithms that currently exist and which ones 21 MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange 22 methods use the SHA-2 family of hashes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 11, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Overview and Rationale 58 Secure Shell (SSH) is a common protocol for secure communication on 59 the Internet. In [RFC4253], SSH originally defined the Key Exchange 60 Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley 61 Group 1 (a 768-bit MODP group) and SHA-1 [RFC3174]. Due to recent 62 security concerns with SHA-1 [RFC6194] and with MODP groups with less 63 than 2048 bits [NIST-SP-800-131Ar1] implementer and users request 64 support for larger MODP group sizes with data integrity verification 65 using the SHA-2 family of secure hash algorithms as well as MODP 66 groups providing more security. 68 The United States Information Assurance Directorate (IAD) at the 69 National Security Agency (NSA) has published a FAQ 70 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 71 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 72 less than SHA2-384 are no longer sufficient for transport of Top 73 Secret information. It is for this reason that this draft moves 74 ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange 75 method. This is the same reason that the stronger MODP groups being 76 introduced are using SHA2-512 as the hash algorithm. Group14 is 77 already present in most SSH implementations and most implementations 78 already have a SHA2-256 implementation, so diffie-hellman- 79 group14-sha256 is provided as an easy to implement and faster to use 80 key exchange. Small embedded applications may find this KEX 81 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 five 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 diffie-hellman-group14-sha256 SHOULD/RECOMMENDED 123 diffie-hellman-group15-sha512 MAY/OPTIONAL 124 diffie-hellman-group16-sha512 SHOULD/RECOMMENDED 125 diffie-hellman-group17-sha512 MAY/OPTIONAL 126 diffie-hellman-group18-sha512 MAY/OPTIONAL 128 Figure 1 130 The SHA-2 family of secure hash algorithms are defined in 131 [FIPS-180-4]. 133 The method of key exchange used for the name "diffie-hellman- 134 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 135 except that the SHA2-256 hash algorithm is used. This new method is 136 desirable for interoperability with resource-constrained devices. 138 The group15 through group18 names are the same as those specified in 139 [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit 140 MODP Group 17, and 8192-bit MODP Group 18. All of these groups are 141 within the guidelines for CNSA Suite for Top Secret. 143 The SHA2-512 algorithm is to be used when "sha512" is specified as a 144 part of the key exchange method name. 146 4. IANA Considerations 148 This document augments the Key Exchange Method Names in [RFC4253]. 149 It downgrades the use of SHA-1 hashing for key exchange methods in 150 [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY 151 the ecdh-sha2-nistp256 given in [RFC5656]. 153 It is desirable to also include the ssh-curves from the 154 [I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256" 155 is currently available in some Secure Shell implementations under the 156 name "curve25519-sha256@libssh.org" and is the best candidate for a 157 fast, safe, and secure key exchange method. 159 IANA is requested to update the SSH algorithm registry with the 160 following entries: 162 Key Exchange Method Name Reference Note 163 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 164 diffie-hellman-group-exchange-sha256 RFC4419 MAY 165 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 166 diffie-hellman-group14-sha1 RFC4253 SHOULD 167 ecdh-sha2-nistp256 RFC5656 MAY 168 ecdh-sha2-nistp384 RFC5656 SHOULD 169 ecdh-sha2-nistp521 RFC5656 SHOULD 170 ecdh-sha2-* RFC5656 MAY 171 ecmqv-sha2 RFC5656 MAY 172 gss-gex-sha1-* RFC4462 SHOULD NOT 173 gss-group1-sha1-* RFC4462 SHOULD NOT 174 gss-group14-sha1-* RFC4462 MAY 175 gss-* RFC4462 MAY 176 rsa1024-sha1 RFC4432 SHOULD NOT 177 rsa2048-sha256 RFC4432 MAY 178 diffie-hellman-group14-sha256 This Draft SHOULD 179 diffie-hellman-group15-sha512 This Draft MAY 180 diffie-hellman-group16-sha512 This Draft SHOULD 181 diffie-hellman-group17-sha512 This Draft MAY 182 diffie-hellman-group18-sha512 This Draft MAY 183 curve25519-sha256 ssh-curves MUST 184 curve448-sha512 ssh-curves MAY 186 Figure 2 188 The Note column in the above table is an implementation suggestion/ 189 recommendation for the listed key exchange method. It is up to the 190 end-user as to what algorithms they choose to be able to negotiate. 192 The guidance of his document is that the SHA-1 algorithm hashing 193 SHOULD NOT be used. If it is used, it should only be provided for 194 backwards compatibility, should not be used in new designs, and 195 should be phased out of existing key exchanges as quickly as possible 196 because of its known weaknesses. Any key exchange using SHA-1 SHOULD 197 NOT be in a default key exchange list if at all possible. If they 198 are needed for backward compatibility, they SHOULD be listed after 199 all of the SHA-2 based key exchanges. 201 The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be 202 retained for compatibility with older Secure Shell implementations. 203 It is intended that this key exchange be phased out as soon as 204 possible. 206 5. Acknowledgements 208 Thanks to the following people for review and comments: Denis Bider, 209 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 210 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault. 212 Thanks to the following people for code to implement interoperable 213 exchanges using some of these groups as found in an this draft: 214 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 215 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 216 and Poderosa implementations also adopting new Diffie-Hellman groups 217 based on this draft. 219 6. Security Considerations 221 The security considerations of [RFC4253] apply to this document. 223 The security considerations of [RFC3526] suggest that these MODP 224 groups have security strengths given in this table. They are based 225 on [RFC3766] Determining Strengths For Public Keys Used For 226 Exchanging Symmetric Keys. 228 Group modulus security strength estimates (RFC3526) 230 +--------+----------+---------------------+---------------------+ 231 | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | 232 | | +----------+----------+----------+----------+ 233 | | | | exponent | | exponent | 234 | | | in bits | size | in bits | size | 235 +--------+----------+----------+----------+----------+----------+ 236 | 14 | 2048-bit | 110 | 220- | 160 | 320- | 237 | 15 | 3072-bit | 130 | 260- | 210 | 420- | 238 | 16 | 4096-bit | 150 | 300- | 240 | 480- | 239 | 17 | 6144-bit | 170 | 340- | 270 | 540- | 240 | 18 | 8192-bit | 190 | 380- | 310 | 620- | 241 +--------+----------+---------------------+---------------------+ 243 Figure 3 245 Many users seem to be interested in the perceived safety of using 246 larger MODP groups and hashing with SHA2-based algorithms. 248 7. References 250 7.1. Normative References 252 [FIPS-180-4] 253 National Institute of Standards and Technology, "Secure 254 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 255 . 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", BCP 14, RFC 2119, 260 DOI 10.17487/RFC2119, March 1997, 261 . 263 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 264 Diffie-Hellman groups for Internet Key Exchange (IKE)", 265 RFC 3526, DOI 10.17487/RFC3526, May 2003, 266 . 268 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 269 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 270 January 2006, . 272 7.2. Informative References 274 [CNSA-SUITE] 275 "Information Assurance by the National Security Agency", 276 "Commercial National Security Algorithm Suite", September 277 2016, . 280 [I-D.ietf-curdle-ssh-curves] 281 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 282 Exchange Method using Curve25519 and Curve448", draft- 283 ietf-curdle-ssh-curves-00 (work in progress), March 2016. 285 [MFQ-U-OO-815099-15] 286 "National Security Agency/Central Security Service", "CNSA 287 Suite and Quantum Computing FAQ", January 2016, 288 . 292 [NIST-SP-800-131Ar1] 293 Barker, and Roginsky, "Transitions: Recommendation for the 294 Transitioning of the Use of Cryptographic Algorithms and 295 Key Lengths", NIST Special Publication 800-131A Revision 296 1, November 2015, 297 . 300 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 301 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 302 . 304 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 305 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 306 . 308 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 309 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 310 RFC 3766, DOI 10.17487/RFC3766, April 2004, 311 . 313 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 314 Group Exchange for the Secure Shell (SSH) Transport Layer 315 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 316 . 318 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 319 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 320 March 2006, . 322 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 323 "Generic Security Service Application Program Interface 324 (GSS-API) Authentication and Key Exchange for the Secure 325 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 326 2006, . 328 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 329 Integration in the Secure Shell Transport Layer", 330 RFC 5656, DOI 10.17487/RFC5656, December 2009, 331 . 333 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 334 Considerations for the SHA-0 and SHA-1 Message-Digest 335 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 336 . 338 [safe-curves] 339 Bernstein, and Lange, "SafeCurves: choosing safe curves 340 for elliptic-curve cryptography.", February 2016, 341 . 343 Author's Address 345 Mark D. Baushke 346 Juniper Networks, Inc. 347 1133 Innovation Way 348 Sunnyvale, CA 94089-1228 349 US 351 Phone: +1 408 745 2952 352 Email: mdb@juniper.net 353 URI: http://www.juniper.net/