Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
draft-ietf-curdle-ssh-kex-sha2-09
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (curdle WG) | |
|---|---|---|---|
| Author | Mark D. Baushke | ||
| Last updated | 2017-12-18 (Latest revision 2017-07-30) | ||
| Replaces | draft-baushke-ssh-dh-group-sha2 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
(of
-14)
Almost Ready
SECDIR Last Call review
(of
-14)
Has Issues
OPSDIR Last Call Review
Incomplete, due 2021-02-24
|
||
| Stream | WG state | In WG Last Call | |
| Document shepherd | Daniel Migault | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Daniel Migault <daniel.migaultf@ericsson.com> |
draft-ietf-curdle-ssh-kex-sha2-09
Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc.
Updates: 4250 (if approved) July 30, 2017
Intended status: Standards Track
Expires: January 31, 2018
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH)
draft-ietf-curdle-ssh-kex-sha2-09
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 document updates RFC
4250.
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 January 31, 2018.
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
Baushke Expires January 31, 2018 [Page 1]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3
3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4
3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4
3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4
3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4
3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4
3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4
3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5
3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5
3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5
3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5
3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 5
3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5
3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6
3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6
3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 6
3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 6
3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 6
3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7
3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 7
3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 7
3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 7
3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 7
3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8
3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8
3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 8
3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 8
3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 8
3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 8
3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 8
4. Selecting an appropriate hashing algorithm . . . . . . . . . 8
5. Summary Guidance for Key Exchange Method Names . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Baushke Expires January 31, 2018 [Page 2]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
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
deprecated as well as recommending some that SHOULD and one that MUST
be adopted. This document updates [RFC4250].
This document adds recommendations for adoption of Key Exchange
Methods which MUST, 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 ssh-curves from
[I-D.ietf-curdle-ssh-curves] and new-modp from the
[I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex
[I-D.ietf-curdle-gss-keyex-sha2].
[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 RFC 2119 [RFC2119].
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], [I-D.ietf-curdle-gss-keyex-sha2],
and [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability
for implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any
method not explicitly listed, MAY be implemented.
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, in which case they will likely be downgraded to SHOULD NOT
or MUST NOT. 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.
Baushke Expires January 31, 2018 [Page 3]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
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 multiple implementations and
SHOULD be implemented in any SSH interested in using elliptic curve
based key exchanges.
3.2. curve448-sha512
The Curve448 provides very strong security. It is probably stronger
and more work than is currently needed. This method MAY be
implemented.
3.3. diffie-hellman-group-exchange-sha1
This set of ephemerally generated key exchange groups uses SHA-1 as
defined in [RFC4419]. However, SHA-1 has security concerns provided
in [RFC6194]. It is recommended that these key exchange groups NOT
be used. This key exchange SHOULD NOT be used.
3.4. diffie-hellman-group-exchange-sha256
This set of ephemerally generated key exchange groups uses SHA2-256
as defined in [RFC4419]. [I-D.ietf-curdle-ssh-dh-group-exchange]
mandates implementations avoid any MODP group with less than 2048
bits. This key exchange MAY be used.
3.5. diffie-hellman-group1-sha1
This method uses [RFC7296] 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 (see [LOGJAM]
and [NIST-SP-800-131Ar1]), this method is considered insecure. This
method is being moved from MUST to SHOULD NOT instead of MUST NOT
only to allow a transition time to get off of it. There are many old
implementations out there that may still need to use this key
exchange, it should be removed from server implementations as quickly
as possible.
3.6. diffie-hellman-group14-sha1
This method uses [RFC3526] group14 (a 2048-bit MODP group) which is
still a reasonable size. This key exchange group 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
Baushke Expires January 31, 2018 [Page 4]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
to SHOULD to aid in transition to stronger SHA-2 based hashes. This
method will transition to SHOULD NOT when SHA-2 alternatives are more
generally available.
3.7. diffie-hellman-group14-sha256
This key exchange uses the group14 (a 2048-bit MODP group) along with
a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field
Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered
to be secure. It is a reasonably simple transition to move from
SHA-1 to SHA-2. This method MUST be implemented.
3.8. diffie-hellman-group15-sha512
Note: The use of this 3072-bit MODP group would be equally justified
to use SHA2-384 as the hash rather than SHA2-512. However, some
small implementations would rather only worry about two rather than
three new hashing functions. This group does not really provide much
additional head room over the 2048-bit group14 FFC DH and the
predominate open source implementations are not adopting it. This
method MAY be implemented.
3.9. 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 it.
This modulus (4096-bit) 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.10. diffie-hellman-group17-sha512
The use of this 6144-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who wish to avoid
using ECC algorithms. This method MAY be implemented.
3.11. diffie-hellman-group18-sha512
The use of this 8192-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who wish to avoid
using ECC algorithms. This method MAY be implemented.
3.12. 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
Baushke Expires January 31, 2018 [Page 5]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
[safe-curves], this curve may not be as useful and strong as desired
for handling TOP SECRET information for some applications. The SSH
development community is divided on this and many implementations do
exist. If traditional ECDH key exchange methods are implemented,
then this method SHOULD be implemented. It is advisable to match the
ECDSA and ECDH algorithms to use the same family of curves.
3.13. 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. If traditional ECDH key exchange methods are implemented,
then this method SHOULD be implemented.
3.14. ecdh-sha2-nistp521
This ECDH method may be implemented because it is smaller and faster
than using large FFC primes with traditional Diffie-Hellman (DH). It
is not listed in [CNSA-SUITE], so it is not currently appropriate for
TOP SECRET. This method MAY be implemented.
3.15. 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 SHOULD NOT be
used. It is intended that it move to MUST NOT as soon as the
majority of server implementations no longer offer it. It should be
removed from server implementations as quickly as possible.
3.16. gss-group1-sha1-*
This method suffers from the same problems of diffie-hellman-
group1-sha1. It uses [RFC7296] 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 (see
[LOGJAM] and [NIST-SP-800-131Ar1]), this method is considered
insecure. This method SHOULD NOT be implemented. It is intended
that it move to MUST NOT as soon as the majority of server
implementations no longer offer it. It should be removed from server
implementations as quickly as possible.
3.17. 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
Baushke Expires January 31, 2018 [Page 6]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
may be implemented and deployed. This method will transition to
SHOULD NOT when SHA-2 alternatives are more generally available. No
other standard indicated that this method was anything other than
optional even though it was implemented in all GSS-API systems. This
method MAY be implemented.
3.18. gss-group14-sha256-*
This key exchange uses the group14 (a 2048-bit MODP group) along with
a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field
Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered
to be secure. It is a reasonably simple transition to move from
SHA-1 to SHA-2. If the GSS-API is to be used, then this method
SHOULD be implemented.
3.19. gss-group15-sha512-*
The use of this 3072-bit MODP group does not really provide much
additional head room over the 2048-bit group14 FFC DH. If the GSS-
API is to be used, then this method MAY be implemented.
3.20. gss-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 (4096-bit) is larger than that required by [CNSA-SUITE]
and should be sufficient to inter-operate with more paranoid nation-
states. If the GSS-API is to be used, then this method SHOULD be
implemented.
3.21. gss-group17-sha512-*
The use of this 6144-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who wish to avoid
using ECC algorithms. If the GSS-API is to be used, then this method
MAY be implemented.
3.22. gss-group18-sha512-*
The use of this 8192-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who prefer to avoid
using ECC algorithms. If the GSS-API is to be used, then this method
MAY be implemented.
Baushke Expires January 31, 2018 [Page 7]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
3.23. gss-nistp256-sha256-*
If the GSS-API is to be used with ECC algorithms, then this method
SHOULD be implemented.
3.24. gss-nistp384-sha384-*
If the GSS-API is to be used with ECC algorithms, then this method
SHOULD be implemented to permit TOP SECRET information to be
communicated.
3.25. gss-nistp521-sha512-*
If the GSS-API is to be used with ECC algorithms, then this method
MAY be implemented.
3.26. gss-curve25519-sha256-*
If the GSS-API is to be used with ECC algorithms, then this method
SHOULD be implemented.
3.27. gss-curve448-sha512-*
If the GSS-API is to be used with ECC algorithms, then this method
MAY be implemented.
3.28. rsa1024-sha1
The security of RSA 1024-bit modulus keys is not good enough any
longer. A key size should be 2048-bits. This generated key exchange
groups uses SHA-1 which has security concerns [RFC6194]. This method
MUST NOT be implemented.
3.29. rsa2048-sha256
An RSA 2048-bit modulus key with a SHA2-256 hash. This method MAY be
implemented.
4. Selecting an appropriate hashing algorithm
As may be seen from the above, the Key Exchange Methods area all
using either SHA256 or SHA512 with the exception of the ecdh-
sha2-nistp384 which uses SHA384.
The cited CNSA Suite specifies the use of SHA384 and says that SHA256
is no longer good enough for TOP SECRET. Nothing is said about the
use of SHA512. It may be that the internal state of 1024 bits in
both SHA384 and SHA512 makes the SHA384 more secure because it does
Baushke Expires January 31, 2018 [Page 8]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
not leak an additional 128 bits of state. Of course, use of SHA384
also reduces the security strength to 192 bits instead of being 256
bits or more. This seems to contradict the desire to double the
symmetric key strength in order to try to be safe from Post Quantum
Computing (PQC) attacks given a session key derived from the key
exchange will be limited to the security strength of the hash being
used.
The move away from SHA256 to SHA512 for the newer key exchange
methods is more to try to slow Grover's algorithm (a PQC attack)
slightly. It is also the case that SHA2-512 may, in many modern
CPUs, be implemented more efficiently using 64-bit arithmetic than
SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs
SHA512 is more about reducing the number of code point alternatives
to negotiate. There seemed to be consensus in favor of SHA2-512 over
SHA2-384 for key exchanges.
5. Summary Guidance for Key Exchange Method Names
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 SHOULD NOT
diffie-hellman-group1-sha1 RFC4253 SHOULD 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 SHOULD NOT
gss-group1-sha1-* RFC4462 SHOULD NOT
gss-group14-sha256-* gss-keyex SHOULD
gss-group16-sha512-* gss-keyex SHOULD
gss-nistp256-sha256-* gss-keyex SHOULD
gss-nistp384-sha384-* gss-keyex SHOULD
gss-curve25519-sha256-* gss-keyex SHOULD
rsa1024-sha1 RFC4432 MUST NOT
The full set of official [IANA-KEX] key algorithm method names not
otherwise mentioned in this document MAY be implemented.
The guidance of this document is that the SHA-1 algorithm hashing
SHOULD 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
Baushke Expires January 31, 2018 [Page 9]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
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] 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 SHOULD be listed after all possible SHA-2 based key
exchanges.
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>]
6. 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,
and Tero Kivinen.
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.
7. Security Considerations
This SSH protocol provides a secure encrypted channel over an
insecure network. It performs server host authentication, key
exchange, encryption, and integrity protection. It also derives a
unique session ID that may be used by higher-level protocols.
Full security considerations for this protocol are provided in
[RFC4251]
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.
Baushke Expires January 31, 2018 [Page 10]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT.
This method used [RFC7296] 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. If your systems need to be concerned with TOP
SECRET information, then the guidance for supporting lesser security
strength key exchanges may be omitted for your implementations.
The MODP group14 is already required for 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. Until such time as a PQC method of key exchange is
developed and adopted, it may be desirable to generate new and larger
DH groups to avoid pre-calculation attacks that are provably not
backdoored.
Baushke Expires January 31, 2018 [Page 11]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
8. IANA Considerations
IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be
implemented as being deprecated by this document.
9. References
9.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,
<http://www.rfc-editor.org/info/rfc2119>.
[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,
<http://www.rfc-editor.org/info/rfc3526>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<http://www.rfc-editor.org/info/rfc4250>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>.
9.2. Informative References
[CNSA-SUITE]
"Information Assurance by the National Security Agency",
"Commercial National Security Algorithm Suite", September
2016, <https://www.iad.gov/iad/programs/iad-initiatives/
cnsa-suite.cfm>.
[I-D.ietf-curdle-gss-keyex-sha2]
Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2",
draft-ietf-curdle-gss-keyex-sha2-02 (work in progress),
June 2017.
[I-D.ietf-curdle-ssh-curves]
Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method using Curve25519 and
Curve448", draft-ietf-curdle-ssh-curves-05 (work in
progress), May 2017.
Baushke Expires January 31, 2018 [Page 12]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
[I-D.ietf-curdle-ssh-dh-group-exchange]
Velvindron, L. and M. Baushke, "Increase SSH minimum
recommended DH modulus size to 2048 bits", draft-ietf-
curdle-ssh-dh-group-exchange-05 (work in progress), July
2017.
[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)", draft-ietf-curdle-ssh-modp-dh-sha2-07 (work in
progress), June 2017.
[IANA-KEX]
Internet Assigned Numbers Authority (IANA), "Secure Shell
(SSH) Protocol Parameters: Key Exchange Method Names",
March 2017, <http://www.iana.org/assignments/ssh-
parameters/ssh-parameters.xhtml#ssh-parameters-16>.
[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Beguelin, S., and P. Zimmermann, "Imperfect
Forward Secrecy: How Diffie-Hellman Fails in Practice",
ACM Conference on Computer and Communications Security
(CCS) 2015, 2015, <https://weakdh.org/imperfect-forward-
secrecy-ccs15.pdf>.
[MFQ-U-OO-815099-15]
"National Security Agency/Central Security Service", "CNSA
Suite and Quantum Computing FAQ", January 2016,
<https://www.iad.gov/iad/library/ia-guidance/ia-solutions-
for-classified/algorithm-guidance/cnsa-suite-and-quantum-
computing-faq.cfm>.
[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,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-131Ar1.pdf>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>.
Baushke Expires January 31, 2018 [Page 13]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[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,
<http://www.rfc-editor.org/info/rfc4419>.
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
March 2006, <http://www.rfc-editor.org/info/rfc4432>.
[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, <http://www.rfc-editor.org/info/rfc4462>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<http://www.rfc-editor.org/info/rfc5656>.
[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,
<http://www.rfc-editor.org/info/rfc6194>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[safe-curves]
Bernstein and Lange, "SafeCurves: choosing safe curves for
elliptic-curve cryptography.", February 2016,
<https://safecurves.cr.yp.to/>.
Author's Address
Baushke Expires January 31, 2018 [Page 14]
Internet-Draft KEX Method Updates/Recommendations for SSH July 2017
Mark D. Baushke
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089-1228
US
Email: mdb@juniper.net
URI: http://www.juniper.net/
Baushke Expires January 31, 2018 [Page 15]