Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec

Introduction This document specifies an Internet Protocol Security (IPsec) profile 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 IPsec. 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 specify how to use any cryptographic algorithm not currently supported by IPsec; instead, it profiles CNSA 2.0-compliant conventions for IPsec, and it uses only algorithms in the CNSA 2.0 suite already specified for use by IPsec. This memo is not an IETF standard, and has not been shown to have IETF community consensus.

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. AES: Advanced Encryption Standard DH: Diffie-Hellman key establishment ECDH: Elliptic Curve Diffie-Hellman PSK/PPK: Pre-Shared Key/Post-Quantum Pre-Shared Key; in this document, used interchangeably ML-KEM: Module-Lattice-Based Key Encapsulation Mechanism, defined in ML-DSA: Module-Lattice-Based Digital Signature Algorithm, defined in

The Commercial National Security Algorithm Suite 2.0 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 transitioning the United States Government 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 US Government National Security Systems. 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 first suite of CNSA Suite algorithms, "Suite B", established a baseline for use of commercial algorithms to protect classified information. The next suite, "CNSA 1.0", served as a bridge between the original set and a fully post-quantum cryptographic capability. The current suite, "CNSA 2.0", seeks to provide fully quantum-resistant protection . The National Institute for Standards and Technology (NIST) has standardized several post-quantum asymmetric algorithms. From these, NSA has selected two: ML-DSA-87 for signing and ML-KEM-1024 for key establishment. With SHA-384 (preferred, or alternatively SHA-512), AES-256, and LMS/XMSS, these comprise the CNSA Suite 2.0. The CNSA Suite was selected by NSA for protection of US national security information based on factors including security, performance, data value and retention requirements, advanced threat actors, and certification process. This suite will not be appropriate for all use cases; data owners are encouraged to perform their own risk assessments and consult with their data protection systems providers. The NSA is authoring a set of RFCs, including this one, to provide updated guidance for using CNSA 2.0 algorithms 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 National Security Systems.

Deviation from CNSA 2.0 Suite for IKEv2 While this profile requires use of CNSA 2.0 compliant algorithms, it also specifies key establishment algorithms allowed by the CNSA 1.0 IPsec profile : ECDH with curve P-384 and DH with prime modulus of 3072 bits or 4096 bits . If ML-KEM-1024 were used in the IKE_SA_INIT exchange, the sizes of its public key and ciphertext would cause the initiator and responder messages to exceed the typical path MTU and necessitate in IP-level fragmentation, which can present operational challenges and prevent the establishment of a connection. To address this issue, enables peers to perform multiple key exchanges. While the cryptographic content exchanged to facilitate the first key establishment algorithm (performed in IKE_SA_INIT) must be constrained enough in size as to not induce IP fragmentation, a subsequent key establishment algorithm can be performed in the IKE_INTERMEDIATE exchange , which precedes IKE_AUTH. This exchange, because it is encrypted by the initial key establishment algorithm, can now leverage the IKEv2-level fragmentation mechanism specified in . Use of this mechanism allows public keys and ciphertexts to be exchanged in messages that exceed path MTU and avoids IP fragmentation. This document profiles the use of and where the key exchanges are instantiated as follows:

The key exchange performed in IKE_SA_INIT can use any of the following algorithms: 384-bit random ECP group, 3072-bit MODP group, 4096-bit MODP group.
The additional key exchange performed in IKE_INTERMEDIATE MUST be ML-KEM-1024.

The CNSA 1.0 key establishment algorithms are permitted instead of, e.g., a smaller quantum resistant algorithm because they enable backwards compatibility with CNSA 1.0-compliant implementations of IPsec during the transition to the CNSA 2.0 Suite and facilitate interoperability among implementations, while introducing negligible security risks (described further in Security Considerations).

General Requirements The reader is assumed to have familiarity with the following documents:

Internet Key Exchange Protocol Version 2
IKEv2 Message Fragmentation
Signature Authentication in IKEv2
Intermediate Exchange in IKEv2
Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of IKEv2 for Post-Quantum Security
Signature Authentication in IKEv2 using PQC

-style notation indicates optional payloads using brackets. Some payloads, while optional in their respective specifications, are required by this profile. This has been done either to enable use of post-quantum cryptography, or to ensure the use of CNSA 2.0 Suite algorithms. These differences are discussed in more detail throughout this section. This document makes no requirements on payloads that are not specifically discussed.

