Commercial National Security Algorithm (CNSA) Suite Profile for SSH

Introduction This document specifies a profile of SSH to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite . This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS) that employ SSH. This profile is also appropriate for all other US Government systems that process high-value information, and is made publicly available for use by developers and operators of these and any other system deployments. This document does not define any cryptographic algorithm, and does not specify how to use any cryptographic algorithm not currently supported by SSH; instead, it profiles CNSA 2.0-compliant conventions for SSH, and uses algorithms already specified for use in SSH that are also allowed by the CNSA Suite 2.0. This document applies to all CNSA Suite solutions that make use of SSH. The reader is assumed to have familiarity with , , . This memo is not an IETF standard, and has not been shown to have IETF community consensus. [ED NOTE: This document uses guidance from , and to specify use of ML-KEM and ML-DSA in SSH, respectively. We note that the drafts are not yet RFCs, and we may need to adjust this text accordingly based on the progress of these documents.]

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. Normative language does not apply beyond the scope of this profile. This is a profile of SSH . Therefore, the requirements language in this memo may be different than that found in the underlying standards. All references to "CNSA" in this document refer to CNSA 2.0 , unless stated otherwise.

The Commercial National Security Algorithm Suite The CNSA Suite is the set of approved commercial algorithms that can be used by vendors and IT users to meet cybersecurity and interoperability requirements for NSS. The initial suite of CNSA Suite algorithms, Suite B, established a baseline for use of commercial algorithms to protect classified information. The following suite, CNSA 1.0, served as a bridge between the original set and a fully quantum-resistant cryptographic capability. The current suite, CNSA 2.0, seeks to provide fully quantum-resistant protection . This profile uses CNSA 2.0 compliant algorithms: ML-DSA-87 for signing, and ML-KEM-1024 for key establishment. ML-DSA-87 and ML-KEM-1024 together with SHA384, SHA512, AES-256, LMS, and XMSS comprise the CNSA Suite 2.0. The NSA is authoring a set of RFCs, including this one, to provide updated guidance for using the CNSA 2.0 Suite in certain 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 NSS.

CNSA 2.0 Compliance The purpose of this document is to provide guidance for CNSA-compliant implementations of the Secure Shell (SSH) protocol . 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 in NSS. An implementation must be validated by the appropriate authority before such usage is permitted.

CNSA 2.0 Suite 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 algorithms provided in the name-lists specified in SSH_MSG_KEXINIT are listed in order of preference. CNSA-compliant implementations MUST list the following algorithms as the first (most preferred) algorithms in their respective name-lists. Key Exchange Algorithms: mlkem1024-sha384 (Section 3.1.3 ), , Public Key Algorithms: ML-DSA-87 (ssh-mldsa87) (Section 8 ), Encryption Algorithms: AEAD_AES_256_GCM aes256-gcm@openssh.com MAC Algorithms (both client_to_server and server_to_client): AEAD_AES_256_GCM Any algorithms not appearing in the above list MUST NOT be negotiated for use in a CNSA-compliant implementation of SSH. The procedures for applying the negotiated algorithms are given in the following sections.

Transport Layer

SSH_MSG_KEXINIT Overview The server and client use the SSH_MSG_KEXINIT exchange [, Section 7.1] to negotiate the following name-lists:

