| Internet-Draft | CNSA Suite 2.0 Profile for IPsec | March 2025 |
| Guthrie | Expires 4 September 2025 | [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, and. 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 4 September 2025.¶
Copyright (c) 2025 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. 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.¶
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 uses only algorithms in the CNSA 2.0 suite already specified for use by IPsec.¶
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.¶
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]¶
This profile uses CNSA 2.0 compliant algorithms ML-KEM-1024 [FIPS203] for key establishment and ML-DSA-87 [FIPS204] as a digital signature. In addition, this profile also includes the 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 cause 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.kampanakis-ml-kem-ikev2] where the key exchanges are instantiated as follows:¶
[EDNOTE: 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). Should this justification be included in the final text?]¶
In the IKE_SA_INIT exchange, the initiator sends a message to the responder that includes the following payloads:¶
The initiator sends the responder a message that includes the following payloads:¶
Note that optional payloads are indicated using brackets; some payloads, while optional in their respective specifications, are required by this profile. These differences are discussed in more detail throughout this section.¶
Section 4.2 discusses requirements concerning the contents of the SA payloads. Section 4.3 discusses requirements on the KE payloads. Section 4.4 discusses the Notify payloads included in the lists above. Section 4.5 discusses the CERTREQ payload sent by the responder.¶
No additional requirements are imposed for the Nonce payloads Ni and Nr beyond what is detailed in [RFC7296].¶
Note that it may be necessary for the initiator and responder to include Notify payloads other than those listed above in their respective IKE_SA_INIT messages for certain use cases (such as those used for NAT traversal). Such use cases are not discussed here as they do not require further profiling and should be implemented in accordance with the relevant RFCs.¶
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) 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.¶
AES-GCM-SIV [RFC8452] conforms with the requirements of this document and MAY be used instead of AES-GCM if a Federal Information Processing Standard (FIPS) validated implementation is available and a Transform Type 1 value is registered with IANA.¶
[EDNOTE: Please contact the document author to express interest in or identify implementations that support AES-GCM-SIV.]¶
Note that 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, 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.¶
In order to use the Intermediate Exchange [RFC9242] and IKE-level fragmentation [RFC7383], initiator and responder MUST include both of the following Notify payloads in their respective IKE_SA_INIT messages:¶
[EDNOTE: Is there a way to signal that both of the above Notify payloads are required by this profile even though they are optional in their respective specifications?]¶
In order to use the ML-DSA-87 signature algorithm, initiator and responder MUST include the N(SIGNATURE_HASH_ALGORITHMS) [RFC7427], Section 4 payload in their respective IKE_SA_INIT messages as specified in Section 5 of [I-D.reddy-ipsecme-ikev2-pqc-auth].¶
The initiator and responder also MAY negotiate support for [I-D.ietf-ipsecme-ikev2-qr-alt] using N(USE_PPK_INT) as specified in [I-D.ietf-ipsecme-ikev2-qr-alt].¶
Note that while [RFC9206] supported the use of a PSK via [RFC8784], this profile instead supports the use of a PSK as specified in [I-D.ietf-ipsecme-ikev2-qr-alt]. This profile acknowledges that there may be a period of transition in which implementations support the use of a PSK via [RFC8784], but have not yet added support for [I-D.ietf-ipsecme-ikev2-qr-alt]. During this time, because the negotiation for each PSK mechanism is independent (though only one is used in a given connection), a CNSA 2.0-compliant initiator MAY include both N(USE_PPK_INT) and N(USE_PPK) in its IKE_SA_INIT message to accommodate the scenario where a responder who is otherwise CNSA 2.0-compliant has not yet added in support for [I-D.ietf-ipsecme-ikev2-qr-alt]. If the responding peer replies with N(USE_PPK) [RFC8784] but is otherwise CNSA 2.0-compliant, the initiator MAY proceed in establishing the initial SA. A CNSA 2.0-compliant peer that receives both N(USE_PPK_INT) and N(USE_PPK) MUST return N(USE_PPK_INT) and agree to use a PSK as specified by [I-D.ietf-ipsecme-ikev2-qr-alt]. If a CNSA 2.0-compliant peer receives only N(USE_PPK), it MAY return N(USE_PPK) and proceed to use a PSK as specified by [RFC8784].¶
While [RFC7296] treats the CERTREQ payload as optional, this profile requires its use.¶
[EDNOTE: [I-D.reddy-ipsecme-ikev2-pqc-auth] discusses mechanisms for signaling which digital signature algorithms are supported. In the case of CNSA 2.0, the inclusion of the N(SIGNATURE_HASH_ALGORITHMS) payload in IKE_SA_INIT is sufficient to indicate that ML-DSA is supported because it is the only CNSA 2.0-compliant signature algorithm that uses this Notify payload. However, one proposal from [I-D.reddy-ipsecme-ikev2-pqc-auth] uses the CERTREQ payload to indicate that a CA certificate signed by an ML-DSA key is trusted. Do future implementors have a preference between these two methods? Note that while [I-D.reddy-ipsecme-ikev2-pqc-auth] also proposes the use of N(SUPPORTED_AUTH_METHODS) [RFC9593] as another mechanism, CNSA 2.0 does not plan to support the use of this extension.]¶
[EDNOTE: Separate from the above discussion, this profile is considering requiring the use of the CERTREQ payload even though it is optional per [RFC7296]. Can implementations support this? Are there compelling use cases for not using the CERTREQ payload (sent by either the responder in IKE_SA_INIT or the initiator in IKE_AUTH) though X.509-based authentication is required?]¶
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 [I-D.ietf-ipsecme-ikev2-qr-alt] 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 5.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, now using ML-KEM-1024.¶
ML-KEM-1024 has Key Exchage Method value "TBD37" [EDNOTE: Will be assigned by IANA when [I-D.kampanakis-ml-kem-ikev2] is published].¶
This profile strengthens normative key generation, encapsulation, and decapsulation guidance from [I-D.kampanakis-ml-kem-ikev2], 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.¶
Like the traditional key establishment performed in the KE Payloads of IKE_SA_INIT, this profile also REQUIRES ephemeral ML-KEM keys without key reuse. The following requirement is restated from [I-D.kampanakis-ml-kem-ikev2] 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.¶
[EDNOTE: Additional RBG requirements for ML-KEM may be included here.]¶
If initiator and responder signal support for [I-D.ietf-ipsecme-ikev2-qr-alt] in IKE_SA_INIT, the initiator MAY send N(PPK_IDENTITY_KEY) payload(s) to the responder using the IKE_INTERMEDIATE exchange, and the responder will reply, both in accordance with [I-D.ietf-ipsecme-ikev2-qr-alt], Section 3.1.¶
While [I-D.ietf-ipsecme-ikev2-qr-alt] 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 second IKE_INTERMEDIATE exchange to agree on a pre-shared key, following the exchange used to facilitate key establishment with ML-KEM.¶
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].¶
In the IKE_AUTH exchange, the initiator sends a message to the responder that includes the following payloads:¶
The responder sends a message to the initiator that includes the following payloads:¶
Note that optional payloads are indicated using brackets; some payloads, while optional in their respective specifications, are required by this profile. These differences are discussed in more detail throughout this section.¶
The initiator's CERTREQ payload is discussed in Section 6.2. The contents of the initiator SAi2 payload and the responder SAr2 payload are discussed in Section 6.3. Section 6.4 discusses the initiator and responder AUTH payloads. The CERT payloads are discussed in Section 6.5.¶
Note that it may be necessary for the initiator and responder to include other Notify payloads in their respective IKE_AUTH messages for certain use cases. Such instances are not discussed here as they do not require further profiling and should be implemented in accordance with the relevant RFCs.¶
While [RFC7296] treats the CERTREQ payload as optional, this profile requires the CERTREQ payload to be used.¶
[EDNOTE: See related EDNOTE in Section 4.5.]¶
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 for an encryption algorithm requires that either no integrity algorithm or an algorithm NONE be offered.¶
AES-GCM-SIV [RFC8452] conforms with the requirements of this document and MAY be used instead of AES-GCM if a Federal Information Processing Standard (FIPS) validated implementation is available and a Transform Type 1 value is registered with IANA.¶
[EDNOTE: [RFC7296] states that DH (now Key Exchange Method) is optional for ESP, but the choice to do this would imply that a KE payload could optionally be included in IKE_AUTH messages, which is not addressed in [RFC7296]. Is this interpretation correct? If so, is this something that happens in practice?]¶
[EDNOTE: Guidance on Extended Sequence Numbers (Transform Type 5) [RFC7296], Section 3.3.2 in ESP proposals is forthcoming.]¶
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.¶
While in accordance with [I-D.reddy-ipsecme-ikev2-pqc-auth] permits both deterministic and non-deterministic signatures, this profile requires the use of non-deterministic ML-DSDA.¶
Note that the calculation of the Authentication Data field in the AUTH payload [RFC7296] is updated by [I-D.kampanakis-ml-kem-ikev2] (which leverages [RFC9370], which leverages [RFC9242], which leverages [RFC7383]). Additionally, if peers agreed on and mixed in a PSK as in [I-D.ietf-ipsecme-ikev2-qr-alt], this also impacts the calculation of the Authentication Data field.¶
[EDNOTE: Is the way that Authentication Data calculation is updated clear, or should this be explained?]¶
[EDNOTE: Clarification regarding the use of ML-DSA vs. ExternalMu-ML-DSA [I-D.ietf-lamps-dilithium-certificates], Part Appendix D is forthcoming. Note that HashML-DSA will not be permitted (also in accordance with [I-D.ietf-lamps-dilithium-certificates]).]¶
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). Note that if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload [RFC7296], Section 3.6. CERT payloads sent by initiator or responder may also optionally use other Cert Encodings (such as Certificate Revocation List (7)) as needed. Other public key formats (such as PGP Certificate=2, SPKI Certificate=9) 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.¶
Forthcoming.¶
Forthcoming.¶
Forthcoming.¶
None.¶