IKE_SA_INIT Exchange

Overview The IKE_SA_INIT exchange MUST include the following payloads in addition to those from :

N(IKEV2_FRAGMENTATION_SUPPORTED)
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
N(SIGNATURE_HASH_ALGORITHMS)

The IKE_SA_INIT exchange MUST include the following optional payload from in the response:

CERTREQ

This profile does not require nor preclude the use of preshared keys. If preshared keys are being mixed in with the key exchange, then one or both of the following payloads MAY also include:

N(USE_PPK_INT) (preferred)
N(USE_PPK)

discusses requirements concerning the contents of the SA payloads. discusses requirements on the KE payloads. discusses the Notify payloads included in the lists above.

Security Association Payloads Security Association (SA) payloads are used to propose IPsec protocols and the cryptographic algorithms (indicated via Transform Types) that correspond to each protocol. A CNSA 2.0-compliant implementation of IPsec will use the Encapsulating Security Payload (ESP) protocol and the IKEv2 protocol . The SA[i/r]1 payloads exchanged in IKE_SA_INIT are used to present IKE proposals. Proposals for the ESP protocol are presented during the IKE_AUTH exchange and are discussed in Section 6.3. The IKE proposal includes the following:

Encryption Algorithm (Transform Type 1): ENCR_AES_GCM_16 (with key size 256 bits)
Pseudorandom Function (Transform Type 2): PRF_HMAC_SHA2_512 or PRF_HMAC_SHA2_384
Integrity Algorithm (Transform Type 3): NONE or not offered
Key Exchange Method (Transform Type 4): 384-bit random ECP group or 3072-bit MODP group or 4096-bit MODP group
Additional Key Exchange 1 (Transform Type 6): ML-KEM-1024

While the proposal requires negotiation of both a confidentiality algorithm and integrity algorithm, algorithms for Authenticated Encryption with Associated Data (AEAD) provide integrity, and are incompatible with the use of a separate integrity algorithm. In particular, since the Advanced Encryption Standard in Galois-Counter Mode (AES-GCM) is an AEAD algorithm, the IKE proposal offering AES-GCM as its encryption algorithm MUST either offer no integrity algorithm or an integrity algorithm of "NONE" with the former being the RECOMMENDED method, as per . ML-KEM-1024 MAY be proposed using any one of the Additional Key Exchange Transform Types (ADDKEs) 1-7 (with Transform Type 6-12 respectively), but a proposal MUST only include a single ADDKE Transform Type, and that ADDKE Transform Type MUST be ML-KEM-1024. An initiator proposal MUST be constructed using all of the Transform Types indicated above. For Transform Types that list more than one algorithm as an option, an initiator proposal MUST include at least one of the options listed and no options other than those listed above. A responder MUST accept initiator proposals that fit this description. If none of the proposals offered by the initiator comply with the above description, then the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode.

Key Exchange Payloads The Key Exchange Method field in the initiator's Key Exchange payload MUST be one of the following:

384-bit random ECP group
3072-bit MODP group
4096-bit MODP group

A responder compliant with this profile MUST send a N(INVALID_KE_PAYLOAD) if it receives a Key Exchange payload using a Key Exchange Method value corresponding to any algorithm not listed above. The following requirements are restated from . In every key establishment session, the CNSA-compliant initiator and responder MUST each generate ephemeral keys. While IKEv2 allows for the reuse of ephemeral Diffie-Hellman private keys , there are security concerns related to this practice. In order to address such concerns, requires ephemeral keys to be generated per connection. Moreover, this profile REQUIRES CNSA 2.0-compliant IPsec implementations to align with . In particular, an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. Any shared secret derived from key establishment MUST also be destroyed (zeroized) immediately after its use. If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is used, the initiator and responder both MUST generate an elliptic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public keys MUST be stored in the key exchange payload as described in . If the Diffie-Hellman (DH) key exchange is used, the initiator and responder both MUST generate a key pair using the appropriately sized MODP group as described in . The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA. As noted in , the shared secret result of an ECDH key exchange is the 384-bit x value of the ECDH common value. The shared secret result of a DH key exchange is the number of octets needed to accommodate the prime (e.g., 384 octets for 3072-bit MODP group) with leading zeros as necessary .

