RFC 9212

Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)

📅 published March 2022, from ietf

Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) 💖

Authors: N. Gajcowski and M. Jenkins, both from the NSA 🫶 Stream and category: Independent Submission, published as Informational 📚 ISSN: 2070-1721 ✨ Date: March 2022 🌸 Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates 🙈

Abstract ✨

Okay so the US Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which is the crypto algorithm policy for national security stuff 🔐. This document explains how to use those CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication Protocol 🦋. It covers all the parts of US National Security Systems (described in NIST Special Publication 800-59) that run SSH, and it's also relevant for other US Government systems that handle high-value information 💅. It's published publicly so developers and operators of these systems, and any other deployments, can use it 🌈.

Status of This Memo 📝

This document isn't an Internet Standards Track specification. It's published for informational purposes only 🧚.

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion, and they don't say anything about whether it's good for implementing or deploying 🤷‍♀️. Documents the RFC Editor approves for publication can't become any level of Internet Standard. See Section 2 of RFC 7841 for the details 💜.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9212 ✨.

Copyright (c) 2022 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🗂️

1.  Introduction
2.  Terminology
3.  The Commercial National Security Algorithm Suite
4.  CNSA and Secure Shell
5.  Security Mechanism Negotiation and Initialization
6.  Key Exchange
  6.1.  ECDH Key Exchange
  6.2.  DH Key Exchange
7.  Authentication
  7.1.  Server Authentication
  7.2.  User Authentication
8.  Confidentiality and Data Integrity of SSH Binary Packets
  8.1.  Galois/Counter Mode
  8.2.  Data Integrity
9.  Rekeying
10. Security Considerations
11. IANA Considerations
12. References
  12.1.  Normative References
  12.2.  Informative References
Authors' Addresses

1. Introduction ✨

This doc sets out how to use the US National Security Agency's CNSA Suite algorithms [CNSA] with the Secure Shell Transport Layer Protocol [RFC4253] and the Secure Shell Authentication Protocol [RFC4252] 🦋. It covers the capabilities, configuration, and operation of all parts of US National Security Systems (described in NIST Special Publication 800-59 [SP80059]) that use SSH. It's also appropriate for other US Government systems that handle high-value info 💖. And yep, it's public, so developers and operators of these systems, plus any other deployments, can use it 🫶.

2. Terminology 📖

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 read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, just like shown here 🔥.

3. The Commercial National Security Algorithm Suite 👑

The NSA profiles commercial crypto algorithms and protocols as part of its job of keeping communications secure and interoperable for US Government National Security Systems 🔐. So it publishes guidance that helps the US Government move to new algorithms, and gives vendors and the wider Internet community info on how to use and configure them properly 💅.

Lowkey the big story is that cryptographically relevant quantum computers are coming, and that's been overshadowing transition plans 🌌. The NSA made the CNSA Suite to give vendors and IT users near-term flexibility for their information assurance interoperability needs, using crypto that exists today ✨. The whole point is to stop vendors and customers from having to make two huge transitions in a short window (first to elliptic curve cryptography, then to post-quantum cryptography) 😭. Since they expect a move to quantum-resistant crypto pretty soon, this avoids a double migration 🦋.

The NSA is writing a set of RFCs, this one included, with updated guidance on using certain common commercial algorithms in IETF protocols 🎀. You can use these alongside other RFCs and crypto guidance (like NIST Special Publications) to protect Internet traffic and data-at-rest for US Government National Security Systems 🛡️.

4. CNSA and Secure Shell 🐚

Several RFCs already explain how each CNSA component plugs into Secure Shell (SSH) 💜:

kex algorithms:

  • ecdh-sha2-nistp384 [RFC5656]
  • diffie-hellman-group15-sha512 [RFC8268]
  • diffie-hellman-group16-sha512 [RFC8268]

public key algorithms:

encryption algorithms (both client_to_server and server_to_client):

message authentication code (MAC) algorithms (both client_to_server and server_to_client):

The approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180] 🔢. But commercial products are more likely to have the SHA-512-based (sha2-512) kex and public key algorithms, which are defined in [RFC8268] and [RFC8332] 😅. So the SHA-384-based kex and public key algorithms SHOULD be used, and SHA-512-based algorithms MAY be used ✨. Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used 🚫.

