<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902" docName="draft-corcoran-cnsa-ipsec-profile-06" number="9206" obsoletes="" updates="" submissionType="IETF" submissionType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">

<front>
    <title abbrev="CNSA Suite IPsec Profile">Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</title>
    <seriesInfo name="Internet-Draft" value="draft-corcoran-cnsa-ipsec-profile-06"/> name="RFC" value="9206"/>
    <author fullname="Laura Corcoran" initials="L." surname="Corcoran">
      <organization abbrev="NSA">National Security Agency</organization>
      <address>
        <email>lscorco@nsa.gov</email>
      </address>

    </author>
    <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
      <organization abbrev="NSA">National Security Agency</organization> Agency - Center for Cybersecurity Standards</organization>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>

    <date year="2022"/> year="2022" month="February" />

<keyword>post quantum</keyword>
<keyword>quantum resistant</keyword>
<keyword>NSA</keyword>

    <abstract>
      <t>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. Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. US National Security Systems are described (described in NIST Special Publication 800-59. It 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.
</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document specifies the conventions for using the United States National Security Agency's (NSA's) Commercial National Security Algorithm (CNSA) Suite algorithms <xref target="CNSA" format="default"/> in Internet Protocol Security (IPsec). It defines CNSA-based user interface User Interface suites ("UI suites") describing sets of security configurations for Internet Key Exchange version 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 that employ IPsec. US National Security Systems are described (described in NIST Special Publication 800-59 <xref target="SP80059" format="default"/>. It format="default"/>) 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.
</t>
      <t>The reader is assumed to have familiarity with the following:

</t>
      <ul empty="true" spacing="normal">
        <li>
        "<xref target="RFC4303" format="title"/>" <xref target="RFC4303" format="default"/>, IP Encapsulating Security Payload (ESP)</li> format="default"/>
        </li>
        <li>
        "<xref target="RFC5280" format="title"/>" <xref target="RFC5280" format="default"/>, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</li> format="default"/>
        </li>
        <li>
        "<xref target="RFC7296" format="title"/>" <xref target="RFC7296" format="default"/>, Internet Key Exchange Version 2 (IKEv2)</li> format="default"/>
        </li>
        <li>
        "<xref target="RFC8221" format="title"/>" <xref target="RFC8221" format="default"/>, Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</li>
        <li> format="default"/>
        </li>
       <li>"<xref target="RFC8603" format="title"/>" <xref target="RFC8603" format="default"/>, Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile</li> format="default"/></li>
      </ul>
    </section>
    <!-- intro -->

<section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.
</t> here.</t>
      <t>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.
</t>
    </section>
    <!-- terminology -->

<section anchor="cnsa" numbered="true" toc="default">
      <name>The Commercial National Security Algorithm Suite</name>
      <t>The National Security Agency (NSA) 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 both (1)&nbsp;assist with the US Government transition to new algorithms, algorithms and to provide (2)&nbsp;provide vendors - -- and the Internet community in general - -- with information concerning their proper use and configuration.
</t>
      <t>Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically-relevant 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.
</t>
      <t>NSA
      <t>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.
</t>
    </section>
    <!-- cnsa -->

<section anchor="overview" numbered="true" toc="default">
      <name>CNSA Compliant
      <name>CNSA-Compliant IPsec Overview</name>
      <t>CNSA compliant

      <t>CNSA-compliant implementations for IPsec MUST <bcp14>MUST</bcp14> use IKEv2 <xref target="RFC7296" format="default"/>.
</t>
      <t>Implementing a CNSA compliant CNSA-compliant IPsec system requires cryptographic algorithm selection for both the IKEv2 and ESP protocols. The following CNSA requirements apply to IPsec:

</t>
      <ul empty="true" spacing="compact">
        <li>

          <t>Encryption:</t>
          <ul empty="true" spacing="compact">
          <li>AES <xref target="FIPS197" format="default"/> (with key size 256 bits)</li>
          </ul>
        </li>
      </ul>

      <ul empty="true" spacing="compact">
        <li>

          <t>Digital Signature:</t>
          <ul empty="true" spacing="compact">
          <li>ECDSA <xref target="FIPS186" format="default"/> (using the NIST P-384 elliptic curve)</li>
          <li>RSA <xref target="FIPS186" format="default"/> (with a modulus of 3072 bits or larger)</li>
          </ul>
        </li>
      </ul>

      <ul empty="true" spacing="compact">
        <li>

          <t>Key Establishment:</t>
          <ul empty="true" spacing="compact">
            <li>ECDH <xref target="SP80056A" format="default"/> (using the NIST P-384 elliptic curve)</li>
            <li>DH <xref target="RFC3526" format="default"/> (with a prime modulus of 3072 or larger)</li>
          </ul>
        </li>
      </ul>

      <t>To facilitate selection of appropriate combinations of compliant algorithms, this document provides CNSA compliant user interface CNSA-compliant User Interface suites (UI Suites) suites) <xref target="RFC4308" format="default"/> to implement IPsec on NSS. National Security Systems.
