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

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9212.¶

Copyright Notice

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) 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.¶

1. Introduction

This document specifies conventions for using the United States National Security Agency's CNSA Suite algorithms [CNSA] with the Secure Shell Transport Layer Protocol [RFC4253] and the Secure Shell Authentication Protocol [RFC4252]. It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59 [SP80059]) that employ SSH. This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.¶

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

3. The Commercial National Security Algorithm Suite

The NSA profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for US Government National Security Systems. To this end, it publishes guidance both to assist with the US Government's transition to new algorithms and to provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration.¶

Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their information assurance interoperability requirements using current cryptography. The purpose behind this flexibility is to avoid vendors and customers making two major transitions (i.e., to elliptic curve cryptography and then to post-quantum cryptography) in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.¶

The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect Internet traffic and data-at-rest for US Government National Security Systems.¶

4. CNSA and Secure Shell

Several RFCs have documented how each of the CNSA components are to be integrated into Secure Shell (SSH):¶

kex algorithms:¶

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):¶

While the approved CNSA hash function for all purposes is SHA-384, as defined in [FIPS180], commercial products are more likely to incorporate the kex algorithms and public key algorithms based on SHA-512 (sha2-512), which are defined in [RFC8268] and [RFC8332]. Therefore, the SHA-384-based kex and public key algorithms SHOULD be used; SHA-512-based algorithms MAY be used. Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used.¶

Use of the Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) shall meet the requirements set forth in [SP800-38D], with the additional requirements that all 16 octets of the authentication tag MUST be used as the SSH data integrity value and that AES is used with a 256-bit key. Use of AES-GCM in SSH should be done as described in [RFC5647], with the exception that AES-GCM need not be listed as the MAC algorithm when its use is implicit (such as done in aes256-gcm@openssh.com). In addition, [RFC5647] fails to specify that the AES-GCM invocation counter is incremented mod 2⁶⁴. CNSA implementations MUST ensure the counter never repeats and is properly incremented after processing a binary packet:¶

invocation_counter = invocation_counter + 1 mod 2⁶⁴.¶

The purpose of this document is to draw upon all of these documents to provide guidance for CNSA-compliant implementations of Secure Shell. Algorithms specified in this document may be different from mandatory-to-implement algorithms; where this occurs, the latter will be present but not used. Note that, while compliant Secure Shell implementations MUST follow the guidance in this document, that requirement does not in and of itself imply that a given implementation of Secure Shell is suitable for use national security systems. An implementation must be validated by the appropriate authority before such usage is permitted.¶

5. Security Mechanism Negotiation and Initialization

As described in Section 7.1 of [RFC4253], the exchange of SSH_MSG_KEXINIT between the server and the client establishes which key agreement algorithm, MAC algorithm, host key algorithm (server authentication algorithm), and encryption algorithm are to be used. This section specifies the use of CNSA components in the Secure Shell algorithm negotiation, key agreement, server authentication, and user authentication.¶

The choice of all but the user authentication methods is determined by the exchange of SSH_MSG_KEXINIT between the client and the server.¶

The kex_algorithms name-list is used to negotiate a single key agreement algorithm between the server and client in accordance with the guidance given in Section 4. While [RFC9142] establishes general guidance on the capabilities of SSH implementations and requires support for "diffie-hellman-group14-sha256", it MUST NOT be used. The result MUST be one of the following kex_algorithms, or the connection MUST be terminated:¶

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 (i.e., client_to_server or server_to_client), but the result must be the same (i.e., use of 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 given in the following sections.¶

6. Key Exchange

The key exchange to be used is determined 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 establish a shared secret value between the client and the server.¶

A compliant system MUST NOT allow the reuse of ephemeral/exchange values in a key exchange algorithm due to security concerns related to this practice. Section 5.6.3.3 of [SP80056A] states that 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] states that such shared secrets shall be destroyed (zeroized) immediately after its use. CNSA-compliant systems MUST follow these mandates.¶

7. Authentication

8. Confidentiality and Data Integrity of SSH Binary Packets

Secure Shell transfers data between the client and the server using its own binary packet structure. The SSH binary packet structure is independent of any packet structure on the underlying data channel. The contents of each binary packet and portions of the header are encrypted, and each packet is authenticated with its own message authentication code. Use of AES-GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity.¶

9. Rekeying

Section 9 of [RFC4253] allows either the server or the client to initiate a "key re-exchange ... by sending an SSH_MSG_KEXINIT packet" and to "change some or all of the [cipher] algorithms during the re-exchange". This specification requires the same cipher suite to be employed when rekeying; that is, the cipher algorithms MUST NOT be changed when a rekey occurs.¶

10. Security Considerations

The security considerations of [RFC4251], [RFC4252], [RFC4253], [RFC5647], and [RFC5656] apply.¶

11. IANA Considerations

This document has no IANA actions.¶

Authors' Addresses