idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-03.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 (March 14, 2016) is 2964 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 -- 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 March 14, 2016 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 15, 2016 9 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 10 (SSH) 11 draft-ietf-curdle-ssh-kex-sha2-03 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 September 15, 2016. 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 MODP group with 768 bits) and SHA-1 [RFC3174]. Due to 62 recent security concerns with SHA-1 [RFC6194] and with MODP groups 63 with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users 64 request support for larger MODP group sizes with data integrity 65 verification using the SHA-2 family of secure hash algorithms as well 66 as MODP 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 for small embedded applications. 82 It has been observed in [safe-curves] that the NIST recommended 83 Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not 84 the best available for Elliptic Curve Cryptography (ECC) Security. 85 For this reason, none of the [RFC5656] curves are marked as a MUST 86 implement. However, the requirement that "every compliant SSH ECC 87 implementation MUST implement ECDH key exchange" is now taken to mean 88 that if ecdsa-sha2-[identifier] is implemented, then ecdh- 89 sha2-[identifier] MUST be implemented. 91 Please send comments on this draft to curdle@ietf.org. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Key Exchange Algorithms 101 This memo adopts the style and conventions of [RFC4253] in specifying 102 how the use of new data key exchange is indicated in SSH. 104 A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The 105 curve25519-sha256 MUST be adopted where possible. 107 As a hedge against uncertainty raised by the NSA IAD FAQ publication, 108 three new MODP Diffie-Hellman based key exchanges are proposed for 109 inclusion in the set of key exchange method names as well as the 110 curve448-sha512 curve. 112 The following new key exchange algorithms are defined: 114 Key Exchange Method Name Note 115 diffie-hellman-group14-sha256 MAY/OPTIONAL 116 diffie-hellman-group16-sha512 SHOULD/RECOMMENDED 117 diffie-hellman-group18-sha512 MAY/OPTIONAL 119 Figure 1 121 The SHA-2 family of secure hash algorithms are defined in 122 [FIPS-180-4]. 124 The method of key exchange used for the name "diffie-hellman- 125 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 126 except that the SHA2-256 hash algorithm is used. 128 The group16 and group18 names are the same as those specified in 129 [RFC3526] 4096-bit MODP Group 16 and 8192-bit MODP Group 18. 131 The SHA2-512 algorithm is to be used when "sha512" is specified as a 132 part of the key exchange method name. 134 4. IANA Considerations 136 This document augments the Key Exchange Method Names in [RFC4253]. 137 It downgrades the use of SHA-1 hashing for key exchange methods in 138 [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY 139 the ecdh-sha2-nistp256 given in [RFC5656]. 141 It is desirable to also include the ssh-curves from the 142 [I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256" 143 is currently available in some Secure Shell implementations under the 144 name "curve25519-sha256@libssh.org" and is the best candidate for a 145 fast, safe, and secure key exchange method. 147 IANA is requested to update the SSH algorithm registry with the 148 following entries: 150 Key Exchange Method Name Reference Note 151 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 152 diffie-hellman-group-exchange-sha256 RFC4419 MAY 153 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 154 diffie-hellman-group14-sha1 RFC4253 SHOULD 155 ecdh-sha2-nistp256 RFC5656 MAY 156 ecdh-sha2-nistp384 RFC5656 SHOULD 157 ecdh-sha2-nistp521 RFC5656 SHOULD 158 ecdh-sha2-* RFC5656 MAY 159 ecmqv-sha2 RFC5656 MAY 160 gss-gex-sha1-* RFC4462 SHOULD NOT 161 gss-group1-sha1-* RFC4462 SHOULD NOT 162 gss-group14-sha1-* RFC4462 MAY 163 gss-* RFC4462 MAY 164 rsa1024-sha1 RFC4432 SHOULD NOT 165 rsa2048-sha256 RFC4432 MAY 166 diffie-hellman-group14-sha256 This Draft MAY 167 diffie-hellman-group16-sha512 This Draft SHOULD 168 diffie-hellman-group18-sha512 This Draft MAY 169 curve25519-sha256 ssh-curves MUST 170 curve448-sha512 ssh-curves MAY 172 Figure 2 174 The Note in the above table is an implementation suggestion/ 175 recommendation for the listed key exchange method. It is up to the 176 end-user as to what algorithms they choose to be able to negotiate. 178 The guidance of his document is that the SHA-1 algorithm hashing 179 SHOULD NOT be used. If it is used, it should only be provided for 180 backwards compatibility, should not be used in new designs, and 181 should be phased out of existing key exchanges as quickly as possible 182 because of its known weaknesses. Any key exchange using SHA-1 SHOULD 183 NOT be in a default key exchange list if at all possible. If they 184 are needed for backward compatibility, they SHOULD be listed after 185 all of the SHA-2 based key exchanges. 187 The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be 188 retained for compatibility with older Secure Shell implementations. 190 It is intended that this key exchange be phased out as soon as 191 possible. 193 5. Acknowledgements 195 Thanks to the following people for review and comments: Denis Bider, 196 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 197 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault. 199 Thanks to the following people for code to implement interoperable 200 exchanges using some of these groups as found in an this draft: 201 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 202 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 203 and Poderosa implementations also adopting new Diffie-Hellman groups 204 based on this draft. 206 6. Security Considerations 208 The security considerations of [RFC4253] apply to this document. 210 The security considerations of [RFC3526] suggest that these MODP 211 groups have security strengths given in this table. They are based 212 on [RFC3766] Determining Strengths For Public Keys Used For 213 Exchanging Symmetric Keys. 215 Group modulus security strength estimates (RFC3526) 217 +--------+----------+---------------------+---------------------+ 218 | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | 219 | | +----------+----------+----------+----------+ 220 | | | | exponent | | exponent | 221 | | | in bits | size | in bits | size | 222 +--------+----------+----------+----------+----------+----------+ 223 | 14 | 2048-bit | 110 | 220- | 160 | 320- | 224 | 15 | 3072-bit | 130 | 260- | 210 | 420- | 225 | 16 | 4096-bit | 150 | 300- | 240 | 480- | 226 | 17 | 6144-bit | 170 | 340- | 270 | 540- | 227 | 18 | 8192-bit | 190 | 380- | 310 | 620- | 228 +--------+----------+---------------------+---------------------+ 230 Figure 3 232 Many users seem to be interested in the perceived safety of using 233 larger MODP groups and hashing with SHA2-based algorithms. 235 7. References 237 7.1. Normative References 239 [FIPS-180-4] 240 National Institute of Standards and Technology, "Secure 241 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 242 . 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 251 Diffie-Hellman groups for Internet Key Exchange (IKE)", 252 RFC 3526, DOI 10.17487/RFC3526, May 2003, 253 . 255 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 256 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 257 January 2006, . 259 7.2. Informative References 261 [I-D.ietf-curdle-ssh-curves] 262 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 263 Exchange Method using Curve25519 and Curve448", draft- 264 ietf-curdle-ssh-curves-00 (work in progress), March 2016. 266 [MFQ-U-OO-815099-15] 267 "National Security Agency/Central Security Service", "CNSA 268 Suite and Quantum Computing FAQ", January 2016, 269 . 273 [NIST-SP-800-131Ar1] 274 Barker, and Roginsky, "Transitions: Recommendation for the 275 Transitioning of the Use of Cryptographic Algorithms and 276 Key Lengths", NIST Special Publication 800-131A Revision 277 1, November 2015, 278 . 281 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 282 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 283 . 285 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 286 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 287 . 289 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 290 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 291 RFC 3766, DOI 10.17487/RFC3766, April 2004, 292 . 294 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 295 Group Exchange for the Secure Shell (SSH) Transport Layer 296 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 297 . 299 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 300 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 301 March 2006, . 303 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 304 "Generic Security Service Application Program Interface 305 (GSS-API) Authentication and Key Exchange for the Secure 306 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 307 2006, . 309 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 310 Integration in the Secure Shell Transport Layer", 311 RFC 5656, DOI 10.17487/RFC5656, December 2009, 312 . 314 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 315 Considerations for the SHA-0 and SHA-1 Message-Digest 316 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 317 . 319 [safe-curves] 320 Bernstein, and Lange, "SafeCurves: choosing safe curves 321 for elliptic-curve cryptography.", February 2016, 322 . 324 Author's Address 325 Mark D. Baushke 326 Juniper Networks, Inc. 327 1133 Innovation Way 328 Sunnyvale, CA 94089-1228 329 US 331 Phone: +1 408 745 2952 332 Email: mdb@juniper.net 333 URI: http://www.juniper.net/