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

This document specifies conventions for using the United States National Security Agency's CNSA Suite algorithms with 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 that employ IPSec. 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.

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 National Security Agency (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 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. NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their IA interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future. 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.

Several 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 MAC algorithms (both client_to_server and server_to_client) AEAD_AES_256_GCM The purpose of this document is to draw upon all of these documents to provide guidance for CNSA compliant implementations of Secure Shell. 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.

The approved CNSA hash function for all purposes is SHA-384, as defined in . However, SHA-512 (sha2-512) is recommended for the Diffie-Hellman kex algorithms and for RSA public key algorithms due to lack of specification of SHA-384 in and . Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used.

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. 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. This allows for the possibility of a man in the middle attack, where an attacker can present itself to the client as the server. The public host keys presented MUST be verified as belonging to the presenting party before the signature is accepted. This certification SHOULD be done using certificates, provided the use of certificates has been approved for that environment. Otherwise, the user MUST validate the presented public key (and/or certificate) by some other means, possibly through an offline mechanism. Certificates MUST be X.509v3 certificates and their use MUST comply with .

As 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 are determined by the exchange of SSH_MSG_KEXINIT between the client and the server. The SSH_MSG_KEXINIT name lists can be used to constrain the choice of cryptographic algorithms in accordance with the guidance given in Section 2. One of the following kex_algorithms MUST be used. ecdh-sha2-nistp384 diffie-hellman-group15-sha512 diffie-hellman-group16-sha512 One of the name lists from the following list MUST be used for the encryption algorithms and mac algorithm. This option MUST be used. encryption_algorithm name_list := { AEAD_AES_256_GCM } mac_algorithm name_list := { AEAD_AES_256_GCM } One of the following public key algorithms MUST be used. rsa-sha2-512 ecdsa-sha2-nistp384

Either ECDH or DH MUST be used to establish a shared secret value between the client and the server. A signature on the exchange hash value derived from the newly established shared secret value is used to authenticate the server to the client. The key exchange to be used is determined by the name lists exchanged in the SSH_MSG_KEXINT packets as described in . 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 must be used in exactly one key establishment transaction and must be destroyed (zeroized) as soon as possible. Section 5.8 of states that such shared secrets must be destroyed (zeroized) immediately after its use. CNSA compliant systems MUST follow these mandates.

The key exchange begins with the SSH_MSG_KEXECDH_INIT message which contains the client's ephemeral public key used to generate a shared secret value. The server responds to a SSH_MSG_KEXECDH_INIT message with a SSH_MSG_KEXECDH_REPLY message which 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 public key algorithm MUST be ecdsa-sha2-nistp384 or rsa-sha2-512.

The key exchange begins with the SSH_MSG_KEXDH_INIT message which contains the client's diffie-hellman exchange value used to generate a shared secret value. The server responds to a SSH_MSG_KEXDH_INIT message with a SSH_MSG_KEXDH_REPLY message. The SSH_MSG_KEXDH_REPLY contains the server's diffie-hellman 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 public key algorithm MUST be ecdsa-sha2-nistp384 or rsa-sha2-512.

The 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 presented key is a valid authenticator for the user. This SHOULD be done using certificates. Certificates MUST be X.509v3 certificates and 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. 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 .

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. AES GCM will both encrypt the packet and form a 16-octet authentication tag to ensure data integrity.

Use of AES GCM in Secure Shell is described in . CNSA complaint SSH implementations MUST support AEAD_AES_GCM_256 to provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted. The AES GCM invocation counter is incremented mod 2^64. That is, after processing a binary packet: invocation_counter = invocation_counter + 1 mod 2^64 The invocation counter MUST NOT repeat a counter value.

As specified in , all 16 octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet.

Secure Shell allows either the server or client to request that the Secure Shell connection be rekeyed. The cipher suite being employed MUST NOT be changed when a rekey occurs.

The security considerations of , , , , and apply.

No IANA actions are requested.