</t>
      <t>The approved CNSA hash function for all purposes is SHA-384, as defined in <xref target="FIPS180" format="default"/>. However, PRF_HMAC_SHA-512 PRF_HMAC_SHA_512 is specified for the IKEv2 PRF Pseudorandom Function (PRF) instead of PRF_HMAC_SHA-384 PRF_HMAC_SHA_384, due to availability. See <xref target="sa" format="default"/> below.
</t>
      <t>For CNSA Suite applications, public key certificates MUST <bcp14>MUST</bcp14> be compliant with the CNSA Suite Certificate and CRL Profile specified in <xref target="RFC8603" format="default"/>.
</t>
      <t>Under certain conditions, such as applications having long-lived data protection
data-protection requirements, systems that do not comply with the requirements of this document are acceptable; see <xref target="long-life" format="default"/>.
</t>
    </section>
    <!-- overview -->

<section anchor="ui-suites" numbered="true" toc="default">
      <name>IPsec User Interface Suites</name>

      <t>User Interface (UI) suites <xref target="RFC4308" format="default"/> 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 <xref target="RFC4303" format="default"/> and for Internet Key Exchange (IKEv2) IKEv2 <xref target="RFC7296" format="default"/>.
  The selection of a UI Suite suite will depend on the key exchange algorithm.  The suite names indicate the Advanced Encryption Standard <xref target="FIPS197" format="default"/> mode, AES key length specified for encryption, and the key exchange algorithm.
</t>
      <t>Although RSA is also a CNSA approved CNSA-approved key establishment algorithm, in IPsec with IKEv2 <xref target="RFC7296" format="default"/> only DH or and ECDH are implemented specified for key exchange. exchange in IKEv2 <xref target="RFC7296" format="default"/>.
 RSA in IPsec is used only for digital signatures. See <xref target="ikev2-authn" format="default"/>.
</t>
      <t>ESP requires negotiation of both a confidentiality algorithm and an integrity algorithm. However, authenticated encryption (AEAD) algorithms for Authenticated Encryption with Associated Data (AEAD) <xref target="RFC5116" format="default"/> do not require a separate integrity algorithm to be negotiated.
 In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM MUST <bcp14>MUST</bcp14> either offer no integrity algorithm, algorithm or indicate the single integrity algorithm NONE (see  Section 3.3 of <xref target="RFC7296" format="default"/>). sectionFormat="of" section="3.3"/>).
</t>
      <t>To be CNSA compliant, IPsec implementations that use the following UI suites MUST <bcp14>MUST</bcp14> use the suite names listed below.  IPsec implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> use names different than those listed here for the suites that are described, described and MUST NOT <bcp14>MUST NOT</bcp14> use the names listed here for suites that do not match these values.  These requirements are necessary for interoperability.
</t>
      <t>Transform names are as listed in the IANA registry for Internet "Internet Key Exchange Version 2 (IKEv2) Parameters. Parameters" registry. Definitions of the transforms are contained in the references specified in that registry.
</t>
      <t>Other UI suites may be acceptable for CNSA compliance. See <xref target="sa" format="default"/> for details.
</t>

      <section anchor="suite-ecdh" numbered="true" toc="default">
        <name>Suite CNSA-GCM-256-ECDH-384</name>
        <ul empty="true"
        <dl newline="true" spacing="compact">
          <li>
            <t>ESP SA:</t>
            <ul empty="true"
            <dt>ESP SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>Integrity: NONE</li>
            </ul>
          </li>
          <li>
            <t>IKEv2 SA:</t>
            <ul empty="true" bits)</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              </dl>
            </dd>
            <dt>IKEv2 SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>PRF: PRF_HMAC_SHA2_512</li>
              <li>Integrity: NONE</li>
              <li>Diffie-Hellman group: 384-bit bits)</dd>
              <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              <dt>Diffie-Hellman group:</dt><dd>384-bit random ECP group</li>
            </ul>
          </li>
        </ul> group</dd>
              </dl>
            </dd>
        </dl>
      </section>
      <!-- suite-ecdh -->

