Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc.
Updates: 4250, 4253 (if approved) March 27, 2017
Intended status: Standards Track
Expires: September 28, 2017

Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
draft-ietf-curdle-ssh-kex-sha2-07

Abstract

This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This RFC updates [RFC4253] MUST algorithms. This RFC also notes that the [IANASSH] has replaced [RFC4250] as the primary reference document for SSH Protocol Assigned Numbers.

This document adds recommendations for adoption of Key Exchange Methods which MUST, SHOULD+, SHOULD, SHOULD-, MAY, SHOULD NOT, and MUST NOT be implemented. New key exchange methods will use the SHA-2 family of hashes and are drawn from these from [I-D.ietf-curdle-ssh-curves] and new-modp from the [I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex [NEWGSSAPI].

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 September 28, 2017.

Copyright Notice

Copyright (c) 2017 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 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.


Table of Contents

1. Overview and Rationale

Secure Shell (SSH) is a common protocol for secure communication on the Internet. In [RFC4253], SSH originally defined two Key Exchange Method Names that MUST be implemented. Over time, what was once considered secure, is no longer considered secure. The purpose of this RFC is to recommend that some published key exchanges be adopted or reclassified and others retired.

[TO BE REMOVED: 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].

When used in the tables in this document, these terms indicate that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be implemented as part of a Secure Shell implementation. Additional terms used in this document are:

SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document.

3. Key Exchange Methods

This memo adopts the style and conventions of [RFC4253] in specifying how the use of data key exchange is indicated in SSH.

This RFC also collects Key Exchange Method Names in various existing RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], [I-D.ietf-curdle-ssh-modp-dh-sha2], [NEWGSSAPI], and [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for implementation of MUST, SHOULD+, SHOULD, SHOULD-, SHOULD NOT, and MUST NOT.

This document is intended to provide guidance as to what Key Exchange Algorithms are to be considered for new or updated SSH implementations. This document will be superseded when one or more of the listed algorithms are considered too weak to continue to use securely, or when newer methods have been analyzed and found to be secure with wide enough adoption to upgrade their recommendation from MAY to SHOULD or MUST.

3.1. curve25519-sha256

The Curve25519 provides strong security and is efficient on a wide range of architectures with properties that allow better implementation properties compared to traditional elliptic curves. The use of SHA2-256 for integrity is a reasonable one for this method. This Key Exchange Method has a few implementations and SHOULD+ be implemented in any SSH interested in using elliptic curve based key exchanges.

3.2. diffie-hellman-group-exchange-sha1

This set of ephemerally generated key exchange groups uses SHA-1 which has security concerns [RFC6194]. It is recommended that these key exchange groups NOT be used. This key exchange MUST NOT be implemented.

3.3. diffie-hellman-group1-sha1

This method uses [RFC2409] Oakley Group 2 (a 1024-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], this method is considered insecure. This method is being moved from MUST to MUST NOT.

3.4. diffie-hellman-group14-sha1

This generated key exchange groups uses SHA-1 which has security concerns [RFC6194]. However, this group is still strong enough and is widely deployed. This method is being moved from MUST to SHOULD- to aid in transition to stronger SHA-2 based hashes. This method will transition to MUST NOT when SHA-2 alternatives are more generally available.

3.5. diffie-hellman-group14-sha256

This generated key exchange uses a 2048-bit sized MODP group along with a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field cryptography Diffie-Hellman key exchange method. It is a reasonably simple transition to move from SHA-1 to SHA-2. This method MUST be implemented.

3.6. diffie-hellman-group16-sha512

The use of FFC DH is well understood and trusted. Adding larger modulus sizes and protecting with SHA2-512 should give enough head room to be ready for the next scare that someone has pre-computed. This modulus is larger than that required by [CNSA-SUITE] and should be sufficient to inter-operate with more paranoid nation-states. This method SHOULD+ be implemented.

3.7. ecdh-sha2-nistp256

Elliptic Curve Diffie-Hellman (ECDH) are often implemented because they are smaller and faster than using large FFC primes with traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and [safe-curves], this curve may not be as useful and strong as desired. The SSH development community is divided on this and many implementations do exist. However, there are good implementations of this along with a constant-time SHA2-256 implementation. If an implementer does not have a constant-time SHA2-384 implementation (which helps avoid side-channel attacks), then this is the correct ECDH to implement. This method SHOULD- be implemented.

3.8. ecdh-sha2-nistp384

This ECDH method should be implemented because it is smaller and faster than using large FFC primes with traditional Diffie-Hellman (DH). Given [CNSA-SUITE], it is considered good enough for TOP SECRET for now. This really needs a constant-time implementation of SHA2-384 to be useful. This method SHOULD+ be implemented.

3.9. gss-gex-sha1-*

This set of ephemerally generated key exchange groups uses SHA-1 which has security concerns [RFC6194]. It is recommended that these key exchange groups NOT be used. This key exchange MUST NOT be implemented.

3.10. gss-group1-sha1-*

This method suffers from the same problems of diffie-hellman-group1-sha1. It uses [RFC2409] Oakley Group 2 (a 1024-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], this method is considered insecure. This method MUST NOT be implemented.

3.11. gss-group14-sha1-*

This generated key exchange groups uses SHA-1 which has security concerns [RFC6194]. If GSS-API key exchange methods are being used, then this one SHOULD- be implemented until such time as SHA-2 variants may be implemented and deployed.

3.12. gss-group14-sha256-*

If the GSS-API is to be used, then this method SHOULD be implemented.

3.13. gss-group16-sha512-*

If the GSS-API is to be used, then this method SHOULD+ be implemented.

3.14. rsa1024-sha1

The security of RSA 1024-bit modulus keys is not good enough any longer. A minimum bit size should be 2048-bit groups. This generated key exchange groups uses SHA-1 which has security concerns [RFC6194]. This method MUST NOT be implemented.

4. Summary Guidance for Key Exchange Method Names

The full set of official [IANASSH] key algorithm method names not otherwise mentioned in this RFC MAY be implemented.

The Implement column is the current recommendations of this RFC. Key Exchange Method Names are listed alphabetically.

Key Exchange Method Name Reference Implement
curve25519-sha256 ssh-curves SHOULD+
diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT
diffie-hellman-group1-sha1 RFC4253 MUST NOT
diffie-hellman-group14-sha1 RFC4253 SHOULD-
diffie-hellman-group14-sha256 new-modp MUST
diffie-hellman-group16-sha512 new-modp SHOULD+
ecdh-sha2-nistp256 RFC5656 SHOULD-
ecdh-sha2-nistp384 RFC5656 SHOULD+
gss-gex-sha1-* RFC4462 MUST NOT
gss-group1-sha1-* RFC4462 MUST NOT
gss-group14-sha1-* RFC4462 SHOULD-
gss-group14-sha256-* gss-keyex SHOULD
gss-group16-sha512-* gss-keyex SHOULD+
rsa1024-sha1 RFC4432 MUST NOT

The guidance of this RFC is that the SHA-1 algorithm hashing MUST NOT be used. If it is used in implementations, it should only be provided for 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 MUST 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 MUST diffie-hellman-group14-sha1 method SHOULD- be retained for compatibility with older Secure Shell implementations. It is intended that this key exchange method be phased out as soon as possible.

It is believed that all current SSH implementations should be able to achieve an implementation of the "diffie-hellman-group14-sha256" method. To that end, this is one method that MUST be implemented.

[TO BE REMOVED: This registration should take place at the following location: <http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16>]

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, Anna Johnston.

Thanks to the following people for code to implement inter-operable 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 RFC.

It is desirable to deprecate or remove key exchange method name that are considered weak. A key exchange method may be weak because too few bits are used, or the hashing algorithm is considered too weak.

The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. This method used [RFC2409] Oakley Group 2 (a 1024-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], this method is no longer considered secure.

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 MUST to MAY as a key exchange method. This is the same reason that the stronger MODP groups being adopted. As the MODP 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 [RFC3526] is explicitly mentioned as the minimum modulus to protect Top Secret communications.

It has been observed in [safe-curves] that the NIST 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 mandatory to 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.

In a Post-Quantum Computing (PQC) world, it will be desirable to use larger cyclic subgroups. To do this using Elliptic Curve Cryptography will require much larger prime base fields, greatly reducing their efficiency. Finite Field based Cryptography already requires large enough base fields to accommodate larger cyclic subgroups.

7. References

7.1. Normative References

[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.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006.
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006.

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", Internet-Draft draft-ietf-curdle-ssh-curves-00, March 2016.
[I-D.ietf-curdle-ssh-modp-dh-sha2] Baushke, M., "More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)", Internet-Draft draft-ietf-curdle-ssh-modp-dh-sha2-03, March 2017.
[IANASSH] "Internet Assigned Numbers Authority", "IANA, Secure Shell (SSH) Protocol Parameters", March 2017.
[MFQ-U-OO-815099-15] "National Security Agency/Central Security Service", "CNSA Suite and Quantum Computing FAQ", January 2016.
[NEWGSSAPI] Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", December 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.
[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.
[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 EMail: mdb@juniper.net URI: http://www.juniper.net/