| Internet Engineering Task Force | M. Baushke |
| Internet-Draft | Juniper Networks, Inc. |
| Updates: 4253, 4419, 4432, 4462, 5656 | February 13, 2016 |
| (if approved) | |
| Intended status: Standards Track | |
| Expires: August 16, 2016 |
More Modular Exponential (MODP) Diffie-Hellman Groups for SSH
draft-baushke-ssh-dh-group-sha2-03
This document defines two added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol. It also updates [RFC4253] by specifying new RECOMMENDED and new OPTIONAL Diffie-Hellman key exchange algorithms using SHA-2 hashes.
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 August 16, 2016.
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 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.
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 MODP group with 768 bits) 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] implementors 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 at the National Security Agency has published a FAQ [MFQ-U-OO-815099-15] suggesting that the use of 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 for small embedded applications.
Please send comments on this draft to ietf-ssh@NetBSD.org.
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].
This memo adopts the style and conventions of [RFC4253] in specifying how the use of new data key exchange is indicated in SSH.
The following new key exchange algorithms are defined:
Key Exchange Method Name Note
diffie-hellman-group14-sha256 MAY/OPTIONAL
diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL
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 algorith is used.
The group15, group16, group17, and group18 names are the same as those specified in [RFC3526] as 3072-bit MODP Group 14, 4096-bit MODP Group 15, 6144-bit MODP Group 17, and 8192-bit MODP Group 18.
The SHA2-512 algorithm is to be used when "sha512" is specified as a part of the key exchange method name.
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.josefsson-ssh-curves] in this list. It is not yet clear if curve448-sha256 or curve448-sha512 will be defined in that draft.
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 MUST
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 MAY
diffie-hellman-group15-sha512 This Draft MUST
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 SHOULD
curve448-sha256 ssh-curves MAY
Figure 2
The Note in the above table is an implementation suggestion 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 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.
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.
Group modulus security strength estimates
+--------+----------+---------------------+---------------------+
| 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 the SHA2-based algorithms for hashing.
| [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, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006. |