<section anchor="suite-dh3k" numbered="true" toc="default">
        <name>Suite CNSA-GCM-256-DH-3072</name>
        <ul empty="true"
        <dl newline="true" spacing="compact">
          <li>
            <t>ESP SA:</t>
            <ul empty="true"
            <dt>ESP SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>Integrity: NONE</li>
            </ul>
          </li>
          <li>
            <t>IKEv2 SA:</t>
            <ul empty="true" bits)</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              </dl>
            </dd>
            <dt>IKEv2 SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>PRF: PRF_HMAC_SHA2_512</li>
              <li>Integrity: NONE</li>
              <li>Diffie-Hellman group: 3072-bit bits)</dd>
              <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              <dt>Diffie-Hellman group:</dt><dd>3072-bit MODP Group</li>
            </ul>
          </li>
        </ul> group</dd>
              </dl>
              </dd>
        </dl>
      </section>
      <!-- suite-dh3k -->

<section anchor="suite-dh4k" numbered="true" toc="default">
        <name>Suite CNSA-GCM-256-DH-4096</name>
        <ul empty="true"
        <dl newline="true" spacing="compact">
          <li>
            <t>ESP SA:</t>
            <ul empty="true"
            <dt>ESP SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>Integrity: NONE</li>
            </ul>
          </li>
          <li>
            <t>IKEv2 SA:
            </t>
            <ul empty="true" bits)</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              </dl>
            </dd>
            <dt>IKEv2 SA:</dt>
            <dd>
              <dl spacing="compact">
              <li>Encryption: ENCR_AES_GCM_16
              <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</li>
              <li>PRF: PRF_HMAC_SHA2_512</li>
              <li>Integrity: NONE</li>
              <li>Diffie-Hellman group: 4096-bit bits)</dd>
              <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
              <dt>Integrity:</dt><dd>NONE</dd>
              <dt>Diffie-Hellman group:</dt><dd>4096-bit MODP Group</li>
            </ul>
          </li>
        </ul> group</dd>
              </dl>
            </dd>
        </dl>
      </section>
      <!-- suite-dh4k -->

</section>
    <!-- ui-suites -->

<section anchor="ikev2-authn" numbered="true" toc="default">
      <name>IKEv2 Authentication</name>
      <t>Authentication of the IKEv2 Security Association (SA) requires computation of a digital signature.  To be CNSA compliant, digital signatures MUST <bcp14>MUST</bcp14> be generated with SHA-384 as defined in <xref target="RFC8017" format="default"/> together with either ECDSA-384 as defined in [RFC4754] <xref target="RFC4754"/> or RSA with 3072-bit or greater modulus and SHA-384 as defined in <xref target="RFC8017" format="default"/>. modulus.
 (For applications with long data-protection requirements, somewhat different rules apply; see <xref target="long-life" format="default"/>.)
</t>
      <t>Initiators and responders MUST <bcp14>MUST</bcp14> be able to verify ECDSA-384 signatures and MUST <bcp14>MUST</bcp14> be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 signatures.
</t>
      <t>For CNSA compliant CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT <bcp14>MUST NOT</bcp14> be accepted for IKEv2 authentication. A 3072-bit modulus or larger MUST <bcp14>MUST</bcp14> be used for RSA. If the relying party receives a message signed with any authentication method other than an ECDSA-384 or RSA signature signature, it MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> return an AUTHENTICATION_FAILED notification and stop processing the message.
</t>
    </section>
    <!-- ikev2-authn -->

<section anchor="certs" numbered="true" toc="default">
      <name>Certificates</name>
      <t>To be CNSA compliant, the initiator and responder MUST <bcp14>MUST</bcp14> use X.509 certificates that comply with <xref target="RFC8603" format="default"/>. 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 <xref target="RFC7296" format="default"/>, sectionFormat="of" section="3.8"/>, rather than the Identification Data from the Identification Payload that is used to look up policy.
</t>
    </section>
    <!-- certs -->

<section anchor="sa" numbered="true" toc="default">
      <name>IKEv2 Security Associations (SA)</name> (SAs)</name>