Notify Payloads The initiator and responder MUST include both of the following Notify payloads in their respective IKE_SA_INIT messages, enabling Intermediate Exchange and IKE-level fragmentation :

N(IKEV2_FRAGMENTATION_SUPPORTED)
N(INTERMEDIATE_EXCHANGE_SUPPORTED)

In order to use the ML-DSA-87 signature algorithm, both initiator and responder MUST include the N(SIGNATURE_HASH_ALGORITHMS) payload with hash value 'Identity' (5) as specified in . The initiators and responders also MAY negotiate use of pre-shared (symmetric) key. While supported the use of a PPK via , use of a PPK as specified in is preferred as it implicates the PPK earlier in the key schedule. Because both implementations may be active for some time, CNSA 2.0-compliant initiators configured for PPK use SHOULD send N(USE_PPK_INT), and MAY also send N(USE_PPK) if they are unsure whether the responder implements the preferred mechanism. A responder that receives such a message (i.e. with both Notify payloads) SHOULD reply with N(USE_PPK_INT) if it is supported. Only one mechanism can be invoked per SA. The details of PPK use are fully described in and ; this profile makes no additional constraints on their implementation, configuration, and use.

IKE_INTERMEDIATE Exchanges

Overview The IKE_INTERMEDIATE exchange performs an additional key establishment with ML-KEM-1024. The initiator sends an IKE_INTERMEDIATE message to the responder containing an encrypted KEi(1) payload. In reply, the responder sends an IKE_INTERMEDIATE message containing an encrypted KEr(1) payload. Requirements for Key Exchange payloads and ML-KEM are discussed in Section 5.2. If is supported by initiator and responder, a second IKE_INTERMEDIATE exchange can also be used to mix in a pre-shared key. PSK guidance and requirements are discussed in detail in . Implementations compliant with this profile MUST NOT use additional IKE_INTERMEDIATE exchanges to facilitate further key establishments. In other words, peers MUST NOT use IKE_INTERMEDIATE exchanges to send KE[i/r](n) payloads for values other than n=1 or that contain key establishment material for algorithms other than ML-KEM-1024.

Key Exchange Payloads In IKE_INTERMEDIATE, initiator and responder messages each contain a Key Exchange payload in order to facilitate a second key establishment which uses ML-KEM-1024. ML-KEM-1024 has Key Exchage Method value "TBD37" [EDNOTE: Will be assigned by IANA when is published]. This profile strengthens normative key generation, encapsulation, and decapsulation guidance from as follows: Responders MUST perform the checks specified in Section 7.2 of prior to performing Encaps(pk). If the checks fail, the responder MUST send a N(INVALID_SYNTAX) payload as a response to the request from the initiator. Initiators MUST perform the checks specified in Section 7.3 of prior to performing Decaps(sk, ct). In this case, the initiator SHOULD send a N(INVALID_SYNTAX) payload to the responder using the IKE_INFORMATIONAL exchange. This is an exception for the general requirement to not begin a new exchange based on errors in responses. As per , ephemeral ML-KEM private keys must be generated per connection. Additionally, a CNSA 2.0-compliant IPsec implementation MUST use ML-KEM ephemeral private keys in exactly one key establishment transaction, and MUST destroy (zeroize) said key as soon as possible. Any shared secret derived from key establishment MUST also be destroyed (zeroized) immediately after its use, as is required for (EC)DH in Section 4.3. The following requirement is restated from for emphasis: the ML-KEM public key generated by the initiator and the ciphertext generated by the responder use randomness (usually a seed) which MUST be independent of any other random seed used in the IKEv2 negotiation. For example, at the initiator, the ML-KEM and (EC)DH keypairs used in a PQ/T Hybrid key exchange should not be generated from the same seed.

PSK If initiator and responder intend to signal support for in IKE_SA_INIT, the initiator sends an N(PPK_IDENTITY_KEY) payload(s) to the responder using the IKE_INTERMEDIATE exchange, and the responder will reply, both in accordance with . While indicates that the initiator MAY include the N(PPK_IDENTITY_KEY) payload(s) in the IKE_INTERMEDIATE exchange message used to transfer ML-KEM key material, it is RECOMMENDED by this profile that the initiator use a separate IKE_INTERMEDIATE exchange to agree on a pre-shared key such that the ML-KEM exchange precedes the PSK exchange. PSKs shall be at least 256 bits in length, and generated from a NIST approved random bit generator that supports 256-bits of entropy .

