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 This profile uses CNSA 2.0 compliant algorithms ML-KEM-1024 for key establishment and ML-DSA-87 as a digital signature. In addition, this profile also includes the 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 cause 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.

[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?]

IKE_SA_INIT Exchange

Overview In the IKE_SA_INIT exchange, the initiator sends a message to the responder that includes the following payloads:

SAi1
KEi
Ni
N(IKEV2_FRAGMENTATION_SUPPORTED)
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
N(SIGNATURE_HASH_ALGORITHMS)
[N(USE_PPK_INT)]

The responder sends the initiator a message that includes the following payloads:

SAr1
KEr
Nr
CERTREQ
N(IKEV2_FRAGMENTATION_SUPPORTED)
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
N(SIGNATURE_HASH_ALGORITHMS)
[N(USE_PPK_INT)]

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 . 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 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 . AES-GCM-SIV 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 authors 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.

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 In order to use the Intermediate Exchange and IKE-level fragmentation , initiator and responder MUST include both of the following Notify payloads in their respective IKE_SA_INIT messages:

N(IKEV2_FRAGMENTATION_SUPPORTED)
N(INTERMEDIATE_EXCHANGE_SUPPORTED)

[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) payload in their respective IKE_SA_INIT messages as specified in Section 5 of . The initiator and responder also MAY negotiate support for using N(USE_PPK_INT) as specified in . Note that while supported the use of a PSK via , this profile instead aims to support the use of a PSK as specified in . This profile acknowledges that there may be a period of transition in which implementations support the use of a PSK via , but have not yet added support for . During this time, a CNSA 2.0-compliant initiator MAY include only N(USE_PPK) in its IKE_SA_INIT message if it does not yet support . Because each PSK mechanism is negotiated independently (though only one is used in a given connection), a CNSA 2.0-compliant initiator also 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 . In either scenario, if the responder replies with N(USE_PPK) but is otherwise CNSA 2.0-compliant, the initiator MAY proceed in establishing the SA using a PSK as specified by . A CNSA 2.0-compliant responder that receives both and supports both N(USE_PPK_INT) and N(USE_PPK) MUST return N(USE_PPK_INT) and agree to use a PSK as specified by .

Certificate Request Payload While treats the CERTREQ payload as optional, this profile requires its use. [EDNOTE: 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 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 also proposes the use of N(SUPPORTED_AUTH_METHODS) 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 . 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?]

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 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.

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. [EDNOTE: Additional RBG requirements for ML-KEM may be included here.]

PSK If initiator and responder signal support for 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 . 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. Note that 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 In the IKE_AUTH exchange, the initiator sends a message to the responder that includes the following payloads:

IDi
CERT
CERTREQ
[IDr]
AUTH (modified by , , , )
SAi2
TSi
TSr

The responder sends a message to the initiator that includes the following payloads:

IDr
CERT
AUTH (modified by , , , )
SAr2
TSi
TSr

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.

Certificate Request Payload While treats the CERTREQ payload as optional, this profile requires the CERTREQ payload to be used. [EDNOTE: See related EDNOTE in Section 4.5.]

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. AES-GCM-SIV 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: 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 . Is this interpretation correct? If so, is this something that happens in practice?] [EDNOTE: Guidance on Extended Sequence Numbers (Transform Type 5) in ESP proposals is forthcoming.]

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. Note that the calculation of the Authentication Data field in the AUTH payload is updated by (which leverages , which leverages , which leverages ). Additionally, if peers agreed on and mixed in a PSK as in , 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 is forthcoming. Note that HashML-DSA will not be permitted (also in accordance with ).]

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). Note that if a chain of certificates needs to be sent, multiple CERT payloads are used, where only the first of which holds the public key used to validate the sender's AUTH payload . 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.

CREATE_CHILD_SA Exchanges Forthcoming.

Additional Requirements Forthcoming.

Security Considerations Forthcoming.

IANA Considerations None.