National Security Agency

lscorco@nsa.gov

National Security Agency - Center for Cybersecurity Standards

mjjenki@cyber.nsa.gov

post quantum quantum resistant NSA The United States Government has published the National Security Agency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2022 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 () 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.

Table of Contents

• .  Introduction
• .  Terminology
• .  The Commercial National Security Algorithm Suite
• .  CNSA-Compliant IPsec Overview
• .  IPsec User Interface Suites
  • .  Suite CNSA-GCM-256-ECDH-384
  • .  Suite CNSA-GCM-256-DH-3072
  • .  Suite CNSA-GCM-256-DH-4096
• .  IKEv2 Authentication
• .  Certificates
• .  IKEv2 Security Associations (SAs)
• .  The Key Exchange Payload in the IKE_SA_INIT Exchange
• . Generating Key Material for the IKE SA
• . Additional Requirements
• . Guidance for Applications with Long Data-Protection Requirements
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

Introduction This document specifies the conventions for using the United States National Security Agency's (NSA's) Commercial National Security Algorithm (CNSA) Suite algorithms in Internet Protocol Security (IPsec). It defines CNSA-based User Interface suites ("UI suites") describing sets of security configurations for Internet Key Exchange Protocol Version 2 (IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and specifies certain other constraints with respect to algorithm selection and configuration. It applies to the capabilities, configuration, and operation of all components of US National Security Systems (described in NIST Special Publication 800-59 ) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value information. It 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 the following:

• ""
• ""
• ""
• ""
• ""

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. AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie-Hellman (ECDH), respectively. DH refers to Diffie-Hellman key establishment. RSA refers to an RSA signature.

The Commercial National Security Algorithm Suite The 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 to both (1) assist with the US Government transition to new algorithms and (2) provide vendors -- and the Internet community in general -- with information concerning their proper use and configuration. Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer. The NSA has established the Commercial National Security Algorithm (CNSA) Suite to provide vendors and IT users near-term flexibility in meeting their information assurance interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future. The NSA is authoring a set of RFCs, including this one, to provide updated guidance concerning the use of certain commonly available commercial algorithms in 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.

CNSA-Compliant IPsec Overview CNSA-compliant implementations for IPsec MUST use IKEv2 . Implementing a CNSA-compliant IPsec system requires cryptographic algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPsec: Encryption:

• AES (with key size 256 bits)

Digital Signature:

• ECDSA (using the NIST P-384 elliptic curve)
• RSA (with a modulus of 3072 bits or larger)

Key Establishment:

• ECDH (using the NIST P-384 elliptic curve)
• DH (with a prime modulus of 3072 or larger)

To facilitate selection of appropriate combinations of compliant algorithms, this document provides CNSA-compliant User Interface suites (UI suites) to implement IPsec on National Security Systems. The approved CNSA hash function for all purposes is SHA-384, as defined in . However, PRF_HMAC_SHA_512 is specified for the IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to availability. See below. For CNSA Suite applications, public key certificates MUST be compliant with the CNSA Suite Certificate and CRL Profile specified in . Under certain conditions, such as applications having long-lived data-protection requirements, systems that do not comply with the requirements of this document are acceptable; see .

IPsec User Interface Suites User Interface (UI) suites are named suites that cover some typical security policy options for IPsec. Use of UI suites does not change the IPsec protocol in any way. The following UI suites provide cryptographic algorithm choices for ESP and for IKEv2 . The selection of a UI suite will depend on the key exchange algorithm. The suite names indicate the Advanced Encryption Standard mode, AES key length specified for encryption, and the key exchange algorithm. Although RSA is also a CNSA-approved key establishment algorithm, only DH and ECDH are specified for key exchange in IKEv2 . RSA in IPsec is used only for digital signatures. See . ESP requires negotiation of both a confidentiality algorithm and an integrity algorithm. However, algorithms for Authenticated Encryption with Associated Data (AEAD) do not require a separate integrity algorithm to be negotiated. In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST either offer no integrity algorithm or indicate the single integrity algorithm NONE (see ). To be CNSA compliant, IPsec implementations that use the following UI suites MUST use the suite names listed below. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described and MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability. Transform names are as listed in the IANA "Internet Key Exchange Version 2 (IKEv2) Parameters" registry. Definitions of the transforms are contained in the references specified in that registry. Other UI suites may be acceptable for CNSA compliance. See for details.

Suite CNSA-GCM-256-ECDH-384

ESP SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

Integrity:

NONE

IKEv2 SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

PRF:

PRF_HMAC_SHA2_512

Integrity:

NONE

Diffie-Hellman group:

384-bit random ECP group

Suite CNSA-GCM-256-DH-3072

ESP SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

Integrity:

NONE

IKEv2 SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

PRF:

PRF_HMAC_SHA2_512

Integrity:

NONE

Diffie-Hellman group:

3072-bit MODP group

Suite CNSA-GCM-256-DH-4096

ESP SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

Integrity:

NONE

IKEv2 SA:

Encryption:

ENCR_AES_GCM_16 (with key size 256 bits)

PRF:

PRF_HMAC_SHA2_512

Integrity:

NONE

Diffie-Hellman group:

4096-bit MODP group

IKEv2 Authentication Authentication of the IKEv2 Security Association (SA) requires computation of a digital signature. To be CNSA compliant, digital signatures MUST be generated with SHA-384 as defined in together with either ECDSA-384 as defined in or RSA with 3072-bit or greater modulus. (For applications with long data-protection requirements, somewhat different rules apply; see .) Initiators and responders MUST be able to verify ECDSA-384 signatures and MUST be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 signatures. For CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 3072-bit modulus or larger MUST be used for RSA. If the relying party receives a message signed with any authentication method other than an ECDSA-384 or RSA signature, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message. If the relying party receives a message signed with RSA using less than a 3072-bit modulus, it MUST return an AUTHENTICATION_FAILED notification and stop processing the message.

Certificates To be CNSA compliant, the initiator and responder MUST use X.509 certificates that comply with . 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 , rather than the Identification Data from the Identification Payload that is used to look up policy.

IKEv2 Security Associations (SAs) specifies three UI suites for ESP and IKEv2 Security Associations. All three use AES-GCM for encryption but differ in the key exchange algorithm. Galois/Counter Mode (GCM) combines counter (CTR) mode with a secure, parallelizable, and efficient authentication mechanism. Since AES-GCM is an AEAD algorithm, ESP implements AES-GCM with no additional integrity algorithm (see ). An initiator proposal SHOULD be constructed from one or more of the following suites:

• CNSA-GCM-256-ECDH-384
• CNSA-GCM-256-DH-3072
• CNSA-GCM-256-DH-4096

A responder SHOULD accept proposals constructed from at least one of the three named suites. Other UI suites may result in acceptable proposals (such as those based on PRF_HMAC_SHA2_384); however, these are provided to promote interoperability. Nonce construction for AES-GCM using a misuse-resistant technique conforms with the requirements of this document and MAY be used if a Federal Information Processing Standard (FIPS) validated implementation is available. The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF transform, as PRF_HMAC_SHA2_384 is not listed among required PRF transforms in ; therefore, implementation of the latter is likely to be scarce. The security level of PRF_HMAC_SHA2_512 is comparable, and the difference in performance is negligible. However, SHA-384 is the official CNSA algorithm for computing a condensed representation of information. Therefore, the PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to the initiator and responder. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used. If none of the proposals offered by the initiator consist solely of transforms based on CNSA algorithms (such as those in the UI suites defined in ), the responder MUST return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode.

The Key Exchange Payload in the IKE_SA_INIT Exchange The key exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The CNSA-compliant initiator and responder MUST each generate an ephemeral key pair to be used in the key exchange. If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected for the SA, 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 selected for the SA, 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.

Generating Key Material for the IKE 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, as described in . IKEv2 allows for the reuse of Diffie-Hellman private keys; see . However, there are security concerns related to this practice. Section 5.6.3.3 of states that an ephemeral private key MUST be used in exactly one key establishment transaction and MUST be destroyed (zeroized) as soon as possible. Section 5.8 of states that any shared secret derived from key establishment MUST be destroyed (zeroized) immediately after its use. CNSA-compliant IPsec systems MUST follow the mandates in .

Additional Requirements The IPsec protocol AH MUST NOT be used in CNSA-compliant implementations. A Diffie-Hellman group MAY be negotiated for a Child SA as described in , allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. If a transform of type 4 is specified for an SA for ESP, the value of that transform MUST match the value of the transform used by the IKEv2 SA. Per , if a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST include the Diffie-Hellman group of the KEi. For CNSA-compliant IPsec implementations, the Diffie-Hellman group of the KEi MUST use the same group used in the IKE_INIT_SA. For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both parties. The initiator of this exchange MAY include a new Diffie-Hellman key; if it is included, it MUST use the same group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the same group. For CNSA-compliant systems, the IKEv2 authentication method MUST use an end-entity certificate provided by the authenticating party. Identification Payloads (IDi and IDr) in the IKE_AUTH exchanges MUST NOT be used for the IKEv2 authentication method but may be used for policy lookup. The administrative User Interface (UI) for a system that conforms to this profile MUST allow the operator to specify a single suite. If only one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms for that one suite. The administrative UI MAY allow the operator to specify more than one suite; if it allows this, it MUST allow the operator to specify a preferred order for the suites that are to be offered or accepted. If more than one suite is specified in the administrative UI, the IKEv2 implementation MUST only offer algorithms of those suites. (Note that although this document does not define a UI suite specifying PRF_HMAC_SHA2_384, a proposal containing such a transform is CNSA compliant.)

Guidance for Applications with Long Data-Protection Requirements The CNSA mandate is to continue to use current algorithms with increased security parameters, then transition to approved post-quantum resilient algorithms when they are identified. However, some applications have data-in-transit-protection requirements that are long enough that post-quantum resilient protection must be provided now. Lacking approved asymmetric post-quantum resilient confidentiality algorithms, that means approved symmetric techniques must be used as described in this section until approved post-quantum resilient asymmetric algorithms are identified. For new applications, confidentiality and integrity requirements from the sections above MUST be followed, with the addition of a Pre-Shared Key (PSK) mixed in as defined in . Installations currently using IKEv1 with PSKs MUST (1) use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA-compliant integrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 with PSKs as soon as implementations become available. Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes and PSK length, and PSK randomness, will be defined in solution-specific requirements appropriate to the application. Details of those requirements will depend on the program under which the commercial National Security Systems solution is developed (e.g., an NSA Commercial Solutions for Classified Capability Package).

Security Considerations This document inherits all of the security considerations of the IPsec and IKEv2 documents, including , , , and . 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 , 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 IANA has added the UI suites defined in this document to the "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located at :

Identifier	Reference
CNSA-GCM-256-ECDH-384	RFC 9206
CNSA-GCM-256-DH-3072	RFC 9206
CNSA-GCM-256-DH-4096	RFC 9206

References Normative References Committee for National Security Systems CNSSP 15 National Institute of Standards and Technology Federal Information Processing Standard 180-4 National Institute of Standards and Technology NIST Federal Information Processing Standard 186-4 National Institute of Standards and Technology Federal Information Processing Standard 197 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. [STANDARDS-TRACK] This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK] This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. [STANDARDS-TRACK] This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2. [STANDARDS-TRACK] This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods. This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. [STANDARDS-TRACK] This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes. This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 3447. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP). This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. National Institute of Standards and Technology NIST Special Publication 800-56A, Revision 3 Informative References This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated. This document is the product of the Crypto Forum Research Group. National Institute of Standards and Technology Special Publication 800-59

Authors' Addresses National Security Agency

lscorco@nsa.gov

National Security Agency - Center for Cybersecurity Standards

mjjenki@cyber.nsa.gov