RFC 8268

More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)

📅 published December 2017, from ietf

RFC 8268: More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) 🎀

okay bestie, this is the RFC that gives SSH some bigger, stronger Diffie-Hellman groups 💪✨ it's from December 2017 and it's a Standards Track doc from the IETF, so it's an official Internet standard, not just a suggestion 💅

  • Request for Comments: 8268
  • Author: M. Baushke, Juniper Networks, Inc. 🦋
  • Category: Standards Track
  • Date: December 2017
  • Updates: Updates: 4250, 4253, so it updates RFC 4250 and RFC 4253 🌸
  • ISSN: 2070-1721

Abstract

okay so the tl;dr is that this doc adds some new MODP groups for SSH that use SHA-2 hashes 🔥 it also updates RFC 4250, and it updates RFC 4253 by fixing a mistake about how you check the peer's DH Public Key 🙈

Status of This Memo

this is an Internet Standards Track document 🧚

it's a product of the IETF, which means it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 💜

info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8268 🌈

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as in effect on the date it was published. please read those carefully because they describe your rights and restrictions for this document 📜

if you pull Code Components out of this doc, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents

1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
3.  Key Exchange Algorithms . . . . . . . . . . . . . . . . . . .   4
4.  Checking the Peer's DH Public Key . . . . . . . . . . . . . .   5
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1. Overview and Rationale ✨

okay so SSH is basically the go-to protocol for secure communication on the Internet 🔐 security protocols and primitives are a super active research area, and that research helps suggest updates to SSH 🧠

so, Section 8 of [RFC4253] has a small error in point 3 about checking the Peer's DH Public Key. Section 4 of this document is the fix 🩹

now the drama: SHA-1 has security concerns [RFC6194], and so do MODP groups smaller than 2048 bits [NIST-SP-800-131Ar1] 😬 so implementers and users should ask for support of larger Diffie-Hellman (DH) MODP group sizes that come with data-integrity verification. that means using the SHA-2 family of secure hash algorithms, and having MODP groups that give more security 💅 bigger MODP groups plus the move to SHA-2 hashes are a big deal for strengthening the key exchange algorithms that the SSH client and server can use 👑

the DH primes in this doc are all "safe primes", meaning p = 2q + 1 where q is also a prime 🌸 the new MODP groups start at the MODP 3072-bit group15, and they all use SHA512 as the hash algorithm 🔥

the DH 2048-bit MODP group14 is already in most SSH implementations, and most implementations already have a SHA256 implementation too. so "diffie-hellman-group14-sha256" is included because it's easy to implement 🍓

the plan is for these new MODP groups with SHA-2-based hashes to update Section 6.4 of [RFC4253] and Section 4.10 of [RFC4250] 🦋

next up, the United States Information Assurance Directorate (IAD) at the National Security Agency (NSA) published "Commercial National Security Algorithm Suite and Quantum Computing Frequently Asked Questions". [MFQ-U-OO-815099-15] is aimed at organizations that run classified or unclassified national security systems (NSS), and at vendors who build products used in NSS 🕵️‍♀️

this FAQ says NSS should no longer use the following:

  • Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) with NIST P-256. (For SSH, this would suggest avoiding [RFC5656] Key Exchange Algorithm "ecdh-sha2-nistp256" and Public Key Algorithm "ecdsa-sha2-nistp256".) 🙅‍♀️
  • SHA-256. (For SSH, this would suggest avoiding any Key Exchange Method using SHA1, SHA224, or SHA256 in favor of using SHA384 or SHA512.) 🙈
  • AES-128. (For SSH, this would suggest avoiding Encryption Algorithms [RFC4253] "aes128-cbc" and [RFC4344] "aes128-ctr".) 💀
  • RSA with 2048-bit keys. (For SSH, this would suggest avoiding [RFC4253] "ssh-rsa" using RSA with SHA1, as well as [RFC6187] "x509v3-rsa2048-sha256", as well as any other RSA key that has a length less than 3072-bits or uses a hash less than SHA384.) 🌈
  • Diffie-Hellman with 2048-bit keys. (For SSH, this would suggest avoiding use of [RFC4253] both of "diffie-hellman-group1-sha1" and "diffie-hellman-group14-sha1", as well as avoiding "diffie-hellman-group14-sha256" added by this document.) 😭

