Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
draft-ietf-curdle-ssh-kex-sha2-13
Internet Engineering Task Force M. D. Baushke
Internet-Draft Juniper Networks, Inc.
Updates: 4250 4253 4432 4462 (if approved) 14 January 2021
Intended status: Standards Track
Expires: 18 July 2021
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH)
draft-ietf-curdle-ssh-kex-sha2-13
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, RFC 4253, RFC 4432, and RFC 4462.
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 https://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 18 July 2021.
Copyright Notice
Copyright (c) 2021 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 (https://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.
Baushke Expires 18 July 2021 [Page 1]
Internet-Draft KEX Method Updates/Recommendations for S January 2021
Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
1.1. Selecting an appropriate hashing algorithm . . . . . . . 3
1.2. Selecting an appropriate Public Key Algorithm . . . . . . 3
1.2.1. Elliptic Curve Cryptography (ECC) . . . . . . . . . . 4
1.2.2. Finite Field Cryptography (FFC) . . . . . . . . . . . 4
1.2.3. Integer Factorization Cryptography (IFC) . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 6
3.1. SHA-1 and SHA-2 Hashing . . . . . . . . . . . . . . . . . 6
3.2. Elliptic Curve Cryptography (ECC) . . . . . . . . . . . . 6
3.2.1. curve25519-sha256 and gss-curve25519-sha256-* . . . . 6
3.2.2. curve448-sha512 and gss-curve448-sha512-* . . . . . . 7
3.2.3. ECC diffie-hellman using ecdh-*, ecmqv-sha2, and
gss-nistp* . . . . . . . . . . . . . . . . . . . . . 7
3.3. Finite Field Cryptography (FFC) . . . . . . . . . . . . . 8
3.3.1. FFC diffie-hellman using generated MODP groups . . . 8
3.3.2. FFC diffie-hellman using named MODP groups . . . . . 8
3.4. Integer Factorization Cryptography (IFC) . . . . . . . . 9
3.5. Secure Shell Extension Negotiation . . . . . . . . . . . 9
4. Summary Guidance for Key Exchange Method Names
Implementations . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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
(KEX) 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] [RFC4253] [RFC4432]
[RFC4462] by changing the requirement level ("MUST" moving to
"SHOULD" or "MAY" or "SHOULD NOT", and "MAY" moving to "MUST" or
"SHOULD" or "SHOULD NOT" or "MUST NOT") of various key-exchange
Show full document text