| Internet-Draft | CNSA Suite 2.0 Profile for IPsec | July 2026 |
| Jenkins | Expires 6 January 2027 | [Page] |
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments.¶
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 6 January 2027.¶
Copyright (c) 2026 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 (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.¶
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 [CNSA2]. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (NSS) [SP80059] 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.¶
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] 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 [FIPS203]¶
ML-DSA: Module-Lattice-Based Digital Signature Algorithm, defined in [FIPS204]¶
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 [CNSA2].¶
The National Institute for Standards and Technology (NIST) has standardized several post-quantum asymmetric algorithms. From these, NSA has selected two: ML-DSA-87 [FIPS204] for signing and ML-KEM-1024 [FIPS203] 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.¶
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 [RFC9206]: ECDH with curve P-384 [SP80056A] and DH with prime modulus of 3072 bits or 4096 bits [RFC3526].¶
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, [RFC9370] 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 [RFC9242], 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 [RFC7383]. 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 [RFC9370] and [I-D.ietf-ipsecme-ikev2-mlkem] where the key exchanges are instantiated as follows:¶
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).¶
The reader is assumed to have familiarity with the following documents:¶
[RFC7296]-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.¶
The IKE_SA_INIT exchange MUST include the following payloads in addition to those from [RFC7296]:¶
The IKE_SA_INIT exchange MUST include the following optional payload from [RFC7296] in the response:¶
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:¶
Section 6.2 discusses requirements concerning the contents of the SA payloads. Section 6.3 discusses requirements on the KE payloads. Section 6.4 discusses the Notify payloads included in the lists above.¶
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 [RFC4303] and the IKEv2 protocol [RFC7296]. 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:¶
While the proposal requires negotiation of both a confidentiality algorithm and integrity algorithm, algorithms for Authenticated Encryption with Associated Data (AEAD) [RFC5116] provide integrity, and are incompatible with the use of a separate integrity algorithm. In particular, since the Advanced Encryption Standard [FIPS197] in Galois-Counter Mode [SP80038D] (AES-GCM) [RFC8247] 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 [RFC7296], Section 3.3.¶
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.¶
The Key Exchange Method field [RFC9370] in the initiator's Key Exchange payload MUST be one of the following:¶
A responder compliant with this profile MUST send a N(INVALID_KE_PAYLOAD) [RFC7296] 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 [RFC9206].¶
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 [RFC7296], Section 2.12, there are security concerns related to this practice. In order to address such concerns, [I-D.ietf-ipsecme-ikev2-mlkem] requires ephemeral keys to be generated per connection. Moreover, this profile REQUIRES CNSA 2.0-compliant IPsec implementations to align with [SP80056A]. 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 [RFC5903].¶
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 [RFC3526]. 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 [RFC5903], Section 7, 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 [RFC2631], Section 2.1.2.¶
The initiator and responder MUST include both of the following Notify payloads in their respective IKE_SA_INIT messages, enabling Intermediate Exchange [RFC9242] and IKE-level fragmentation [RFC7383]:¶
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 [I-D.ietf-ipsecme-ikev2-pqc-auth].¶
The initiators and responders also MAY negotiate use of pre-shared (symmetric) key. While [RFC9206] supported the use of a PPK via [RFC8784], use of a PPK as specified in [RFC9867] 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 [RFC9206] and [RFC8784]; this profile makes no additional constraints on their implementation, configuration, and use.¶
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) [RFC9370] payload. In reply, the responder sends an IKE_INTERMEDIATE message containing an encrypted KEr(1) [RFC9370] payload. Requirements for Key Exchange payloads and ML-KEM are discussed in Section 5.2.¶
If [RFC9867] 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 Section 7.3.¶
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.¶
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 [I-D.ietf-ipsecme-ikev2-mlkem] is published].¶
This profile strengthens normative key generation, encapsulation, and decapsulation guidance from [I-D.ietf-ipsecme-ikev2-mlkem], Section 2.3 as follows: Responders MUST perform the checks specified in Section 7.2 of [FIPS203] 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 [FIPS203] 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 [I-D.ietf-ipsecme-ikev2-mlkem], 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 [I-D.ietf-ipsecme-ikev2-mlkem] 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.¶
If initiator and responder intend to signal support for [RFC9867] 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 [RFC9867], Section 3.1.¶
While [RFC9867] 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 [SP80090C].¶
The IKE_AUTH exchange MUST include the following optional payloads from [RFC7296] in the initiator message:¶
The IKE_AUTH exchange MUST include the following optional payloads from [RFC7296] in the responder message:¶
The contents of the initiator SAi2 payload and the responder SAr2 payload are discussed in Section 8.2. Section 8.3 discusses the initiator and responder AUTH payloads. The CERT payloads are discussed in Section 8.4.¶
The initiator and responder present their ESP proposals in SAi2 and SAr2 respectively.¶
The ESP proposal includes the following:¶
While ESP as specified in [RFC7296] optionally supports an integrity algorithm, the use of AES-GCM [RFC4106] for an encryption algorithm requires that either no integrity algorithm or an algorithm NONE be offered.¶
This profile REQUIRES the use of digital signature ML-DSA-87 [FIPS204]. 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 [I-D.ietf-ipsecme-ikev2-pqc-auth] and as defined by [FIPS204], 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 [FIPS204] and Section 8 of [RFC9881] 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 [RFC7296], [I-D.ietf-ipsecme-ikev2-mlkem], [RFC9370], [RFC9242], and [RFC7383]. Additionally, if peers agreed on and mixed in a PSK as in [RFC9867], this also impacts the calculation of the Authentication Data field.¶
While [RFC7296] 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 [I-D.jenkins-cnsa2-pkix-profile]. 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.¶
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.¶
The IPsec protocol AH MUST NOT be used in CNSA-compliant implementations.¶
Two operational requirements derive from [SP80056A]:¶
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 [RFC7296], rather than Identification Data from the Identification Payload that is used to look up policy.¶
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.¶
None.¶
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.¶