Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH)National Security Agencynhgajco@uwe.nsa.govNational Security Agencymjjenki@cyber.nsa.govNSSremote administrationThe United States Government has published the National Security
Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which
defines cryptographic algorithm policy for national security
applications. This document specifies the conventions for using the
United States National Security Agency's CNSA Suite algorithms with the
Secure Shell Transport Layer Protocol and the Secure Shell
Authentication Protocol. It applies to the capabilities, configuration,
and operation of all components of US National Security Systems
(described in NIST Special Publication 800-59) that employ Secure Shell
(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.
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
.
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
() 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.
Table of Contents
. Introduction
. Terminology
. The Commercial National Security Algorithm Suite
. CNSA and Secure Shell
. Security Mechanism Negotiation and Initialization
. Key Exchange
. ECDH Key Exchange
. DH Key Exchange
. Authentication
. Server Authentication
. User Authentication
. Confidentiality and Data Integrity of SSH Binary Packets
. Galois/Counter Mode
. Data Integrity
. Rekeying
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Authors' Addresses
IntroductionThis document specifies conventions for using the United States
National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure Shell Authentication
Protocol . It applies to the
capabilities, configuration, and operation of all components of US
National Security Systems (described in NIST Special Publication 800-59
) 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.
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 when, and only when, they appear in all capitals, as
shown here.
The Commercial National Security Algorithm SuiteThe 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.CNSA and Secure ShellSeveral RFCs have documented how each of the CNSA components are to be integrated into Secure Shell (SSH):
kex algorithms:
ecdh-sha2-nistp384
diffie-hellman-group15-sha512
diffie-hellman-group16-sha512
public key algorithms:
ecdsa-sha2-nistp384
rsa-sha2-512
encryption algorithms (both client_to_server and server_to_client):
AEAD_AES_256_GCM
message authentication code (MAC) algorithms (both client_to_server and server_to_client):
AEAD_AES_256_GCM
While the approved CNSA hash function for all purposes is SHA-384, as defined in , commercial products are more likely to incorporate the kex algorithms and public key algorithms based on SHA-512 (sha2-512), which are defined in and . 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 , 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 , 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, fails to specify that the AES-GCM invocation counter is incremented mod 264. CNSA implementations MUST ensure the counter never repeats and is properly incremented after processing a binary packet:invocation_counter = invocation_counter + 1 mod 264.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.
Security Mechanism Negotiation and InitializationAs described in , 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 . While 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:
ecdh-sha2-nistp384
diffie-hellman-group15-sha512
diffie-hellman-group16-sha512
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 } orencryption_algorithm_name_list := { aes256-gcm@openssh.com }mac_algorithm_name_list := {}One of the following public key algorithms MUST be used:
rsa-sha2-512
ecdsa-sha2-nistp384
The procedures for applying the negotiated algorithms are given in the following sections.
Key ExchangeThe 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 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 states that such shared secrets shall be destroyed (zeroized) immediately after its use. CNSA-compliant systems MUST follow these mandates.
ECDH Key ExchangeThe key exchange begins with the SSH_MSG_KEXECDH_INIT message that contains the client's ephemeral public key used to generate a shared secret value.
The server responds to an SSH_MSG_KEXECDH_INIT message with an SSH_MSG_KEXECDH_REPLY message that contains the server's ephemeral public key, the server's public host key, and a signature of the exchange hash value formed 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.
DH Key ExchangeThe key exchange begins with the SSH_MSG_KEXDH_INIT message that contains the client's DH exchange value used to generate a shared secret value.
The server responds to an SSH_MSG_KEXDH_INIT message with an SSH_MSG_KEXDH_REPLY message that contains the server's DH exchange value, the server's public host key, and a signature of the exchange hash value formed from the newly established shared secret value. The kex algorithm MUST be one of diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512.
AuthenticationServer AuthenticationA signature on the exchange hash value derived from the newly established shared secret value is used to authenticate the server to the client. Servers MUST be authenticated using digital signatures. The public key algorithm implemented MUST be ecdsa-sha2-nistp384 or rsa-sha2-512. The RSA public key modulus MUST be 3072 or 4096 bits in size; clients MUST NOT accept RSA signatures from a public key modulus of any other size.
The following public key algorithms MUST be used:
ecdsa-sha2-nistp384
rsa-sha2-512
The client MUST verify that the presented key is a valid authenticator for the server before verifying the server signature. If possible, validation SHOULD be done using certificates. Otherwise, the client MUST validate the presented public key through some other secure, possibly off-line mechanism. Implementations MUST NOT employ a "Trust on First Use (TOFU)" security model where a client accepts the first public host key presented to it from a not-yet-verified server. Use of a TOFU model would allow an intermediate adversary to present itself to the client as the server.
Where X.509 v3 Certificates are used, their use MUST comply with .User AuthenticationThe Secure Shell Transport Layer Protocol authenticates the server to the host but does not authenticate the user (or the user's host) to the server. All users MUST be authenticated, MUST follow , 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 public key, the following public key algorithms MUST be used:
ecdsa-sha2-nistp384
rsa-sha2-512
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 .
If 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 facilitate client authentication with RSA using SHA-512, clients and servers SHOULD implement the server-sig-algs extension, as specified in . In that case, in the SSH_MSG_KEXINIT, the client SHALL include the indicator ext-info-c to the kex_algorithms field, 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 this response.
If 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. Additional guidelines are provided in .
Confidentiality and Data Integrity of SSH Binary PacketsSecure 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.
Galois/Counter ModeUse of AES-GCM in Secure Shell is described in . CNSA-complaint SSH implementations MUST support AES-GCM (negotiated as AEAD_AES_GCM_256 or aes256-gcm@openssh; see ) to provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted.
The AES-GCM invocation counter is incremented mod 264. That is, after processing a binary packet:invocation_counter = invocation_counter + 1 mod 264The invocation counter MUST NOT repeat a counter value.Data IntegrityAs specified in , all 16 octets of the
authentication tag MUST be used as the SSH data integrity value of the SSH
binary packet.Rekeying 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.
Security ConsiderationsThe security considerations of , , , , and
apply.IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesUse of Public Standards for Secure Information SharingCommittee for National Security SystemsSecure Hash Standard (SHS)National Institute of Standards and TechnologyKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Secure Shell (SSH) Protocol ArchitectureThe Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. [STANDARDS-TRACK]The Secure Shell (SSH) Authentication ProtocolThe Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]The Secure Shell (SSH) Transport Layer ProtocolThe Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]AES Galois Counter Mode for the Secure Shell Transport Layer ProtocolSecure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH Transport Layer Protocol. This memo provides information for the Internet community.Elliptic Curve Algorithm Integration in the Secure Shell Transport LayerThis document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key.Extension Negotiation in the Secure Shell (SSH) ProtocolThis memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange.Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) ProtocolThis memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections.Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) ProfileThis document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It 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.Informative ReferencesKey Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462.Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMACNational Institute of Standards and TechnologyRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm CryptographyNational Institute of Standards and TechnologyRevision 3Guideline for Identifying an Information System as a National Security SystemNational Institute of Standards and TechnologyDigital Identity GuidelinesNational Institute of Standards and TechnologyAuthors' AddressesNational Security Agencynhgajco@uwe.nsa.govNational Security Agencymjjenki@cyber.nsa.gov