<t><xref target="ui-suites" format="default"/> 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 Galois/Counter Mode (GCM) <xref target="RFC4106" format="default"/>  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 Section 3.3 of <xref target="RFC7296" format="default"/>). sectionFormat="of" section="3.3"/>).
</t>

<t>An initiator proposal SHOULD <bcp14>SHOULD</bcp14> be constructed from one or more of the following suites:
</t>

      <ul empty="true" spacing="compact">
        <li>CNSA-GCM-256-ECDH-384,</li>
        <li>CNSA-GCM-256-DH-3072,</li>
        <li>CNSA-GCM-256-DH-4096.</li>
        <li>CNSA-GCM-256-ECDH-384</li>
        <li>CNSA-GCM-256-DH-3072</li>
        <li>CNSA-GCM-256-DH-4096</li>
      </ul>

<t>A responder SHOULD <bcp14>SHOULD</bcp14> 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.
</t>

<t>Nonce construction for AES-GCM using a misuse-resistant technique <xref target="RFC8452" format="default"/> conforms with the requirements of this document and MAY <bcp14>MAY</bcp14> be used if a Federal Information Processing Standard (FIPS) validated implementation is available.
</t>

<t>The named UI suites specify PRF_HMAC_SHA2_512 for the IKEv2 SA PRF transform transform, as PRF_HMAC_SHA2_384 is not listed among required PRF transforms in <xref target="RFC8247" format="default"/>; 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 <bcp14>MUST NOT</bcp14> be used.
</t>

<t>If none of the proposals offered by the initiator consist solely of transforms based on CNSA algorithms (such as those in the UI Suites suites defined in <xref target="ui-suites" format="default"/>, format="default"/>), the responder MUST <bcp14>MUST</bcp14> return a Notify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA compliant CNSA-compliant mode.
</t>

    </section>
    <!-- sa -->

<section anchor="ike-sa-init" numbered="true" toc="default">
      <name>The Key Exchange Payload in the IKE_SA_INIT Exchange</name>
      <t>The key exchange payload is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The CNSA compliant CNSA-compliant initiator and responder MUST <bcp14>MUST</bcp14> each generate an ephemeral key pair to be used in the key exchange.
</t>
      <t>If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected for the SA, the initiator and responder both MUST <bcp14>MUST</bcp14> generate an elliptic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public keys MUST <bcp14>MUST</bcp14> be stored in the key exchange payload as described in <xref target="RFC7296" target="RFC5903" format="default"/>.
</t>
      <t>If the Diffie-Hellman (DH) key exchange is selected for the SA, the initiator and responder both MUST <bcp14>MUST</bcp14> generate a key pair using the appropriately sized MODP group as described in <xref target="RFC3526" format="default"/>. The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA.
</t>

    </section>
    <!-- ike-sa-init -->

<section anchor="ikesa-keygen" numbered="true" toc="default">
      <name>Generating Key Material for the IKE SA</name>

<t>As noted in Section 7 of <xref target="RFC5903" format="default"/>, sectionFormat="of" section="7"/>, the shared secret result of a an ECDH key exchange is the 384 bit 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 accomodate accommodate the prime (e.g. (e.g., 384 octets for 3072 MODP) 3072-bit MODP group) with leading zeros as necessary, as described in Section 2.1.2 of <xref target="RFC2631" format="default"/>. sectionFormat="of" section="2.1.2"/>.
</t>

<t>IKEv2, Section 2.12 <xref target="RFC7296" format="default"/>

<t>IKEv2 allows for the reuse of Diffie-Hellman private keys. keys; see <xref target="RFC7296" sectionFormat="of" section="2.12"/>.  However, there are security concerns related to this practice. Section 5.6.3.3 Section&nbsp;5.6.3.3 of <xref target="SP80056A" format="default"/> states that an ephemeral private key MUST <bcp14>MUST</bcp14> be used in exactly one key establishment transaction and MUST <bcp14>MUST</bcp14> be destroyed (zeroized) as soon as possible. Section 5.8 Section&nbsp;5.8 of <xref target="SP80056A" format="default"/> states that a Diffie-Hellman any shared secret must derived from key establishment <bcp14>MUST</bcp14> be destroyed (zeroized) immediately after its use. CNSA compliant
 CNSA-compliant IPsec systems MUST <bcp14>MUST</bcp14> follow the mandates in <xref target="SP80056A" format="default"/>.