the FAQ also says NSS users should pick DH groups based on well-established and validated parameter sets that meet the minimum required sizes. a few examples:

  • Elliptic Curves are currently restricted to the NIST P-384 group only for both ECDH and ECDSA, following existing NIST and National Information Assurance Partnership (NIAP) standards. (For SSH, this means using [RFC5656] "ecdh-sha2-nistp384" for key exchange and "ecdsa-sha2-nistp384" for Public Key Algorithm Names.) ⭐
  • RSA moduli should have a minimum size of 3072 bits (other than the noted PKI exception), and keys should be generated in accordance with all relevant NIST standards. 🧚
  • For Diffie-Hellman, use a Diffie-Hellman prime modulus of at least 3072 bits. (For bit sizes as specified in [RFC3526], this would allow any of group15, group16, group17, or group18 to be used.) 💜

SSH might not always protect Top Secret communications, but this doc still adopts the DH groups from the FAQ's examples, and it uses SHA512 instead of SHA256 for the new DH groups 🫶

2. Requirements Language 💖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 📚

3. Key Exchange Algorithms 🦋

this doc adds some new Key Exchange Algorithm Method Names on top of what was originally in [RFC4253] and [RFC4250] 🌸

it also follows the style and conventions of [RFC4253] for showing how new data key exchange gets indicated in SSH ✨

these are the new key exchange method algorithms defined here:

  • diffie-hellman-group14-sha256
  • diffie-hellman-group15-sha512
  • diffie-hellman-group16-sha512
  • diffie-hellman-group17-sha512
  • diffie-hellman-group18-sha512

the SHA-2 family of secure hash algorithms is defined in [RFC6234] 🔥

the key exchange method for the name "diffie-hellman-group14-sha256" is the same as for "diffie-hellman-group14-sha1", except that it uses the SHA256 hash algorithm 💅 it is recommended that "diffie-hellman-group14-sha256" SHOULD be supported, to smooth the transition to newer group sizes 🎀

the group15 through group18 names are the same as the ones specified in [RFC3526]: 3072-bit MODP group15, 4096-bit MODP group16, 6144-bit MODP group17, and 8192-bit MODP group18 👑

the SHA512 algorithm is used whenever "sha512" appears as part of the key exchange method name 🌈

7.1. Normative References ✨

okay bestie, these are the must-reads 📚 the stuff the spec literally can't work without, so you gotta have these on hand 🫶

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://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,
           <https://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,
           <https://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, <https://www.rfc-editor.org/info/rfc4253>.

[RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234,
           DOI 10.17487/RFC6234, May 2011,
           <https://www.rfc-editor.org/info/rfc6234>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References 🧚

these ones are more like the extra-credit reading 🌸 super useful for context, but the spec doesn't need you to read them to work, so no pressure, bestie 💖

[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters",
           <http://www.iana.org/assignments/ssh-parameters/>

[MFQ-U-OO-815099-15]
           National Security Agency / Central Security Service,
           "Commerical National Security Algorithm Suite and Quantum
           Computing FAQ", MFQ U/OO/815099-15 , January 2016,
           <https://www.iad.gov/iad/library/ia-guidance/
           ia-solutions-for-classified/algorithm-
           guidance/assets/public/upload/
           CNSA-Suite-and-Quantum-Computing-FAQ.pdf>.

[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, DOI 10.6028/NIST.SP.800-131Ar1, November 2015,
           <http://dx.doi.org/10.6028/NIST.SP.800-131Ar1>.

[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,
           <https://www.rfc-editor.org/info/rfc3766>.

[RFC4344]  Bellare, M., Kohno, T., and C. Namprempre, "The Secure
           Shell (SSH) Transport Layer Encryption Modes", RFC 4344,
           DOI 10.17487/RFC4344, January 2006,
           <https://www.rfc-editor.org/info/rfc4344>.

[RFC5656]  Stebila, D. and J. Green, "Elliptic Curve Algorithm
           Integration in the Secure Shell Transport Layer",
           RFC 5656, DOI 10.17487/RFC5656, December 2009,
           <https://www.rfc-editor.org/info/rfc5656>.

[RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
           Shell Authentication", RFC 6187, DOI 10.17487/RFC6187,
           March 2011, <https://www.rfc-editor.org/info/rfc6187>.

[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,
           <https://www.rfc-editor.org/info/rfc6194>.

Acknowledgements 🫶

okay the real MVPs 👑 these people reviewed and commented on the doc, so a massive thank you to every single one of them 💕

Denis Bider, Peter Gutmann, Damien Miller, Niels Moller, Matt Johnston, Iwamoto Kouichi, Dave Dugal, Daniel Migault, Anna Johnston, Ron Frederick, Rich Salz, Travis Finkenauer, and Eric Rescorla. literally iconic squad 🥹✨

Author's Address 🦋

this is where you can find the author, Mark D. Baushke, if you ever need to reach out 📬

Mark D. Baushke
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA  94089-1228
United States of America

Phone: +1 408 745 2952
Email: mdb@juniper.net
URI:   http://www.juniper.net/
📦 where this page comes from