AES in Galois/Counter Mode (AES-GCM) shall meet the requirements in [SP800-38D] 🔐. On top of that, all 16 octets of the authentication tag MUST be used as the SSH data integrity value, and AES has to be used with a 256-bit key 💅. Using AES-GCM in SSH should follow [RFC5647], with one exception: AES-GCM doesn't need to be listed as the MAC algorithm when its use is implicit, like in aes256-gcm@openssh.com 🧚. There's also a gap: [RFC5647] doesn't say that the AES-GCM invocation counter is incremented mod 2^64 🙈. So CNSA implementations MUST make sure the counter never repeats and is properly incremented after processing a binary packet 😭:

   invocation_counter = invocation_counter + 1 mod 2^64.

This doc pulls all of these documents together to guide CNSA-compliant Secure Shell implementations 🎀. Algorithms in this document might differ from the mandatory-to-implement ones. When that happens, the mandatory ones will still be there, just not used 🌸. Note that while compliant SSH implementations MUST follow this guidance, following it doesn't by itself mean an implementation is suitable for national security systems 🚨. An implementation has to be validated by the appropriate authority before it can be used that way ⭐.

5. Security Mechanism Negotiation and Initialization 🤝

As described in Section 7.1 of [RFC4253], exchanging SSH_MSG_KEXINIT between server and client decides which key agreement algorithm, MAC algorithm, host key algorithm (server authentication algorithm), and encryption algorithm get used 🔑. This section explains how CNSA components fit into SSH algorithm negotiation, key agreement, server authentication, and user authentication 💖.

Everything except the user authentication methods gets picked by the SSH_MSG_KEXINIT exchange between client and server 🧚.

The kex_algorithms name-list negotiates a single key agreement algorithm between server and client, following the guidance in Section 4 🦋. While [RFC9142] sets general guidance on what SSH implementations can do and requires support for "diffie-hellman-group14-sha256", that one MUST NOT be used 🚫. The result MUST be one of the following kex_algorithms, or the connection MUST be terminated 💀:

  • ecdh-sha2-nistp384 [RFC5656]
  • diffie-hellman-group15-sha512 [RFC8268]
  • diffie-hellman-group16-sha512 [RFC8268]

One of the following sets MUST be used for the encryption_algorithms and mac_algorithms name-lists 🎀. Either set MAY be used for each direction (client_to_server or server_to_client), but the result has to be the same, meaning AEAD_AES_256_GCM ✨:

   encryption_algorithm_name_list := { AEAD_AES_256_GCM }

   mac_algorithm_name_list := { AEAD_AES_256_GCM }

or

   encryption_algorithm_name_list := { aes256-gcm@openssh.com }

   mac_algorithm_name_list := {}

One of the following public key algorithms MUST be used 🔐:

The procedures for applying the negotiated algorithms are in the sections below 💜.

6. Key Exchange 🗝️

The key exchange is decided by the name-lists exchanged in the SSH_MSG_KEXINIT packets, as described above 🤝. Either Elliptic Curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST be used to set up a shared secret value between client and server 🔥.

A compliant system MUST NOT allow ephemeral/exchange values to be reused in a key exchange algorithm, because reuse causes security concerns 🙅‍♀️. Section 5.6.3.3 of [SP80056A] says an ephemeral private key shall be used in exactly one key establishment transaction and shall be destroyed (zeroized) as soon as possible 🫠. Section 5.8 of [SP80056A] says those shared secrets shall be destroyed (zeroized) right after they're used 💀. CNSA-compliant systems MUST follow these mandates 🛡️.

6.1. ECDH Key Exchange 🌊

The key exchange starts with an SSH_MSG_KEXECDH_INIT message, which carries the client's ephemeral public key used to generate a shared secret value 🦋.

The server answers an SSH_MSG_KEXECDH_INIT message with an SSH_MSG_KEXECDH_REPLY message. That reply carries the server's ephemeral public key, the server's public host key, and a signature of the exchange hash value built from the newly established shared secret value 🎀. The kex algorithm MUST be ecdh-sha2-nistp384, and the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512 ✨.

6.2. DH Key Exchange 🦋

okay so the key exchange kicks off with an SSH_MSG_KEXDH_INIT message 💌 that carries the client's DH exchange value, which is what gets used to build the shared secret.

