idnits 2.17.1 draft-ietf-curdle-ssh-modp-dh-sha2-08.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 : ---------------------------------------------------------------------------- No issues found here. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 14, 2017) is 2414 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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) September 14, 2017 5 Intended status: Standards Track 6 Expires: March 18, 2018 8 More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) 9 Groups for Secure Shell (SSH) 10 draft-ietf-curdle-ssh-modp-dh-sha2-08 12 Abstract 14 This document defines added Modular Exponential (MODP) Groups for the 15 Secure Shell (SSH) protocol using SHA-2 hashes. This document 16 updates RFC 4250. This document updates RFC 4253 including an errata 17 fix for checking the Peer's DH Public Key. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 18, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 1. Overview and Rationale 65 Secure Shell (SSH) is a common protocol for secure communication on 66 the Internet. Security protocols and primitives are an active area 67 for research and help to suggest updates to SSH. 69 Section 3 of the [RFC4253] contains a small errata for checking the 70 Peer's DH Public key. Section 4 of this document provides the 71 correction. 73 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 74 with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users 75 request support for larger Diffie Hellman (DH) MODP group sizes with 76 data integrity verification using the SHA-2 family of secure hash 77 algorithms as well as MODP groups providing more security. The use 78 of larger MODP groups and the move to the SHA-2 family of hashes are 79 important features to strengthen the key exchange algorithms 80 available to the SSH client and server. 82 DH primes being adopted by this document are all "safe primes" such 83 that p = 2q + 1 where q is also a prime. New MODP groups are being 84 introduced starting with the MODP 3072-bit group 15. All use SHA512 85 as the hash algorithm. 87 The DH 2048-bit MODP group 14 is already present in most SSH 88 implementations and most implementations already have a SHA256 89 implementation, so diffie-hellman-group14-sha256 is provided as easy 90 to implement. 92 It is intended that these new MODP groups with SHA-2 based hashes 93 update the [RFC4253] section 6.4 and [RFC4250] section 4.10 94 standards. 96 The United States Information Assurance Directorate (IAD) at the 97 National Security Agency (NSA) has published "Commercial National 98 Security Algorithm (CNSA) Suite and Quantum Computing Frequently 99 Asked Questions (FAQ)" [MFQ-U-OO-815099-15] addressed to 100 organizations that run classified or unclassified national security 101 systems (NSS) and vendors that build products used in NSS. 103 This FAQ document indicates that NSS should no longer use: 105 o ECDH and ECDSA with NIST P-256 107 o SHA-256 109 o AES-128 111 o RSA with 2048-bit keys 113 o Diffie-Hellman with 2048-bit keys 115 The FAQ also states that NSS users should select DH groups based upon 116 well established and validated parameter sets that comply with the 117 minimum required sizes. Some specific examples include: 119 o Elliptic Curves are currently restricted to the NIST P-384 group 120 only for both ECDH and ECDSA, in accordance with existing NIST and 121 NIAP standards. 123 o RSA moduli should have a minimum size of 3072 bits (other than the 124 noted PKI exception), and keys should be generated in accordance 125 with all relevant NIST standards. 127 o For Diffie-Hellman use a Diffie-Hellman prime modulus of at least 128 3072 bits as specified in IETF RFC 3526 [RFC3526] (Groups 15-18). 130 Although SSH may not always be used to protect Top Secret 131 communications, this document adopts the use of the DH groups 132 provided as an example in the FAQ as well as the use of SHA512 rather 133 than SHA256 for the new DH groups. 135 [TO BE REMOVED: Please send comments on this draft to 136 curdle@ietf.org.] 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. Key Exchange Algorithms 146 This document adds some new Key Exchange Algorithm Method Names in 147 [RFC4253] and [RFC4250]. 149 This document adopts the style and conventions of [RFC4253] in 150 specifying how the use of new data key exchange is indicated in SSH. 152 The following new key exchange method algorithms are defined: 154 o diffie-hellman-group14-sha256 156 o diffie-hellman-group15-sha512 158 o diffie-hellman-group16-sha512 160 o diffie-hellman-group17-sha512 162 o diffie-hellman-group18-sha512 164 The SHA-2 family of secure hash algorithms are defined in [RFC6234]. 166 The method of key exchange used for the name "diffie-hellman- 167 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 168 except that the SHA256 hash algorithm is used. It is recommended 169 that diffie-hellman-group14-sha256 SHOULD be supported to smooth the 170 transition to newer group sizes. 172 The group15 through group18 names are the same as those specified in 173 [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit 174 MODP Group 17, and 8192-bit MODP Group 18. 176 The SHA512 algorithm is to be used when "sha512" is specified as a 177 part of the key exchange method name. 179 4. Checking the Peer's DH Public Key 181 Section 3 of [RFC4253] contains a small errata. When checking e 182 (client public key) and f (server public key) values, an incorrect 183 range is provided. The erroneous text is: 185 Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT 186 be sent or accepted by either side. If this condition is 187 violated, the key exchange fails. 189 The errata is that the range should have been an open interval 190 excluding the end point values. (i.e "(1, p-1)"). This document 191 amends that document text as follows: 193 DH Public key values MUST be checked and both conditions: 195 1 < e < p-1 197 1 < f < p-1 199 MUST be true. Values not within these bounds MUST NOT be sent or 200 accepted by either side. If either one of these condition is 201 violated, then the key exchange fails. 203 This simple check ensures: 205 o The remote peer behaves properly. 207 o The local system is not forced into the two-element subgroup. 209 5. IANA Considerations 211 IANA is requested to add to the Key Exchange Method Names algorithm 212 registry [IANA-KEX] with the following entries: 214 Key Exchange Method Name Reference 215 ----------------------------- ---------- 216 diffie-hellman-group14-sha256 This Draft 217 diffie-hellman-group15-sha512 This Draft 218 diffie-hellman-group16-sha512 This Draft 219 diffie-hellman-group17-sha512 This Draft 220 diffie-hellman-group18-sha512 This Draft 222 [TO BE REMOVED: This registration should take place at the following 223 location: ] 226 6. Acknowledgements 228 Thanks to the following people for review and comments: Denis Bider, 229 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 230 Kouichi, Dave Dugal, Daniel Migault, Anna Johnston, Ron Frederick, 231 Rich Salz, Travis Finkenauer, Eric Rescorla. 233 7. Security Considerations 235 The security considerations of [RFC4253] apply to this document. 237 The security considerations of [RFC3526] suggest that MODP group14 238 through group18 have security strengths that range between 110 bits 239 of security through 310 bits of security. They are based on 240 [RFC3766] Determining Strengths For Public Keys Used For Exchanging 241 Symmetric Keys. Care should be taken to use sufficient entropy and/ 242 or DRBG algorithms to maximize the true security strength of the key 243 exchange and ciphers selected. 245 Using a fixed set of Diffie-Hellman parameters makes them a high 246 value target for pre-computation. Generating additional sets of 247 primes to be used, or moving to larger values is a mitigation against 248 this issue. 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 260 Diffie-Hellman groups for Internet Key Exchange (IKE)", 261 RFC 3526, DOI 10.17487/RFC3526, May 2003, 262 . 264 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 265 Protocol Assigned Numbers", RFC 4250, 266 DOI 10.17487/RFC4250, January 2006, 267 . 269 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 270 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 271 January 2006, . 273 8.2. Informative References 275 [IANA-KEX] 276 Internet Assigned Numbers Authority (IANA), "Secure Shell 277 (SSH) Protocol Parameters: Key Exchange Method Names", 278 March 2017, . 281 [MFQ-U-OO-815099-15] 282 "National Security Agency/Central Security Service", "CNSA 283 Suite and Quantum Computing FAQ", January 2016, 284 . 288 [NIST-SP-800-131Ar1] 289 Barker and Roginsky, "Transitions: Recommendation for the 290 Transitioning of the Use of Cryptographic Algorithms and 291 Key Lengths", NIST Special Publication 800-131A Revision 292 1, November 2015, 293 . 296 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 297 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 298 RFC 3766, DOI 10.17487/RFC3766, April 2004, 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 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 307 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 308 DOI 10.17487/RFC6234, May 2011, 309 . 311 Author's Address 313 Mark D. Baushke 314 Juniper Networks, Inc. 315 1133 Innovation Way 316 Sunnyvale, CA 94089-1228 317 US 319 Phone: +1 408 745 2952 320 Email: mdb@juniper.net 321 URI: http://www.juniper.net/