Network Working Group A. Becker Internet-Draft C. Wynn Obsoletes: 9212 (if approved) NSA Intended status: Informational 3 March 2025 Expires: 4 September 2025 Commercial National Security Algorithm (CNSA) Suite Profile for SSH draft-becker-cnsa2-ssh-profile-00 Abstract This document defines a base profile of SSH for use with the U.S. Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for U.S. national security applications. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This profile is made publicly available for use by developers and operators of these and any other system deployments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Becker & Wynn Expires 4 September 2025 [Page 1] Internet-Draft CNSA2 SSH Profile March 2025 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Commercial National Security Algorithm Suite . . . . . . 3 4. CNSA 2.0 Compliance . . . . . . . . . . . . . . . . . . . . . 4 4.1. CNSA 2.0 Suite . . . . . . . . . . . . . . . . . . . . . 4 5. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. SSH_MSG_KEXINIT Overview . . . . . . . . . . . . . . . . 5 5.2. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Server Host Authentication . . . . . . . . . . . . . . . 7 5.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 8 6. User Authentication . . . . . . . . . . . . . . . . . . . . . 8 7. Confidentiality and Data Integrity . . . . . . . . . . . . . 9 8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document specifies a profile of SSH [RFC4253] to comply with the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) 2.0 Suite [annccnsa]. This profile applies to the capabilities, configuration, and operation of all components of U.S. National Security Systems (NSS) that employ SSH. U.S. National Security Systems are described in NIST Special Publication 800-59 [SP80059]. This profile is also appropriate for all other U.S. 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. The reader is assumed to have familiarity with [RFC4253]. [ED NOTE: This document uses some details from [I-D.harrison-mlkem-ssh] to specify use of ML-KEM in SSH. We note that the draft is not yet an RFC, and we may need to adjust this text accordingly based on the progress of that document.] Becker & Wynn Expires 4 September 2025 [Page 2] Internet-Draft CNSA2 SSH Profile March 2025 [ED NOTE: This document may change to use guidance from work specifying the use of ML-KEM and ML-DSA in SSH.] All usage of the term "CNSA" in this document refers to CNSA 2.0 [annccnsa], unless otherwise stated. 2. Terminology Text from RFC2119. 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] if and only if they appear in all capitals, as shown here. All MUST-level requirements of [RFC4253], apply throughout this profile; they are generally not repeated. In cases where a MUST- level requirement is repeated for clarity, the source document prevails. This profile may contain changes that elevate or downgrade some SHOULD- or MUST-level options from a specified RFC. All options from [RFC4253], that are not mentioned in this profile remain at the requirement level of the reference. All usage of the term "CNSA" in this document refers to CNSA 2.0 [annccnsa], unless otherwise stated. 3. The Commercial National Security Algorithm Suite The National Security Agency (NSA) profiles commercial cryptographic algorithms and protocols as part of its mission to support secure, interoperable communications for U.S. Government National Security Systems (NSS). To this end, it publishes guidance both to assist with the U.S. Government transition to new algorithms and to provide vendors - and the internet community in general - with information concerning their proper use and configuration within the scope of U.S. Government National Security Systems. The Commercial National Security Algorithm (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, establishes fully quantum-resistant protection [annccnsa]. Becker & Wynn Expires 4 September 2025 [Page 3] Internet-Draft CNSA2 SSH Profile March 2025 Pursuant to the National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems [NSM-10], the National Institute for Standards and Technology (NIST) selected several quantum-resistant, or post-quantum, asymmetric algorithms for standardization. From these, NSA has included two in CNSA 2.0: ML-DSA-87 [FIPS204] for signing, and ML-KEM-1024 [FIPS203] 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 U.S. Government National Security Systems. 4. CNSA 2.0 Compliance The purpose of this document is to provide guidance for CNSA- compliant implementations of the Secure Shell (SSH) protocol [RFC4253]. 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. 4.1. 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: ML-KEM-1024-sha384 [FIPS203], [SHS] [ED NOTE: Use of ML-KEM is specified in [I-D.harrison-mlkem-ssh], and this draft only details use for ML-KEM-1024-sha384. CNSA 2.0 also allows SHA-512 to be used for the exchange hash, but at the time of writing, only ML-KEM-1024 with SHA-382 is specified in [I-D.harrison-mlkem-ssh]. If SHA-512 becomes available as an option, it will be a CNSA compliant option.] Public Key Algorithms: Becker & Wynn Expires 4 September 2025 [Page 4] Internet-Draft CNSA2 SSH Profile March 2025 ML-DSA-87 [FIPS204] [ED NOTE: There is no formal specification for use of ML-DSA in SSH, this draft will be updated as necessary guidance is established.] Encryption Algorithms: AEAD_AES_256_GCM [RFC5647] aes256-gcm@openssh.com MAC Algorithms (both client_to_server and server_to_client): AEAD_AES_256_GCM [RFC5647] 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. 5. Transport Layer 5.1. SSH_MSG_KEXINIT Overview The server and client use the SSH_MSG_KEXINIT exchange [RFC4253, 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. Becker & Wynn Expires 4 September 2025 [Page 5] Internet-Draft CNSA2 SSH Profile March 2025 5.2. 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 containinng "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 [SP80056A], 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 [RFC 4253 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. [RFC9142] does not provide guidance for use of ML-KEM in SSH, but recently posted [I-D.harrison-mlkem-ssh] details guidance on the technical function necessary to include ML-KEM in SSH. Currently, the kex message exchange requires use of SSH_MSG_KEXDH_INIT [RFC4253], or SSH_MSG_ECDH_INIT [RFC5656], and the details are given in that document. This document is subject to change as [I-D.harrison-mlkem-ssh] progresses. ] The key exchange is started by the client and server sending an SSH_MSG_KEXINIT message. In SSH_MSG_KEXINIT, both the client and server MUST include ML-KEM-1024-sha384 [I-D.harrison-mlkem-ssh] in the kex_algorithms name-list, and ML-KEM-1024-sha384 MUST be the first (most preferred) algorithm in the list. Becker & Wynn Expires 4 September 2025 [Page 6] Internet-Draft CNSA2 SSH Profile March 2025 For use of ML-KEM, the client sends the public key output, PK, of the ML-KEM KeyGen algorithm in a following message. The server then sends its reply message, which includes the ciphertext output, CT, of the ML-KEM Encaps algorithm, and the server’s ephemeral public host key. The exchange hash is then generated and signed by the server. Note that [I-D.harrison-mlkem-ssh] details several checks that must also be performed for the ML-KEM algorithm components. 5.3. 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. [ED NOTE: There is no formal specification for use of ML-DSA in SSH, this draft will be updated as necessary guidance is established.] 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 [RFC8603]. Details on CNSA compliance and certificates can be found in [I-D.jenkins-cnsa2-pkix-profile]. Becker & Wynn Expires 4 September 2025 [Page 7] Internet-Draft CNSA2 SSH Profile March 2025 5.4. 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[SP80038D], 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 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. 6. User Authentication The user authentication protocol for authenticating the client to the server is specified in [RFC4252]. For CNSA compliant connections, all users MUST be authenticated as outlined in [RFC4252], and SHOULD be authenticated using a public key method. Specifically, CNSA compliant connections MUST NOT use password authentication, 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 Becker & Wynn Expires 4 September 2025 [Page 8] Internet-Draft CNSA2 SSH Profile March 2025 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 [RFC 4253] 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 [RFC 8308]. 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 support. CNSA compliant servers MUST list ML-DSA_87. 7. Confidentiality and Data Integrity Use of AES-GCM in SSH is detailed in [RFC5647]. 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 [RFC5647], all 16 octets of the authentication tag MUST be used as the SSH data integrity value of the SSH binary packet. 8. 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 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. 9. Security Considerations Most of the security considerations for this document are described in [RFC4253], [RFC5647], [RFC4252]. Additional security considerations for the use of ML-KEM in SSH can be found in [I-D.harrison-mlkem-ssh]. Becker & Wynn Expires 4 September 2025 [Page 9] Internet-Draft CNSA2 SSH Profile March 2025 10. IANA Considerations This document has no IANA actions 11. References [AES] National Institute of Standards and Technology, "Announcing the ADVANCED ENCRYPTION STANDARD (AES)", FIPS 197, DOI 10.6028/NIST.FIPS.197, November 2001, . [annccnsa] National Security Agency, "Announcing the Commercial National Security Algorithm Suite 2.0", September 2022, . [FIPS203] National Institute of Standards and Technology (2024), "Module-Lattice-Based Key-Encapsulation Mechanism Standard", (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS), NIST FIPS 203, . [FIPS204] National Institute of Standards and Technology (2024), "Module-Lattice-Based Digital Signature Standard", (Department of Commerce, Washington, D.C.), Federal Information Processing Standards Publication (FIPS), NIST FIPS 204, . [GCM] Dworkin, M., "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, . [I-D.harrison-mlkem-ssh] Harrison, A., "Module-Lattice Key Exchange in SSH", January 2025, . [I-D.jenkins-cnsa2-pkix-profile] Jenkins, M. and A. Becker, "Commercial National Security Algorithm Suite Certificate and Certificate Revocation List Profile", January 2025, . Becker & Wynn Expires 4 September 2025 [Page 10] Internet-Draft CNSA2 SSH Profile March 2025 [NSM-10] United States, The White House, "National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems", NSM 10, May 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [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, . [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9142] Baushke, M., "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)", RFC 9142, DOI 10.17487/RFC9142, January 2022, . Becker & Wynn Expires 4 September 2025 [Page 11] Internet-Draft CNSA2 SSH Profile March 2025 [SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, FIPS PUB 180-4, August 2015, . [SP80038D] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, NIST Special Publication 800-38D", Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, >. [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", Special Publication 800-56A, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, >. [SP80059] National Institute of Standards and Technology, "Guideline for Identifying an Information System as a National Security System", Special Publication 59, DOI 10.6028/NIST.SP.800-59, August 2003, . Authors' Addresses Alison Becker National Security Agency Email: aebecke@uwe.nsa.gov Casey Wynn National Security Agency Email: cwwynn@uwe.nsa.gov Becker & Wynn Expires 4 September 2025 [Page 12]