</t>

    </section>
    <!-- ikesa-keygen -->

<section anchor="addl-reqt" numbered="true" toc="default">
      <name>Additional Requirements</name>
      <t>The IPsec protocol AH MUST NOT <bcp14>MUST NOT</bcp14> be used in CNSA compliant CNSA-compliant implementations.
</t>
      <t>A Diffie-Hellman group MAY <bcp14>MAY</bcp14> be negotiated for a Child SA as described in Section 1.3 of <xref target="RFC7296" format="default"/> sectionFormat="of" section="1.3"/>,
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 <bcp14>MUST</bcp14> match the value of the transform used by the IKEv2 SA.
</t>
      <t>Per <xref target="RFC7296" format="default"/>, if a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST <bcp14>MUST</bcp14> include the Diffie-Hellman group of the KEi. For CNSA compliant CNSA-compliant IPsec compliant implementations, the Diffie-Hellman group of the KEi MUST <bcp14>MUST</bcp14> use the same group used in the IKE_INIT_SA.
</t>
      <t>For IKEv2, rekeying of the CREATE_CHILD_SA MUST <bcp14>MUST</bcp14> be supported by both parties. The initiator of this exchange MAY <bcp14>MAY</bcp14> include a new Diffie-Hellman key; if it is included, it MUST <bcp14>MUST</bcp14> use the same group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diffie-Hellman key, the responder MUST <bcp14>MUST</bcp14> include a Diffie-Hellman key, and it MUST <bcp14>MUST</bcp14> use the same group.
</t>
      <t>For CNSA compliant CNSA-compliant systems, the IKEv2 authentication method MUST <bcp14>MUST</bcp14> use an end-entity certificate provided by the authenticating party. Identification Payloads (Idi (IDi and IDr) in the IKE_AUTH exchanges MUST NOT <bcp14>MUST NOT</bcp14> be used for the IKEv2 authentication method , but may be used for policy lookup.
</t>
      <t>The administrative user interface User Interface (UI) for a system that conforms to this profile MUST <bcp14>MUST</bcp14> allow the operator to specify a single suite.  If only one suite is specified in the administrative UI, the IKEv2 implementation MUST <bcp14>MUST</bcp14> only offer algorithms for that one suite.
</t>
      <t>The administrative UI MAY <bcp14>MAY</bcp14> allow the operator to specify more than one suite; if it allows this, it MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> 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.)
</t>
    </section>
    <!-- addl-reqt -->

<section anchor="long-life" numbered="true" toc="default">
      <name>Guidance for Applications With with Long Data-Protection Requirements</name>

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

<t>For new applications, confidentiality and integrity requirements from the sections above MUST <bcp14>MUST</bcp14> be followed, with the addition of a PSK Pre-Shared Key (PSK) mixed in as defined in <xref target="RFC8784" format="default"/>.
</t>

