idnits 2.17.1 draft-ietf-curdle-ssh-modp-dh-sha2-09.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 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 15, 2017) is 2413 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) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 1 error (**), 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 15, 2017 5 Intended status: Standards Track 6 Expires: March 19, 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-09 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 19, 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 1. Overview and Rationale 53 Secure Shell (SSH) is a common protocol for secure communication on 54 the Internet. Security protocols and primitives are an active area 55 for research and help to suggest updates to SSH. 57 Section 3 of the [RFC4253] contains a small errata for checking the 58 Peer's DH Public key. Section 4 of this document provides the 59 correction. 61 Due to security concerns with SHA-1 [RFC6194] and with MODP groups 62 with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users 63 request support for larger Diffie Hellman (DH) MODP group sizes with 64 data integrity verification using the SHA-2 family of secure hash 65 algorithms as well as MODP groups providing more security. The use 66 of larger MODP groups and the move to the SHA-2 family of hashes are 67 important features to strengthen the key exchange algorithms 68 available to the SSH client and server. 70 DH primes being adopted by this document are all "safe primes" such 71 that p = 2q + 1 where q is also a prime. New MODP groups are being 72 introduced starting with the MODP 3072-bit group 15. All use SHA512 73 as the hash algorithm. 75 The DH 2048-bit MODP group 14 is already present in most SSH 76 implementations and most implementations already have a SHA256 77 implementation, so diffie-hellman-group14-sha256 is provided as easy 78 to implement. 80 It is intended that these new MODP groups with SHA-2 based hashes 81 update the [RFC4253] section 6.4 and [RFC4250] section 4.10 82 standards. 84 The United States Information Assurance Directorate (IAD) at the 85 National Security Agency (NSA) has published "Commercial National 86 Security Algorithm (CNSA) Suite and Quantum Computing Frequently 87 Asked Questions (FAQ)" [MFQ-U-OO-815099-15] addressed to 88 organizations that run classified or unclassified national security 89 systems (NSS) and vendors that build products used in NSS. 91 This FAQ document indicates that NSS should no longer use: 93 o ECDH and ECDSA with NIST P-256 95 o SHA-256 96 o AES-128 98 o RSA with 2048-bit keys 100 o Diffie-Hellman with 2048-bit keys 102 The FAQ also states that NSS users should select DH groups based upon 103 well established and validated parameter sets that comply with the 104 minimum required sizes. Some specific examples include: 106 o Elliptic Curves are currently restricted to the NIST P-384 group 107 only for both ECDH and ECDSA, in accordance with existing NIST and 108 NIAP standards. 110 o RSA moduli should have a minimum size of 3072 bits (other than the 111 noted PKI exception), and keys should be generated in accordance 112 with all relevant NIST standards. 114 o For Diffie-Hellman use a Diffie-Hellman prime modulus of at least 115 3072 bits as specified in IETF RFC 3526 [RFC3526] (Groups 15-18). 117 Although SSH may not always be used to protect Top Secret 118 communications, this document adopts the use of the DH groups 119 provided as an example in the FAQ as well as the use of SHA512 rather 120 than SHA256 for the new DH groups. 122 [TO BE REMOVED: Please send comments on this draft to 123 curdle@ietf.org.] 125 2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 3. Key Exchange Algorithms 133 This document adds some new Key Exchange Algorithm Method Names in 134 [RFC4253] and [RFC4250]. 136 This document adopts the style and conventions of [RFC4253] in 137 specifying how the use of new data key exchange is indicated in SSH. 139 The following new key exchange method algorithms are defined: 141 o diffie-hellman-group14-sha256 143 o diffie-hellman-group15-sha512 144 o diffie-hellman-group16-sha512 146 o diffie-hellman-group17-sha512 148 o diffie-hellman-group18-sha512 150 The SHA-2 family of secure hash algorithms are defined in [RFC6234]. 152 The method of key exchange used for the name "diffie-hellman- 153 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 154 except that the SHA256 hash algorithm is used. It is recommended 155 that diffie-hellman-group14-sha256 SHOULD be supported to smooth the 156 transition to newer group sizes. 158 The group15 through group18 names are the same as those specified in 159 [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit 160 MODP Group 17, and 8192-bit MODP Group 18. 162 The SHA512 algorithm is to be used when "sha512" is specified as a 163 part of the key exchange method name. 165 4. Checking the Peer's DH Public Key 167 Section 3 of [RFC4253] contains a small errata. When checking e 168 (client public key) and f (server public key) values, an incorrect 169 range is provided. The erroneous text is: 171 Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT 172 be sent or accepted by either side. If this condition is 173 violated, the key exchange fails. 175 The errata is that the range should have been an open interval 176 excluding the end point values. (i.e "(1, p-1)"). This document 177 amends that document text as follows: 179 DH Public key values MUST be checked and both conditions: 181 1 < e < p-1 183 1 < f < p-1 185 MUST be true. Values not within these bounds MUST NOT be sent or 186 accepted by either side. If either one of these condition is 187 violated, then the key exchange fails. 189 This simple check ensures: 191 o The remote peer behaves properly. 193 o The local system is not forced into the two-element subgroup. 195 5. IANA Considerations 197 IANA is requested to add to the Key Exchange Method Names algorithm 198 registry [IANA-KEX] with the following entries: 200 Key Exchange Method Name Reference 201 ----------------------------- ---------- 202 diffie-hellman-group14-sha256 This Draft 203 diffie-hellman-group15-sha512 This Draft 204 diffie-hellman-group16-sha512 This Draft 205 diffie-hellman-group17-sha512 This Draft 206 diffie-hellman-group18-sha512 This Draft 208 [TO BE REMOVED: This registration should take place at the following 209 location: ] 212 6. Acknowledgements 214 Thanks to the following people for review and comments: Denis Bider, 215 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 216 Kouichi, Dave Dugal, Daniel Migault, Anna Johnston, Ron Frederick, 217 Rich Salz, Travis Finkenauer, Eric Rescorla. 219 7. Security Considerations 221 The security considerations of [RFC4253] apply to this document. 223 The security considerations of [RFC3526] suggest that MODP group14 224 through group18 have security strengths that range between 110 bits 225 of security through 310 bits of security. They are based on 226 [RFC3766] Determining Strengths For Public Keys Used For Exchanging 227 Symmetric Keys. Care should be taken to use sufficient entropy and/ 228 or DRBG algorithms to maximize the true security strength of the key 229 exchange and ciphers selected. 231 Using a fixed set of Diffie-Hellman parameters makes them a high 232 value target for pre-computation. Generating additional sets of 233 primes to be used, or moving to larger values is a mitigation against 234 this issue. 236 8. References 237 8.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 245 Diffie-Hellman groups for Internet Key Exchange (IKE)", 246 RFC 3526, DOI 10.17487/RFC3526, May 2003, 247 . 249 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 250 Protocol Assigned Numbers", RFC 4250, 251 DOI 10.17487/RFC4250, January 2006, 252 . 254 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 255 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 256 January 2006, . 258 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 259 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 260 DOI 10.17487/RFC6234, May 2011, 261 . 263 8.2. Informative References 265 [IANA-KEX] 266 Internet Assigned Numbers Authority (IANA), "Secure Shell 267 (SSH) Protocol Parameters: Key Exchange Method Names", 268 March 2017, . 271 [MFQ-U-OO-815099-15] 272 "National Security Agency/Central Security Service", "CNSA 273 Suite and Quantum Computing FAQ", January 2016, 274 . 278 [NIST-SP-800-131Ar1] 279 Barker and Roginsky, "Transitions: Recommendation for the 280 Transitioning of the Use of Cryptographic Algorithms and 281 Key Lengths", NIST Special Publication 800-131A Revision 282 1, November 2015, 283 . 286 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 287 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 288 RFC 3766, DOI 10.17487/RFC3766, April 2004, 289 . 291 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 292 Considerations for the SHA-0 and SHA-1 Message-Digest 293 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 294 . 296 Author's Address 298 Mark D. Baushke 299 Juniper Networks, Inc. 300 1133 Innovation Way 301 Sunnyvale, CA 94089-1228 302 US 304 Phone: +1 408 745 2952 305 Email: mdb@juniper.net 306 URI: http://www.juniper.net/