idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-01.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], [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 7, 2016) is 2944 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' -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 7, 2016 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 8, 2016 9 Key Exchange Method Updates for Secure Shell (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-01 12 Abstract 14 This document deprecates some previously specified Key Exchange 15 Method algorithm names as well as defining a few added Modular 16 Exponential (MODP) Groups for the Secure Shell (SSH) protocol. It 17 also updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by 18 specifying the set key exchange algorithms that currently exist and 19 which ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key 20 exchange methods use the SHA-2 family of hashes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 8, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Overview and Rationale 56 Secure Shell (SSH) is a common protocol for secure communication on 57 the Internet. In [RFC4253], SSH originally defined the Key Exchange 58 Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley 59 Group 1 (a MODP group with 768 bits) and SHA-1 [RFC3174]. Due to 60 recent security concerns with SHA-1 [RFC6194] and with MODP groups 61 with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users 62 request support for larger MODP group sizes with data integrity 63 verification using the SHA-2 family of secure hash algorithms as well 64 as MODP groups providing more security. 66 The United States Information Assurance Directorate at the National 67 Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting 68 that the use of ECDH using the nistp256 curve and SHA-2 based hashes 69 less than SHA2-384 are no longer sufficient for transport of Top 70 Secret information. It is for this reason that this draft moves 71 ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange 72 method. This is the same reason that the stronger MODP groups being 73 introduced are using SHA2-512 as the hash algorithm. Group14 is 74 already present in most SSH implementations and most implementations 75 already have a SHA2-256 implementation, so diffie-hellman- 76 group14-sha256 is provided as an easy to implement and faster to use 77 key exchange for small embedded applications. 79 It has been observed in [safe-curves] that the NIST recommended 80 Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not 81 the best available for Elliptic Curve Cryptography Security. For 82 this reason, none of the [RFC5656] curves are marked as a MUST 83 implement. However, the requirement that "every compliant SSH ECC 84 implementation MUST implement ECDH key exchange" is now taken to mean 85 that if ecdsa-sha2-[identifier] is implemented, then ecdh- 86 sha2-[identifier] MUST be implemented. 88 Please send comments on this draft to ietf-ssh@NetBSD.org. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Key Exchange Algorithms 98 This memo adopts the style and conventions of [RFC4253] in specifying 99 how the use of new data key exchange is indicated in SSH. 101 The following new key exchange algorithms are defined: 103 Key Exchange Method Name Note 104 diffie-hellman-group14-sha256 MAY/OPTIONAL 105 diffie-hellman-group16-sha512 SHOULD/RECOMMENDED 106 diffie-hellman-group18-sha512 MAY/OPTIONAL 108 Figure 1 110 The SHA-2 family of secure hash algorithms are defined in 111 [FIPS-180-4]. 113 The method of key exchange used for the name "diffie-hellman- 114 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 115 except that the SHA2-256 hash algorithm is used. 117 The group16 and group18 names are the same as those specified in 118 [RFC3526] 4096-bit MODP Group 16 and 8192-bit MODP Group 18. 120 The SHA2-512 algorithm is to be used when "sha512" is specified as a 121 part of the key exchange method name. 123 4. IANA Considerations 125 This document augments the Key Exchange Method Names in [RFC4253]. 126 It downgrades the use of SHA-1 hashing for key exchange methods in 127 [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY 128 the ecdh-sha2-nistp256 given in [RFC5656]. 130 It is desirable to also include the ssh-curves from the 131 [I-D.josefsson-ssh-curves] in this list. The "curve25519-sha256" is 132 currently available in some Secure Shell implementations under the 133 name "curve25519-sha256@libssh.org" and is the best candidate for a 134 fast, safe, and secure key exchange method. 136 IANA is requested to update the SSH algorithm registry with the 137 following entries: 139 Key Exchange Method Name Reference Note 140 diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT 141 diffie-hellman-group-exchange-sha256 RFC4419 MAY 142 diffie-hellman-group1-sha1 RFC4253 SHOULD NOT 143 diffie-hellman-group14-sha1 RFC4253 SHOULD 144 ecdh-sha2-nistp256 RFC5656 MAY 145 ecdh-sha2-nistp384 RFC5656 SHOULD 146 ecdh-sha2-nistp521 RFC5656 SHOULD 147 ecdh-sha2-* RFC5656 MAY 148 ecmqv-sha2 RFC5656 MAY 149 gss-gex-sha1-* RFC4462 SHOULD NOT 150 gss-group1-sha1-* RFC4462 SHOULD NOT 151 gss-group14-sha1-* RFC4462 MAY 152 gss-* RFC4462 MAY 153 rsa1024-sha1 RFC4432 SHOULD NOT 154 rsa2048-sha256 RFC4432 MAY 155 diffie-hellman-group14-sha256 This Draft MAY 156 diffie-hellman-group16-sha512 This Draft SHOULD 157 diffie-hellman-group18-sha512 This Draft MAY 158 curve25519-sha256 ssh-curves MUST 159 curve448-sha512 ssh-curves MAY 161 Figure 2 163 The Note in the above table is an implementation suggestion/ 164 recommendation for the listed key exchange method. It is up to the 165 end-user as to what algorithms they choose to be able to negotiate. 167 The guidance of his document is that the SHA-1 algorithm hashing 168 SHOULD NOT be used. If it is used, it should only be provided for 169 backwards compatibility, should not be used in new designs, and 170 should be phased out of existing key exchanges as quickly as possible 171 because of its known weaknesses. Any key exchange using SHA-1 SHOULD 172 NOT be in a default key exchange list if at all possible. If they 173 are needed for backward compatibility, they SHOULD be listed after 174 all of the SHA-2 based key exchanges. 176 The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be 177 retained for compatibility with older Secure Shell implementations. 178 It is intended that this key exchange be phased out as soon as 179 possible. 181 5. Acknowledgements 183 Thanks to the following people for review and comments: Denis Bider, 184 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 185 Kouichi, Simon Josefsson, Dave Dugal. 187 Thanks to the following people for code to implement interoperable 188 exchanges using some of these groups as found in an the -01 draft: 189 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 190 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 191 and Poderosa implementations also adopting new Diffie-Hellman groups 192 based on the -01 draft. 194 6. Security Considerations 196 The security considerations of [RFC4253] apply to this document. 198 The security considerations of [RFC3526] suggest that these MODP 199 groups have security strengths given in this table. They are based 200 on [RFC3766] Determining Strengths For Public Keys Used For 201 Exchanging Symmetric Keys. 203 Group modulus security strength estimates (RFC3526) 205 +--------+----------+---------------------+---------------------+ 206 | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | 207 | | +----------+----------+----------+----------+ 208 | | | | exponent | | exponent | 209 | | | in bits | size | in bits | size | 210 +--------+----------+----------+----------+----------+----------+ 211 | 14 | 2048-bit | 110 | 220- | 160 | 320- | 212 | 15 | 3072-bit | 130 | 260- | 210 | 420- | 213 | 16 | 4096-bit | 150 | 300- | 240 | 480- | 214 | 17 | 6144-bit | 170 | 340- | 270 | 540- | 215 | 18 | 8192-bit | 190 | 380- | 310 | 620- | 216 +--------+----------+---------------------+---------------------+ 218 Figure 3 220 Many users seem to be interested in the perceived safety of using 221 larger MODP groups and hashing with SHA2-based algorithms. 223 7. References 224 7.1. Normative References 226 [FIPS-180-4] 227 National Institute of Standards and Technology, "Secure 228 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 229 . 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 238 Diffie-Hellman groups for Internet Key Exchange (IKE)", 239 RFC 3526, DOI 10.17487/RFC3526, May 2003, 240 . 242 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 243 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 244 January 2006, . 246 7.2. Informative References 248 [I-D.josefsson-ssh-curves] 249 Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key 250 Exchange Method using Curve25519 and Curve448", draft- 251 josefsson-ssh-curves-04 (work in progress), March 2016. 253 [MFQ-U-OO-815099-15] 254 "National Security Agency/Central Security Service", "CNSA 255 Suite and Quantum Computing FAQ", January 2016, 256 . 260 [NIST-SP-800-131Ar1] 261 Barker, and Roginsky, "Transitions: Recommendation for the 262 Transitioning of the Use of Cryptographic Algorithms and 263 Key Lengths", NIST Special Publication 800-131A Revision 264 1, November 2015, 265 . 268 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 269 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 270 . 272 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 273 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 274 . 276 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 277 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 278 RFC 3766, DOI 10.17487/RFC3766, April 2004, 279 . 281 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 282 Group Exchange for the Secure Shell (SSH) Transport Layer 283 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 284 . 286 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 287 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 288 March 2006, . 290 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 291 "Generic Security Service Application Program Interface 292 (GSS-API) Authentication and Key Exchange for the Secure 293 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 294 2006, . 296 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 297 Integration in the Secure Shell Transport Layer", 298 RFC 5656, DOI 10.17487/RFC5656, December 2009, 299 . 301 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 302 Considerations for the SHA-0 and SHA-1 Message-Digest 303 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 304 . 306 [safe-curves] 307 Bernstein, and Lange, "SafeCurves: choosing safe curves 308 for elliptic-curve cryptography.", February 2016, 309 . 311 Author's Address 312 Mark D. Baushke 313 Juniper Networks, Inc. 314 1133 Innovation Way 315 Sunnyvale, CA 94089-1228 316 US 318 Phone: +1 408 745 2952 319 Email: mdb@juniper.net 320 URI: http://www.juniper.net/