Internet Engineering Task Force M. Baushke Internet-Draft Juniper Networks, Inc. Updates: 4253, 4419, 4432, 4462, 5656 September 7, 2016 (if approved) Intended status: Standards Track Expires: March 11, 2017 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-04 Abstract This document adds recommendations for adoption of ssh-curves from the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential (MODP) Groups, and deprecates some previously specified Key Exchange Method algorithm names for the Secure Shell (SSH) protocol. It also updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying the set key exchange algorithms that currently exist and which ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange methods use the SHA-2 family of hashes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 11, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Baushke Expires March 11, 2017 [Page 1] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Overview and Rationale Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4253], SSH originally defined the Key Exchange Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley Group 1 (a 768-bit MODP group) and SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and with MODP groups with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users request support for larger MODP group sizes with data integrity verification using the SHA-2 family of secure hash algorithms as well as MODP groups providing more security. The United States Information Assurance Directorate (IAD) at the National Security Agency (NSA) has published a FAQ [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes less than SHA2-384 are no longer sufficient for transport of Top Secret information. It is for this reason that this draft moves ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange method. This is the same reason that the stronger MODP groups being introduced are using SHA2-512 as the hash algorithm. Group14 is already present in most SSH implementations and most implementations already have a SHA2-256 implementation, so diffie-hellman- group14-sha256 is provided as an easy to implement and faster to use key exchange. Small embedded applications may find this KEX desirable to use. The NSA Information Assurance Directorate (IAD) has also published the Commercial National Security Algorithm Suite (CNSA Suite) [CNSA-SUITE] in which the 3072-bit MODP Group 15 in RFC 3526 is explicitly mentioned as the minimum modulus to protect Top Secret communications. It has been observed in [safe-curves] that the NIST recommended Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not the best available for Elliptic Curve Cryptography (ECC) Security. For this reason, none of the [RFC5656] curves are marked as a MUST implement. However, the requirement that "every compliant SSH ECC implementation MUST implement ECDH key exchange" is now taken to mean that if ecdsa-sha2-[identifier] is implemented, then ecdh- sha2-[identifier] MUST be implemented. Baushke Expires March 11, 2017 [Page 2] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 Please send comments on this draft to curdle@ietf.org. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Key Exchange Algorithms This memo adopts the style and conventions of [RFC4253] in specifying how the use of new data key exchange is indicated in SSH. A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The curve25519-sha256 MUST be adopted where possible. As a hedge against uncertainty raised by the NSA IAD FAQ publication, five new MODP Diffie-Hellman based key exchanges are proposed for inclusion in the set of key exchange method names as well as the curve448-sha512 curve. The following new key exchange algorithms are defined: Key Exchange Method Name Note diffie-hellman-group14-sha256 SHOULD/RECOMMENDED diffie-hellman-group15-sha512 MAY/OPTIONAL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group17-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL Figure 1 The SHA-2 family of secure hash algorithms are defined in [FIPS-180-4]. The method of key exchange used for the name "diffie-hellman- group14-sha256" is the same as that for "diffie-hellman-group14-sha1" except that the SHA2-256 hash algorithm is used. This new method is desirable for interoperability with resource-constrained devices. The group15 through group18 names are the same as those specified in [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit MODP Group 17, and 8192-bit MODP Group 18. All of these groups are within the guidelines for CNSA Suite for Top Secret. The SHA2-512 algorithm is to be used when "sha512" is specified as a part of the key exchange method name. Baushke Expires March 11, 2017 [Page 3] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 4. IANA Considerations This document augments the Key Exchange Method Names in [RFC4253]. It downgrades the use of SHA-1 hashing for key exchange methods in [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY the ecdh-sha2-nistp256 given in [RFC5656]. It is desirable to also include the ssh-curves from the [I-D.ietf-curdle-ssh-curves] in this list. The "curve25519-sha256" is currently available in some Secure Shell implementations under the name "curve25519-sha256@libssh.org" and is the best candidate for a fast, safe, and secure key exchange method. IANA is requested to update the SSH algorithm registry with the following entries: Key Exchange Method Name Reference Note diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group-exchange-sha256 RFC4419 MAY diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD ecdh-sha2-nistp256 RFC5656 MAY ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp521 RFC5656 SHOULD ecdh-sha2-* RFC5656 MAY ecmqv-sha2 RFC5656 MAY gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha1-* RFC4462 MAY gss-* RFC4462 MAY rsa1024-sha1 RFC4432 SHOULD NOT rsa2048-sha256 RFC4432 MAY diffie-hellman-group14-sha256 This Draft SHOULD diffie-hellman-group15-sha512 This Draft MAY diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group17-sha512 This Draft MAY diffie-hellman-group18-sha512 This Draft MAY curve25519-sha256 ssh-curves MUST curve448-sha512 ssh-curves MAY Figure 2 The Note column in the above table is an implementation suggestion/ recommendation for the listed key exchange method. It is up to the end-user as to what algorithms they choose to be able to negotiate. The guidance of his document is that the SHA-1 algorithm hashing SHOULD NOT be used. If it is used, it should only be provided for Baushke Expires March 11, 2017 [Page 4] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 backwards compatibility, should not be used in new designs, and should be phased out of existing key exchanges as quickly as possible because of its known weaknesses. Any key exchange using SHA-1 SHOULD NOT be in a default key exchange list if at all possible. If they are needed for backward compatibility, they SHOULD be listed after all of the SHA-2 based key exchanges. The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD be retained for compatibility with older Secure Shell implementations. It is intended that this key exchange be phased out as soon as possible. 5. Acknowledgements Thanks to the following people for review and comments: Denis Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault. Thanks to the following people for code to implement interoperable exchanges using some of these groups as found in an this draft: Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) and Poderosa implementations also adopting new Diffie-Hellman groups based on this draft. 6. Security Considerations The security considerations of [RFC4253] apply to this document. The security considerations of [RFC3526] suggest that these MODP groups have security strengths given in this table. They are based on [RFC3766] Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. Baushke Expires March 11, 2017 [Page 5] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 Group modulus security strength estimates (RFC3526) +--------+----------+---------------------+---------------------+ | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | | | +----------+----------+----------+----------+ | | | | exponent | | exponent | | | | in bits | size | in bits | size | +--------+----------+----------+----------+----------+----------+ | 14 | 2048-bit | 110 | 220- | 160 | 320- | | 15 | 3072-bit | 130 | 260- | 210 | 420- | | 16 | 4096-bit | 150 | 300- | 240 | 480- | | 17 | 6144-bit | 170 | 340- | 270 | 540- | | 18 | 8192-bit | 190 | 380- | 310 | 620- | +--------+----------+---------------------+---------------------+ Figure 3 Many users seem to be interested in the perceived safety of using larger MODP groups and hashing with SHA2-based algorithms. 7. References 7.1. Normative References [FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . Baushke Expires March 11, 2017 [Page 6] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 7.2. Informative References [CNSA-SUITE] "Information Assurance by the National Security Agency", "Commercial National Security Algorithm Suite", September 2016, . [I-D.ietf-curdle-ssh-curves] Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448", draft- ietf-curdle-ssh-curves-00 (work in progress), March 2016. [MFQ-U-OO-815099-15] "National Security Agency/Central Security Service", "CNSA Suite and Quantum Computing FAQ", January 2016, . [NIST-SP-800-131Ar1] Barker, and Roginsky, "Transitions: Recommendation for the Transitioning of the Use of Cryptographic Algorithms and Key Lengths", NIST Special Publication 800-131A Revision 1, November 2015, . [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, . [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, . [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, . [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, . Baushke Expires March 11, 2017 [Page 7] Internet-Draft KEX Method Updates/Recommendations for SSH September 2016 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, March 2006, . [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 2006, . [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, . [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, . [safe-curves] Bernstein, and Lange, "SafeCurves: choosing safe curves for elliptic-curve cryptography.", February 2016, . Author's Address Mark D. Baushke Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, CA 94089-1228 US Phone: +1 408 745 2952 Email: mdb@juniper.net URI: http://www.juniper.net/ Baushke Expires March 11, 2017 [Page 8]