idnits 2.17.1 draft-ietf-curdle-ssh-modp-dh-sha2-06.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 (June 20, 2017) is 2502 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) June 20, 2017 5 Intended status: Standards Track 6 Expires: December 22, 2017 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-06 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. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 22, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 1. Overview and Rationale 64 Secure Shell (SSH) is a common protocol for secure communication on 65 the Internet. Due to recent security concerns with SHA-1 [RFC6194] 66 and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1] 67 implementer and users request support for larger Diffie Hellman (DH) 68 MODP group sizes with data integrity verification using the SHA-2 69 family of secure hash algorithms as well as MODP groups providing 70 more security. 72 DH primes being adopted by this document are all "safe primes" such 73 that p = 2q + 1 where q is also a prime. New MODP groups are being 74 introduced starting with the MODP 3072-bit group 15 all use SHA512 as 75 the hash algorithm. 77 The DH 2048-bit MODP group 14 is already present in most SSH 78 implementations and most implementations already have a SHA256 79 implementation, so diffie-hellman-group14-sha256 is provided as easy 80 to implement. 82 It is intended that these new MODP groups with SHA-2 based hashes 83 update the [RFC4253] section 6.4 and [RFC4250] section 4.10 84 standards. 86 The United States Information Assurance Directorate (IAD) at the 87 National Security Agency (NSA) has published "Commercial National 88 Security Algorithm (CNSA) Suite and Quantum Computing Frequently 89 Asked Questions (FAQ)" [MFQ-U-OO-815099-15] addressed to 90 organizations that run classified or unclassified national security 91 systems (NSS) and vendors that build products used in NSS. 93 This FAQ document indicates that NSS should no longer use: 95 o ECDH and ECDSA with NIST P-256 97 o SHA-256 98 o AES-128 100 o RSA with 2048-bit keys 102 o Diffie-Hellman with 2048-bit keys 104 The FAQ also states that NSS users should select DH groups based upon 105 well established and validated parameter sets that comply with the 106 minimum required sizes. Some specific examples include: 108 o Elliptic Curves are currently restricted to the NIST P-384 group 109 only for both ECDH and ECDSA, in accordance with existing NIST and 110 NIAP standards. 112 o RSA moduli should have a minimum size of 3072 bits (other than the 113 noted PKI exception), and keys should be generated in accordance 114 with all relevant NIST standards. 116 o For Diffie-Hellman use a Diffie-Hellman prime modulus of at least 117 3072 bits as specified in IETF RFC 3526 [RFC3526] (Groups 15-18). 119 Although SSH may not always be used to protect Top Secret 120 communications, this document adopts the use of the DH groups 121 provided as an example in the FAQ as well as the use of SHA512 rather 122 than SHA256 for the new DH groups. 124 [TO BE REMOVED: Please send comments on this draft to 125 curdle@ietf.org.] 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 3. Key Exchange Algorithms 135 This memo adopts the style and conventions of [RFC4253] in specifying 136 how the use of new data key exchange is indicated in SSH. 138 The following new key exchange algorithms are defined: 140 Key Exchange Method Name 141 diffie-hellman-group14-sha256 142 diffie-hellman-group15-sha512 143 diffie-hellman-group16-sha512 144 diffie-hellman-group17-sha512 145 diffie-hellman-group18-sha512 147 Figure 1 149 The SHA-2 family of secure hash algorithms are defined in [RFC6234]. 151 The method of key exchange used for the name "diffie-hellman- 152 group14-sha256" is the same as that for "diffie-hellman-group14-sha1" 153 except that the SHA256 hash algorithm is used. It is recommended 154 that diffie-hellman-group14-sha256 SHOULD be supported to smooth the 155 transition to newer group sizes. 157 The group15 through group18 names are the same as those specified in 158 [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit 159 MODP Group 17, and 8192-bit MODP Group 18. 161 The SHA512 algorithm is to be used when "sha512" is specified as a 162 part of the key exchange method name. 164 4. IANA Considerations 166 This document augments the Key Exchange Method Names in [RFC4253] and 167 [RFC4250]. 169 IANA is requested to add to the Key Exchange Method Names algorithm 170 registry [IANA-KEX] with the following entries: 172 Key Exchange Method Name Reference 173 ----------------------------- ---------- 174 diffie-hellman-group14-sha256 This Draft 175 diffie-hellman-group15-sha512 This Draft 176 diffie-hellman-group16-sha512 This Draft 177 diffie-hellman-group17-sha512 This Draft 178 diffie-hellman-group18-sha512 This Draft 180 [TO BE REMOVED: This registration should take place at the following 181 location: ] 184 5. Security Considerations 186 The security considerations of [RFC4253] apply to this document. 188 The security considerations of [RFC3526] suggest that MODP group14 189 through group18 have security strengths that range between 110 bits 190 of security through 310 bits of security. They are based on 191 [RFC3766] Determining Strengths For Public Keys Used For Exchanging 192 Symmetric Keys. Care should be taken to use sufficient entropy and/ 193 or DRBG algorithms to maximize the true security strength of the key 194 exchange and ciphers selected. 196 Using a fixed set of Diffie-Hellman parameters makes them a high 197 value target for pre-computation. Generating additional sets of 198 primes to be used, or moving to larger values is a mitigation against 199 this issue. 201 6. References 203 6.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, 207 DOI 10.17487/RFC2119, March 1997, 208 . 210 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 211 Diffie-Hellman groups for Internet Key Exchange (IKE)", 212 RFC 3526, DOI 10.17487/RFC3526, May 2003, 213 . 215 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 216 Protocol Assigned Numbers", RFC 4250, 217 DOI 10.17487/RFC4250, January 2006, 218 . 220 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 221 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 222 January 2006, . 224 6.2. Informative References 226 [IANA-KEX] 227 Internet Assigned Numbers Authority (IANA), "Secure Shell 228 (SSH) Protocol Parameters: Key Exchange Method Names", 229 March 2017, . 232 [MFQ-U-OO-815099-15] 233 "National Security Agency/Central Security Service", "CNSA 234 Suite and Quantum Computing FAQ", January 2016, 235 . 239 [NIST-SP-800-131Ar1] 240 Barker and Roginsky, "Transitions: Recommendation for the 241 Transitioning of the Use of Cryptographic Algorithms and 242 Key Lengths", NIST Special Publication 800-131A Revision 243 1, November 2015, 244 . 247 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 248 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 249 RFC 3766, DOI 10.17487/RFC3766, April 2004, 250 . 252 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 253 Considerations for the SHA-0 and SHA-1 Message-Digest 254 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 255 . 257 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 258 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 259 DOI 10.17487/RFC6234, May 2011, 260 . 262 Author's Address 264 Mark D. Baushke 265 Juniper Networks, Inc. 266 1133 Innovation Way 267 Sunnyvale, CA 94089-1228 268 US 270 Phone: +1 408 745 2952 271 Email: mdb@juniper.net 272 URI: http://www.juniper.net/