IKE_AUTH Exchange

Overview The IKE_AUTH exchange MUST include the following optional payloads from in the initiator message:

CERT
CERTREQ

The IKE_AUTH exchange MUST include the following optional payloads from in the responder message:

CERT

The contents of the initiator SAi2 payload and the responder SAr2 payload are discussed in . discusses the initiator and responder AUTH payloads. The CERT payloads are discussed in .

Security Association Payloads The initiator and responder present their ESP proposals in SAi2 and SAr2 respectively. The ESP proposal includes the following:

Encryption Algorithm (Transform Type 1): ENCR_AES_GCM_16 (with key size 256 bits)
Integrity Algorithm (Transform Type 2): NONE or not offered

While ESP as specified in optionally supports an integrity algorithm, the use of AES-GCM for an encryption algorithm requires that either no integrity algorithm or an algorithm NONE be offered.

Authentication Payloads This profile REQUIRES the use of digital signature ML-DSA-87 . If the relying party receives a message signed with any authentication method other than ML-DSA-87, it MUST return an AUTHENTICATION_FAILED Notify payload and stop processing the message. In alignment with and as defined by , this profile permits the use of both hedged and deterministic variants of ML-DSA. The ML-DSA algorithm incorporates an internal hashing function, so there is no need to apply a hashing algorithm before signing. Where implementation makes it more efficient to perform hashing externally, the external-μ mechanism described in Step 6 of Algorithm 7 of and Section 8 of MAY be used. HashML-DSA is not permitted. The computation instructions of the Authentication Data field in the AUTH payload is a complex interplay of , , , , and . Additionally, if peers agreed on and mixed in a PSK as in , this also impacts the calculation of the Authentication Data field.

Certificate Payloads While treats the inclusion of CERT payloads in IKE_AUTH messages as optional, CNSA 2.0-compliant initiator and responder IKE_AUTH messages MUST include the requisite CERT payloads. All CERT payloads MUST comply with . CERT payload(s) sent by both initiator and responder MUST include the Cert Encoding of X.509 Certificate - Signature (4). If a chain of certificates needs to be sent, multiple CERT payloads are used, of which only the first holds the public key used to validate the sender's AUTH payload. CERT payloads sent by initiator or responder may also use other Cert Encodings (such as Certificate Revocation List (7)) as needed. Other public key formats (such as PGP Certificate or SPKI Certificate) MUST NOT be used. Peer authentication decisions MUST be based on the Subject or Subject Alternative Name from the certificate that contains the key used to validate the digital signature in the AUTH payload, rather than the Identification Data from the ID payload that is used to look up policy.

CREATE_CHILD_SA Exchanges A KE payload SHOULD be included in the CREATE_CHILD_SA exchange, whether it be for creating a new child SA or for rekeying an existing IKE_SA or CHILD_SA. When an initiator includes a key exchange value, it MUST be an ML-KEM-1024 public key. Upon receipt, the responder MUST include a ML-KEM_1024 ciphertext in its response. Long-lived SAs SHOULD be rekeyed according to mission need and deployment environment.

Additional Requirements The IPsec protocol AH MUST NOT be used in CNSA-compliant implementations. Two operational requirements derive from :

Any ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. (Section 5.6.3.3)
Any shared secret derived from key establishment MUST be destroyed (zeroized) immediately after its use. (Section 5.8)

Initiator and responder MUST use X.509 certificates that comply with [RFC8603]. Peer authentication decisions must be based on the Subject or Subject Alternative Name from the certificate that contains the key used to validate the signature in the Authentication Payload as defined in Section 3.8 of , rather than Identification Data from the Identification Payload that is used to look up policy.

Security Considerations The security of a system that uses cryptography depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms. The security also depends on the engineering and administration of the protocol used by the system to ensure that there are no non-cryptographic ways to bypass the security of the overall system. When selecting a mode for the AES encryption [RFC5116], be aware that nonce reuse can result in a loss of confidentiality. Nonce reuse is catastrophic for GCM, since it also results in a loss of integrity.

IANA Considerations None.

Acknowledgements Rebecca Guthrie was the primary editor and contributed significantly to this document while she was employed at the National Security Agency's Center for Cybersecurity Standards.