kex_algorithms
server_host_key_algorithms
encryption_algorithms (client_to_server and server_to_client)
mac_algorithms (client_to_server and server_to_client

The kex_algorithms name-list is used to negotiate key exchange algorithms and hash used in the exchange hash. This is discussed further in Section 5.2. The server_host_key_algorithms name-list is used to identify the algorithms for which the server has host keys, and which the client is willing to accept. This is discussed in Section 5.3. The encryption_algorithms and mac_algorithms name-lists are used to negotiate symmetric encryption and MAC algorithm. These name-lists are discussed in more detail in Section 5.4.

Key Exchange This document does not preclude implementations that contain algorithms other than those specified in CNSA 2.0, such as the mandatory-to-implement algorithms listed in the Key Exchange Method Names (also known as those containing "MUST" in the OK to Implement column). However, algorithms that are not CNSA compliant must not be negotiated and used in a CNSA-compliant connection. A CNSA compliant connection MUST NOT allow the reuse of ephemeral/exchange values in a key exchange algorithm due to security concerns related to this practice. In accordance with , an ephemeral private key shall be used in exactly one key establishment transaction and shall be destroyed (zeroized) as soon as possible. The key exchange algorithm and hash is determined by the kex_algorithms name-list exchanged in the SSH_MSG_KEXINIT packets [ Section 7.1], as described above. For CNSA compliant connections, the following MUST be negotiated in the kex_algorithms name-list of SSH_MSG_KEXINIT, and MUST be the first (most preferred) choice in the list: Key Exchange: ML-KEM-1024 MUST be used to establish a shared secret value between the client and the server. Any algorithm other than ML-KEM-1024 MUST NOT be negotiated for key exchange in a CNSA-compliant connection. Hash Algorithm: The exchange hash MUST be generated using either SHA-384 or SHA-512, or the connection MUST be terminated. Any algorithm other than SHA-384 or SHA-512 MUST NOT be negotiated for hashing in a CNSA-compliant connection. [ED NOTE: CNSA 2.0 compliance requires the use of ML-KEM-1024 for key establishment, and SHA-384 or SHA-512 for hashing. does not provide guidance for use of ML-KEM in SSH, but recently posted details guidance on the technical function necessary to include ML-KEM in SSH, including defining SSH_MSG_KEX_KEM_INIT and SSH_MSG_KEX_KEM_REPLY. This document is subject to change as progresses.] The key exchange is started by the client and server sending an SSH_MSG_KEX_KEM_INIT message. In SSH_MSG_KEX_KEM_INIT, both the client and server MUST include mlkem1024-sha384 in the kex_algorithms name-list, and mlkem1024-sha384 MUST be the first (most preferred) algorithm in the list. For use of ML-KEM, the client sends the public key output, PK, of the ML-KEM KeyGen algorithm in SSH_MSG_KEX_KEM_INIT . The server then sends its reply, SSH_MSG_KEX_KEM_REPLY , which includes the ciphertext output, CT, of the ML-KEM Encaps algorithm, and the server's ephemeral public host key (or certificate). The exchange hash is then generated and signed by the server. Note that details several checks that must also be performed for the ML-KEM algorithm components.

Server Host Authentication For server host authentication, the server sends the client the server_host_key_algorithms name-list packet of the SSH_MSG_KEXINIT message. For CNSA compliant connections, ML-DSA-87 MUST be listed as the first (most preferred) algorithm in server_host_key_algorithms. The server generates the exchange hash H as defined in Section 5.2 and signs it using its private host key. CNSA 2.0 compliance requires the use of ML-DSA-87 for signatures. Authentication by the client is a two-step process of validating the presented public key and verifying the signature. By default, the server sends a raw public key, but it could be an X.509 certificate. For CNSA compliant connections, servers MUST be authenticated using digital signatures. The public key algorithm implemented MUST be ML-DSA-87. Where possible, public keys SHOULD be validated with certificates, otherwise, the client MUST validate the presented public key through another secure, possibly offline, mechanism. CSNA compliant 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. If raw public key format is used, the trust anchor MUST be securely distributed. Where X.509 certificates are used, they must comply with .

Encryption One of the following sets MUST be used for the encryption_algorithms and mac_algorithms name-lists in SSH_MSG_KEXDH. Either set MAY be used for each direction (client_to_server and server_to_client): 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 := {} For encryption, use of AES-GCM MUST meet the requirements 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 in aes256-gcm@openssh.com). In addition, the AES-GCM invocation counter is incremented mod 2^64: invocation_counter = invocation_counter + 1 mod 2^64 CNSA compliant implementations MUST NOT repeat a counter value, and MUST ensure the counter is properly incremented after processing a binary packet.

User Authentication The user authentication protocol for authenticating the client to the server is specified in . For CNSA compliant connections, all users MUST be authenticated as outlined in , and SHOULD be authenticated using a public key method. Specifically, all users MUST be authenticated and SHOULD be authenticated using public key. Users MAY be authenticated using passwords subject to requirements in this section. CNSA compliant connections MUST NOT use other methods of authentication, including hostbased authentication, keyboard-interactive authentication, or "none". When authenticating with public key, CNSA compliant connects MUST use ML-DSA-87. The server MUST verify that the public key is a valid authenticator for the user. Public key authentication is a two-step process of validating the public key and verifying the signature. In order for the server to verify the client, it must have a copy of the client's public key in advance. If possible, validation SHOULD be done using certificates. Otherwise, the server must validate the public key through another secure, possibly offline, mechanism. When certificates are used, the file can list the CA key preceded by the string "@cert-authority" instead of the user key. When algorithms are negotiated in SSH_MSG_KEXINIT, the SSH protocol defined in does not require the server to declare its supported algorithms for user host key, and the server will reject public key authentication requests for key types it does not support. For CNSA compliant connections, the client MUST use ML-DSA-87. Recent OpenSSH implementations do require the server to declare its supported algorithms via mechanisms detailed in . The client includes "ext-info-c" in the kex_algorithms field of the SSH_MSG_KEXINIT message, to indicate that it wants to negotiate an SSH extension. In OpenSSH versions 9.5 and 9.6, "ext-info-c" is automatically appended and forces the server to list the user authentication methods it supports. CNSA compliant servers MUST list ML-DSA-87. 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 guidance on password requirements are provided in .

Confidentiality and Data Integrity Use of AES-GCM in SSH is detailed in . CNSA compliant implementations MUST support AES-GCM as described in SECTION, to provide confidentiality and ensure data integrity. No other confidentiality or data integrity algorithms are permitted. As specified in , all 16 octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet.

Rekeying Section 9 of 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 reexchange". For CNSA compliant implementations, the same cipher suite MUST be employed when rekeying; that is, the cipher algorithms MUST NOT be changed when a rekey occurs.

Security Considerations Most of the security considerations for this document are described in , , . Additional security considerations for the use of ML-KEM in SSH can be found in .

IANA Considerations This document has no IANA actions