the server answers that SSH_MSG_KEXDH_INIT with an SSH_MSG_KEXDH_REPLY message. it holds the server's DH exchange value, the server's public host key, and a signature over the exchange hash value, which is made from the brand new shared secret. ✨ the kex algorithm MUST be either diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512. no other choices, bestie 💅

7. Authentication 🔐

7.1. Server Authentication

a signature on the exchange hash value, which comes from the freshly made shared secret, is how the server proves who it is to the client 🫶 servers MUST be authenticated using digital signatures, no exceptions. the public key algorithm implemented MUST be ecdsa-sha2-nistp384 or rsa-sha2-512. for RSA, the public key modulus MUST be 3072 or 4096 bits in size, and clients MUST NOT accept RSA signatures from a public key modulus of any other size. not a single bit off 😤

the following public key algorithms MUST be used:

the client MUST verify that the presented key is a valid authenticator for the server before it checks the server signature 🧐 if it's possible, validation SHOULD be done using certificates. if not, the client MUST validate the presented public key through some other secure, possibly off-line mechanism. and implementations MUST NOT employ a "Trust on First Use (TOFU)" security model, where a client just accepts the first public host key it sees from a server it hasn't verified yet. 🚫 a TOFU setup would let an intermediate adversary pretend to be the server, and that is NOT it, chat 💀

where X.509 v3 Certificates are used, their use MUST comply with [RFC8603] 📜

7.2. User Authentication