<t>Installations currently using IKEv1 with PSK MUST PSKs <bcp14>MUST</bcp14> (1) use AES in cipher block chaining mode (AES-CBC) in conjunction with a CNSA compliant CNSA-compliant integrity algorithm (e.g. AUTH_HMAC_SHA2_384_192), (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 with PSK PSKs <xref target="RFC8784" format="default"/> as soon as implementations become available.
</t>

<!--  Removed as redundant.
<t>For all applications to which this section applies, PSK authentication MUST be performed using HMAC-SHA-384 <xref target="RFC4868" format="default"/>.
</t>
-->

<t>Specific guidance for systems not compliant with the requirements of this document, including non-GCM modes and PSK length length, and PSK randomness, will be defined in solution specific
solution-specific requirements appropriate to the application.
 Details of those requirements will depend on the program under which the commercial NSS National Security Systems solution is developed (e.g. (e.g., an NSA Commercial Solutions for Classified Capability Package).
</t>

    </section>
    <!-- long-life -->

<section anchor="sec-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>

<t>This document inherits all of the security considerations of the IPsec and IKEv2 documents, including <xref target="RFC7296" format="default"/>, <xref target="RFC4303" format="default"/>, <xref target="RFC4754" format="default"/>, and <xref target="RFC8221" format="default"/>.
</t>

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

<t>When selecting a mode for the AES encryption <xref target="RFC5116" format="default"/> , format="default"/>, be aware that nonce reuse can result in a loss of confidentiality. Nonce reuse is catastrophic for GCM GCM, since it also results in a loss of integrity.
</t>
    </section>
    <!-- sec-considerations -->

<section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is asked has added the UI suites defined in this document to amend the registry titled "Cryptographic Suites for IKEv1, IKEv2, and IPsec" registry located at https://www.iana.org/assignments/crypto-suites as described in this section. The registry consists of a text string and an RFC number that lists the associated transforms. The UI suites defined in this document are listed, with this document as the RFC reference. <eref target="https://www.iana.org/assignments/crypto-suites" brackets="angle"/>:
</t>

<table>
<thead><tr><td align="center">Identifier</td><td align="center">Reference</td></tr></thead>
<thead><tr><th align="center">Identifier</th>
<th align="center">Reference</th></tr></thead>
<tbody>
<tr><td>CNSA-GCM-256-ECDH-384</td><td>[this document when published]</td></tr>
<tr><td>CNSA-GCM-256-DH-3072</td><td>[this document when published]</td></tr>
<tr><td>CNSA-GCM-256-DH-4096</td><td>[this document when published]</td></tr>
<tr><td>CNSA-GCM-256-ECDH-384</td><td>RFC 9206</td></tr>
<tr><td>CNSA-GCM-256-DH-3072</td><td>RFC 9206</td></tr>
<tr><td>CNSA-GCM-256-DH-4096</td><td>RFC 9206</td></tr>
</tbody>
</table>

    </section>
    <!--  iana -->

</middle>
  <back>
    <!--  *****BACK MATTER ***** -->

<references>   <name>References</name>
   <references>   <name>Normative References</name>
      <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Policies.htm">
         <front>
            <title>Use of Public Standards for Secure Information Sharing</title>
            <seriesInfo name="CNSSP" value="15"/>
            <author>
              <organization>Committee for National Security Systems</organization>
            </author>
            <date month="October" year="2016"/>
         </front>
        <refcontent>CNSSP 15</refcontent>
      </reference>   <!-- CNSA -->

      <reference anchor="FIPS180" target="https://csrc.nist.gov/publications/detail/fips/180/4/final">
         <front>
            <title>Secure Hash Standard (SHS)</title>
            <seriesInfo name="Federal Information Processing Standard" value="180-4"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2015"/>
         </front>
        <refcontent>Federal Information Processing Standard 180-4</refcontent>
       <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
      </reference>   <!-- FIPS180 -->

      <reference anchor="FIPS186" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf"> target="https://csrc.nist.gov/publications/detail/fips/186/4/final">
         <front>
            <title>Digital Signature Standard (DSS)</title>
            <seriesInfo name="NIST Federal Information Processing Standard" value="186-4"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="July" year="2013"/>
         </front>
        <refcontent>NIST Federal Information Processing Standard 186-4</refcontent>
       <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
      </reference>   <!-- FIPS186 -->

      <reference anchor="FIPS197" target="https://csrc.nist.gov/publications/detail/fips/197/final">
         <front>
            <title>Advanced Encryption Standard (AES)</title>
            <seriesInfo name="Federal Information Processing Standard" value="197"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="November" year="2001"/>
         </front>
        <refcontent>Federal Information Processing Standard 197</refcontent>
       <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
      </reference>   <!-- FIPS197 -->

      <reference anchor="SP80056A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf"> target="https://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
            <seriesInfo name="NIST Special Publication" value="800-56A, Revision 3"/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="April" year="2018"/>
         </front>
        <refcontent>NIST Special Publication 800-56A, Revision 3</refcontent>
       <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
      </reference>   <!-- SP80056A -->

      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2631.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4308.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4308.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4754.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4754.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4868.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5116.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5903.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5903.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"/>

   </references>   <!-- Normative -->

   <references>   <name>Informative References</name>
      <reference anchor="SP80059" target="https://csrc.nist.gov/publications/detail/sp/800-59/final">
         <front>
            <title>Guideline for Identifying an Information System as a National Security System</title>
            <seriesInfo name="Special Publication 800-59" value=""/>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2003"/>
         </front>
        <refcontent>Special Publication 800-59</refcontent>
       <seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
      </reference>   <!-- SP80059 -->

      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8452.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8452.xml"/>

    </references>   <!-- Informative -->
</references>   <!-- References -->

</back>
  <!--  ===== END BACK MATTER ===== -->
</rfc>