the Secure Shell Transport Layer Protocol authenticates the server to the host, but it does not authenticate the user (or the user's host) to the server 🙈 so all users MUST be authenticated, MUST follow [RFC4252], and SHOULD be authenticated using a public key method. users MAY authenticate using passwords. other methods of authentication MUST not be used, including "none" 🚫

when authenticating with a public key, the following public key algorithms MUST be used:

the server MUST verify that the public key is a valid authenticator for the user. if possible, validation SHOULD be done using certificates. otherwise, the server must validate the public key through another secure, possibly off-line mechanism.

where X.509 v3 Certificates are used, their use MUST comply with [RFC8603] 🎀

if you're authenticating with RSA, the client's public key modulus MUST be 3072 or 4096 bits in size, and the server MUST NOT accept signatures from an RSA public key modulus of any other size 🔑

to make client authentication with RSA using SHA-512 work smoothly, clients and servers SHOULD implement the server-sig-algs extension, as specified in [RFC8308] ✨ in that case, the client SHALL include the indicator ext-info-c in the kex_algorithms field of the SSH_MSG_KEXINIT, and the server SHOULD respond with an SSH_MSG_EXT_INFO message containing the server-sig-algs extension. the server MUST list only ecdsa-sha2-nistp384 and/or rsa-sha2-512 as the acceptable public key algorithms in that response 🧚

if you're authenticating by passwords, it is essential that passwords have sufficient entropy to protect against dictionary attacks 🚨 during authentication, the password MUST be protected in the established encrypted communications channel. more guidelines live in [SP80063] 📚

8. Confidentiality and Data Integrity of SSH Binary Packets 🌸

Secure Shell moves data between the client and the server using its own binary packet structure 🎁 that structure is independent of whatever packet structure sits on the underlying data channel. the contents of each binary packet, plus parts of the header, get encrypted, and every packet is authenticated with its own message authentication code. using AES-GCM does both jobs at once: it encrypts the packet and forms a 16-octet authentication tag for data integrity 🔥

8.1. Galois/Counter Mode

using AES-GCM in Secure Shell is described in [RFC5647] 💜 CNSA-compliant SSH implementations MUST support AES-GCM (negotiated as AEAD_AES_GCM_256 or aes256-gcm@openssh; see Section 5) to provide confidentiality and ensure data integrity. no other confidentiality or data integrity algorithms are permitted, so that's the whole menu 🍓

the AES-GCM invocation counter goes up mod 2^64. in other words, after processing a binary packet:

invocation_counter = invocation_counter + 1 mod 2^64

the invocation counter MUST NOT repeat a counter value 🙅‍♀️ never reuse one, periodt.

8.2. Data Integrity

as specified in [RFC5647], all 16 octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet 🛡️ every single octet counts, no skipping.

9. Rekeying 🔁

Section 9 of [RFC4253] lets either the server or the client start a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet" and "change some or all of the [cipher] algorithms during the re-exchange" 🎀 this spec, though, says the same cipher suite has to be used when rekeying. so the cipher algorithms MUST NOT be changed when a rekey happens 🔒

10. Security Considerations 💀

okay, serious moment, bestie 🫶 the security considerations of [RFC4251], [RFC4252], [RFC4253], [RFC5647], and [RFC5656] all apply here. read those, because they're part of the deal and you can't skip them 😭

11. IANA Considerations 🌈

this document has no IANA actions. nothing to register, nothing to update, we are chillin' 😌

12. References 📚

12.1. Normative References

[CNSA]     Committee for National Security Systems, "Use of Public
           Standards for Secure Information Sharing", CNSSP 15,
           October 2016,
           <https://www.cnss.gov/CNSS/Issuances/Policies.cfm>.

[FIPS180]  National Institute of Standards and Technology, "Secure
           Hash Standard (SHS)", FIPS PUB 180-4,
           DOI 10.6028/NIST.FIPS.180-4, August 2015,
           <https://doi.org/10.6028/NIST.FIPS.180-4>.

[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>.

[RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
           Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
           January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
           Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
           January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[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>.

[RFC5647]  Igoe, K. and J. Solinas, "AES Galois Counter Mode for the
           Secure Shell Transport Layer Protocol", RFC 5647,
           DOI 10.17487/RFC5647, August 2009,
           <https://www.rfc-editor.org/info/rfc5647>.

[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>.

[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>.

[RFC8268]  Baushke, M., "More Modular Exponentiation (MODP) Diffie-
           Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
           (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
           <https://www.rfc-editor.org/info/rfc8268>.

[RFC8308]  Bider, D., "Extension Negotiation in the Secure Shell
           (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March
           2018, <https://www.rfc-editor.org/info/rfc8308>.

[RFC8332]  Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in
           the Secure Shell (SSH) Protocol", RFC 8332,
           DOI 10.17487/RFC8332, March 2018,
           <https://www.rfc-editor.org/info/rfc8332>.

[RFC8603]  Jenkins, M. and L. Zieglar, "Commercial National Security
           Algorithm (CNSA) Suite Certificate and Certificate
           Revocation List (CRL) Profile", RFC 8603,
           DOI 10.17487/RFC8603, May 2019,
           <https://www.rfc-editor.org/info/rfc8603>.

12.2. Informative References

[RFC9142]  Baushke, M., "Key Exchange (KEX) Method Updates and
           Recommendations for Secure Shell (SSH)", RFC 9142,
           DOI 10.17487/RFC9142, January 2022,
           <https://www.rfc-editor.org/info/rfc9142>.

[SP800-38D]
           National Institute of Standards and Technology,
           "Recommendation for Block Cipher Modes of Operation:
           Galois/Counter Mode (GCM) and GMAC", NIST Special
           Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November
           2007, <https://doi.org/10.6028/NIST.SP.800-38D>.

[SP80056A] National Institute of Standards and Technology,
           "Recommendation for Pair-Wise Key Establishment Schemes
           Using Discrete Logarithm Cryptography", Revision 3, NIST
           Special Publication 800-56A,
           DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
           <https://doi.org/10.6028/NIST.SP.800-56Ar3>.

[SP80059]  National Institute of Standards and Technology, "Guideline
           for Identifying an Information System as a National
           Security System", NIST Special Publication 800-59,
           DOI 10.6028/NIST.SP.800-59, August 2003,
           <https://doi.org/10.6028/NIST.SP.800-59>.

[SP80063]  National Institute of Standards and Technology, "Digital
           Identity Guidelines", NIST Special Publication 800-63-3,
           DOI 10.6028/NIST.SP.800-63-3, June 2017,
           <https://doi.org/10.6028/NIST.SP.800-63-3>.

Authors' Addresses 👩‍💻

Nicholas Gajcowski
National Security Agency
Email: nhgajco@uwe.nsa.gov

Michael Jenkins
National Security Agency
Email: mjjenki@cyber.nsa.gov

that's the whole spec, bestie! 🌈💖 you made it through 🫶✨

📦 where this page comes from