rfc9206.original.xml   rfc9206.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- draft submitted in xml v3 -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" ipr="trust200902 <!DOCTYPE rfc [
" docName="draft-corcoran-cnsa-ipsec-profile-06" obsoletes="" updates="" submiss <!ENTITY nbsp "&#160;">
ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortR <!ENTITY zwsp "&#8203;">
efs="true" version="3"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-corcoran-cnsa-ipsec-profile-06" number="9206" obsoletes="" updates="" submissio
nType="independent" category="info" xml:lang="en" tocInclude="true" tocDepth="2"
symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="CNSA Suite IPsec Profile">Commercial National Security Algori thm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</title> <title abbrev="CNSA Suite IPsec Profile">Commercial National Security Algori thm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec)</title>
<seriesInfo name="Internet-Draft" value="draft-corcoran-cnsa-ipsec-profile-0 <seriesInfo name="RFC" value="9206"/>
6"/>
<author fullname="Laura Corcoran" initials="L." surname="Corcoran"> <author fullname="Laura Corcoran" initials="L." surname="Corcoran">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency</organization>
<address> <address>
<email>lscorco@nsa.gov</email> <email>lscorco@nsa.gov</email>
</address> </address>
</author> </author>
<author fullname="Michael Jenkins" initials="M." surname="Jenkins"> <author fullname="Michael Jenkins" initials="M." surname="Jenkins">
<organization abbrev="NSA">National Security Agency</organization> <organization abbrev="NSA">National Security Agency - Center for Cybersecu rity Standards</organization>
<address> <address>
<email>mjjenki@cyber.nsa.gov</email> <email>mjjenki@cyber.nsa.gov</email>
</address> </address>
</author> </author>
<date year="2022"/> <date year="2022" month="February" />
<keyword>post quantum</keyword>
<keyword>quantum resistant</keyword>
<keyword>NSA</keyword>
<abstract> <abstract>
<t>The United States Government has published the National Security Agency 's Commercial National Security Algorithm (CNSA) Suite, which defines cryptograp hic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Sui te algorithms in Internet Protocol Security. It applies to the capabilities, con figuration, and operation of all components of US National Security Systems that employ IPsec. US National Security Systems are described in NIST Special Public ation 800-59. It is also appropriate for all other US Government systems that pr ocess high-value information. It is made publicly available for use by developer s and operators of these and any other system deployments. <t>The United States Government has published the National Security Agency 's Commercial National Security Algorithm (CNSA) Suite, which defines cryptograp hic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Sui te algorithms in Internet Protocol Security (IPsec). It applies to the capabilit ies, configuration, and operation of all components of US National Security Syst ems (described in NIST Special Publication 800-59) that employ IPsec. This docum ent is also appropriate for all other US Government systems that process high-va lue information. It is made publicly available for use by developers and operato rs of these and any other system deployments.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies conventions for using the United States Nationa l Security Agency's Commercial National Security Algorithm (CNSA) Suite algorith ms <xref target="CNSA" format="default"/> in Internet Protocol Security (IPsec). It defines CNSA-based user interface suites ("UI suites") describing sets of se curity configurations for Internet Key Exchange version 2 (IKEv2) and IP Encapsu lating Security Payload (ESP) protocol use, and specifies certain other constrai nts with respect to algorithm selection and configuration. It applies to the cap abilities, configuration, and operation of all components of US National Securit y Systems that employ IPsec. US National Security Systems are described in NIST Special Publication 800-59 <xref target="SP80059" format="default"/>. It is also appropriate for all other US Government systems that process high-value informa tion. It is made publicly available for use by developers and operators of these and any other system deployments. <t>This document specifies the conventions for using the United States Nat ional Security Agency's (NSA's) Commercial National Security Algorithm (CNSA) Su ite algorithms <xref target="CNSA" format="default"/> in Internet Protocol Secur ity (IPsec). It defines CNSA-based User Interface suites ("UI suites") describin g sets of security configurations for Internet Key Exchange Protocol Version 2 ( IKEv2) and IP Encapsulating Security Payload (ESP) protocol use, and specifies c ertain other constraints with respect to algorithm selection and configuration. It applies to the capabilities, configuration, and operation of all components o f US National Security Systems (described in NIST Special Publication 800-59 <xr ef target="SP80059" format="default"/>) that employ IPsec. This document is also appropriate for all other US Government systems that process high-value informa tion. It is made publicly available for use by developers and operators of these and any other system deployments.
</t> </t>
<t>The reader is assumed to have familiarity with the following: <t>The reader is assumed to have familiarity with the following:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>
<xref target="RFC4303" format="default"/>, IP Encapsulating Security P
ayload (ESP)</li>
<li> <li>
<xref target="RFC5280" format="default"/>, Internet X.509 Public Key I "<xref target="RFC4303" format="title"/>" <xref target="RFC4303" format=
nfrastructure Certificate and Certificate Revocation List (CRL) Profile</li> "default"/>
</li>
<li> <li>
<xref target="RFC7296" format="default"/>, Internet Key Exchange Versi "<xref target="RFC5280" format="title"/>" <xref target="RFC5280" format=
on 2 (IKEv2)</li> "default"/>
</li>
<li> <li>
<xref target="RFC8221" format="default"/>, Cryptographic Algorithm Imp "<xref target="RFC7296" format="title"/>" <xref target="RFC7296" format=
lementation Requirements and Usage Guidance for Encapsulating Security Payload ( "default"/>
ESP) and Authentication Header (AH)</li> </li>
<li> <li>
<xref target="RFC8603" format="default"/>, Commercial National Securit "<xref target="RFC8221" format="title"/>" <xref target="RFC8221" format=
y Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profi "default"/>
le</li> </li>
<li>"<xref target="RFC8603" format="title"/>" <xref target="RFC8603" form
at="default"/></li>
</ul> </ul>
</section> </section>
<!-- intro -->
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
this document are to be interpreted as described in BCP 14 <xref target="RFC2119 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
" format="default"/> <xref target="RFC8174" format="default"/> when, and only wh "<bcp14>SHOULD NOT</bcp14>",
en, they appear in all capitals, as shown here. "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>AES refers to the Advanced Encryption Standard. ECDSA and ECDH refer to are to be interpreted as described in BCP&nbsp;14
the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
Curve Diffie-Hellman (ECDH), respectively. DH refers to Diffie-Hellman key estab when, they appear in all capitals, as shown here.</t>
lishment. RSA refers to RSA signature. <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 estab
lishment. RSA refers to an RSA signature.
</t> </t>
</section> </section>
<!-- terminology -->
<section anchor="cnsa" numbered="true" toc="default"> <section anchor="cnsa" numbered="true" toc="default">
<name>The Commercial National Security Algorithm Suite</name> <name>The Commercial National Security Algorithm Suite</name>
<t>The National Security Agency (NSA) profiles commercial cryptographic al gorithms and protocols as part of its mission to support secure, interoperable c ommunications for US Government National Security Systems. To this end, it publi shes guidance both to assist with the US Government transition to new algorithms , and to provide vendors - and the Internet community in general - with informat ion concerning their proper use and configuration. <t>The NSA profiles commercial cryptographic algorithms and protocols as p art of its mission to support secure, interoperable communications for US Govern ment National Security Systems. To this end, it publishes guidance to both (1)&n bsp;assist with the US Government transition to new algorithms and (2)&nbsp;prov ide vendors -- and the Internet community in general -- with information concern ing their proper use and configuration.
</t> </t>
<t>Recently, cryptographic transition plans have become overshadowed by th e prospect of the development of a cryptographically-relevant quantum computer. NSA has established the Commercial National Security Algorithm (CNSA) Suite to p rovide vendors and IT users near-term flexibility in meeting their information a ssurance interoperability requirements. The purpose behind this flexibility is t o avoid vendors and customers making two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography i n the near future. <t>Recently, cryptographic transition plans have become overshadowed by th e 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 informati on assurance interoperability requirements. The purpose behind this flexibility is to avoid vendors and customers making two major transitions in a relatively s hort timeframe, as we anticipate a need to shift to quantum-resistant cryptograp hy in the near future.
</t> </t>
<t>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 cry ptographic guidance (e.g., NIST Special Publications) to properly protect Intern et traffic and data-at-rest for US Government National Security Systems. <t>The NSA is authoring a set of RFCs, including this one, to provide upda ted guidance concerning the use of certain commonly available commercial algorit hms in IETF protocols. These RFCs can be used in conjunction with other RFCs and cryptographic guidance (e.g., NIST Special Publications) to properly protect In ternet traffic and data-at-rest for US Government National Security Systems.
</t> </t>
</section> </section>
<!-- cnsa -->
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>CNSA Compliant IPsec Overview</name> <name>CNSA-Compliant IPsec Overview</name>
<t>CNSA compliant implementations for IPsec MUST use IKEv2 <xref target="R
FC7296" format="default"/>. <t>CNSA-compliant implementations for IPsec <bcp14>MUST</bcp14> use IKEv2
<xref target="RFC7296" format="default"/>.
</t> </t>
<t>Implementing a CNSA compliant IPsec system requires cryptographic algor ithm selection for both the IKEv2 and ESP protocols. The following CNSA requirem ents apply to IPsec: <t>Implementing a CNSA-compliant IPsec system requires cryptographic algor ithm selection for both the IKEv2 and ESP protocols. The following CNSA requirem ents apply to IPsec:
</t> </t>
<ul empty="true" spacing="compact">
<li>
<t>Encryption:</t> <t>Encryption:</t>
<ul empty="true" spacing="compact"> <ul empty="true" spacing="compact">
<li>AES <xref target="FIPS197" format="default"/> (with key size 256 bits)</li> <li>AES <xref target="FIPS197" format="default"/> (with key size 256 b its)</li>
</ul> </ul>
</li>
</ul>
<ul empty="true" spacing="compact">
<li>
<t>Digital Signature:</t> <t>Digital Signature:</t>
<ul empty="true" spacing="compact"> <ul empty="true" spacing="compact">
<li>ECDSA <xref target="FIPS186" format="default"/> (using the NIST <li>ECDSA <xref target="FIPS186" format="default"/> (using the NIST P-
P-384 elliptic curve)</li> 384 elliptic curve)</li>
<li>RSA <xref target="FIPS186" format="default"/> (with a modulus of <li>RSA <xref target="FIPS186" format="default"/> (with a modulus of 3
3072 bits or larger)</li> 072 bits or larger)</li>
</ul> </ul>
</li>
</ul>
<ul empty="true" spacing="compact">
<li>
<t>Key Establishment:</t> <t>Key Establishment:</t>
<ul empty="true" spacing="compact"> <ul empty="true" spacing="compact">
<li>ECDH <xref target="SP80056A" format="default"/> (using the NIST P-384 elliptic curve)</li> <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 modul us of 3072 or larger)</li> <li>DH <xref target="RFC3526" format="default"/> (with a prime modul us of 3072 or larger)</li>
</ul> </ul>
</li>
</ul> <t>To facilitate selection of appropriate combinations of compliant algori
<t>To facilitate selection of appropriate combinations of compliant algori thms, this document provides CNSA-compliant User Interface suites (UI suites) <x
thms, this document provides CNSA compliant user interface suites (UI Suites) <x ref target="RFC4308" format="default"/> to implement IPsec on National Security
ref target="RFC4308" format="default"/> to implement IPsec on NSS. Systems.
</t> </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 is spec ified for the IKEv2 PRF instead of PRF_HMAC_SHA-384 due to availability. See <xr ef target="sa" format="default"/> below. <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 is spec ified for the IKEv2 Pseudorandom Function (PRF) instead of PRF_HMAC_SHA_384, due to availability. See <xref target="sa" format="default"/> below.
</t> </t>
<t>For CNSA Suite applications, public key certificates MUST be compliant with the CNSA Suite Certificate and CRL Profile specified in <xref target="RFC86 03" format="default"/>. <t>For CNSA Suite applications, public key certificates <bcp14>MUST</bcp14 > be compliant with the CNSA Suite Certificate and CRL Profile specified in <xre f target="RFC8603" format="default"/>.
</t> </t>
<t>Under certain conditions, such as applications having long-lived data p <t>Under certain conditions, such as applications having long-lived
rotection requirements, systems that do not comply with the requirements of this data-protection requirements, systems that do not comply with the requirements o
document are acceptable; see <xref target="long-life" format="default"/>. f this document are acceptable; see <xref target="long-life" format="default"/>.
</t> </t>
</section> </section>
<!-- overview -->
<section anchor="ui-suites" numbered="true" toc="default"> <section anchor="ui-suites" numbered="true" toc="default">
<name>IPsec User Interface Suites</name> <name>IPsec User Interface Suites</name>
<t>User Interface (UI) suites <xref target="RFC4308" format="default"/> ar <t>User Interface (UI) suites <xref target="RFC4308" format="default"/> ar
e named suites that cover some typical security policy options for IPsec. Use of e 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 suite UI suites does not change the IPsec protocol in any way. The following UI suite
s provide cryptographic algorithm choices for ESP <xref target="RFC4303" format= s provide cryptographic algorithm choices for ESP <xref target="RFC4303" format=
"default"/> and for Internet Key Exchange (IKEv2) <xref target="RFC7296" format= "default"/> and for IKEv2 <xref target="RFC7296" format="default"/>.
"default"/>. The selection of a UI Suite will depend on the key exchange algori The selection of a UI suite will depend on the key exchange algorithm. The su
thm. The suite names indicate the Advanced Encryption Standard <xref target="FI ite names indicate the Advanced Encryption Standard <xref target="FIPS197" forma
PS197" format="default"/> mode, AES key length specified for encryption, and the t="default"/> mode, AES key length specified for encryption, and the key exchang
key exchange algorithm. e algorithm.
</t> </t>
<t>Although RSA is also a CNSA approved key establishment algorithm, in IP <t>Although RSA is also a CNSA-approved key establishment algorithm, only
sec with IKEv2 <xref target="RFC7296" format="default"/> only DH or ECDH are imp DH and ECDH are specified for key exchange in IKEv2 <xref target="RFC7296" forma
lemented for key exchange. RSA in IPsec is used only for digital signatures. See t="default"/>.
<xref target="ikev2-authn" format="default"/>. RSA in IPsec is used only for digital signatures. See <xref target="ikev2-authn
" format="default"/>.
</t> </t>
<t>ESP requires negotiation of both a confidentiality algorithm and an int <t>ESP requires negotiation of both a confidentiality algorithm and an int
egrity algorithm. However, authenticated encryption (AEAD) algorithms <xref targ egrity algorithm. However, algorithms for Authenticated Encryption with Associat
et="RFC5116" format="default"/> do not require a separate integrity algorithm to ed Data (AEAD) <xref target="RFC5116" format="default"/> do not require a separa
be negotiated. In particular, since AES-GCM is an AEAD algorithm, ESP implement te integrity algorithm to be negotiated.
ing AES-GCM MUST either offer no integrity algorithm, or indicate the single int In particular, since AES-GCM is an AEAD algorithm, ESP implementing AES-GCM <bc
egrity algorithm NONE (see Section 3.3 of <xref target="RFC7296" format="defaul p14>MUST</bcp14> either offer no integrity algorithm or indicate the single inte
t"/>). grity algorithm NONE (see <xref target="RFC7296" sectionFormat="of" section="3.3
"/>).
</t> </t>
<t>To be CNSA compliant, IPsec implementations that use the following UI s uites MUST use the suite names listed below. IPsec implementations SHOULD NOT u se 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. <t>To be CNSA compliant, IPsec implementations that use the following UI s uites <bcp14>MUST</bcp14> use the suite names listed below. IPsec implementatio ns <bcp14>SHOULD NOT</bcp14> use names different than those listed here for the suites that are described and <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>
<t>Transform names are as listed in the IANA registry for Internet Key Exc hange Version 2 (IKEv2) Parameters. Definitions of the transforms are contained in the references specified in that registry. <t>Transform names are as listed in the IANA "Internet Key Exchange Versio n 2 (IKEv2) Parameters" registry. Definitions of the transforms are contained in the references specified in that registry.
</t> </t>
<t>Other UI suites may be acceptable for CNSA compliance. See <xref target ="sa" format="default"/> for details. <t>Other UI suites may be acceptable for CNSA compliance. See <xref target ="sa" format="default"/> for details.
</t> </t>
<section anchor="suite-ecdh" numbered="true" toc="default"> <section anchor="suite-ecdh" numbered="true" toc="default">
<name>Suite CNSA-GCM-256-ECDH-384</name> <name>Suite CNSA-GCM-256-ECDH-384</name>
<ul empty="true" spacing="compact"> <dl newline="true" spacing="compact">
<li> <dt>ESP SA:</dt>
<t>ESP SA:</t> <dd>
<ul empty="true" spacing="compact"> <dl spacing="compact">
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>Integrity: NONE</li> dd>
</ul> <dt>Integrity:</dt><dd>NONE</dd>
</li> </dl>
<li> </dd>
<t>IKEv2 SA:</t> <dt>IKEv2 SA:</dt>
<ul empty="true" spacing="compact"> <dd>
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dl spacing="compact">
<li>PRF: PRF_HMAC_SHA2_512</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>Integrity: NONE</li> dd>
<li>Diffie-Hellman group: 384-bit random ECP group</li> <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
</ul> <dt>Integrity:</dt><dd>NONE</dd>
</li> <dt>Diffie-Hellman group:</dt><dd>384-bit random ECP group</dd>
</ul> </dl>
</dd>
</dl>
</section> </section>
<!-- suite-ecdh -->
<section anchor="suite-dh3k" numbered="true" toc="default"> <section anchor="suite-dh3k" numbered="true" toc="default">
<name>Suite CNSA-GCM-256-DH-3072</name> <name>Suite CNSA-GCM-256-DH-3072</name>
<ul empty="true" spacing="compact"> <dl newline="true" spacing="compact">
<li> <dt>ESP SA:</dt>
<t>ESP SA:</t> <dd>
<ul empty="true" spacing="compact"> <dl spacing="compact">
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>Integrity: NONE</li> dd>
</ul> <dt>Integrity:</dt><dd>NONE</dd>
</li> </dl>
<li> </dd>
<t>IKEv2 SA:</t> <dt>IKEv2 SA:</dt>
<ul empty="true" spacing="compact"> <dd>
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dl spacing="compact">
<li>PRF: PRF_HMAC_SHA2_512</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>Integrity: NONE</li> dd>
<li>Diffie-Hellman group: 3072-bit MODP Group</li> <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
</ul> <dt>Integrity:</dt><dd>NONE</dd>
</li> <dt>Diffie-Hellman group:</dt><dd>3072-bit MODP group</dd>
</ul> </dl>
</dd>
</dl>
</section> </section>
<!-- suite-dh3k -->
<section anchor="suite-dh4k" numbered="true" toc="default"> <section anchor="suite-dh4k" numbered="true" toc="default">
<name>Suite CNSA-GCM-256-DH-4096</name> <name>Suite CNSA-GCM-256-DH-4096</name>
<ul empty="true" spacing="compact"> <dl newline="true" spacing="compact">
<li> <dt>ESP SA:</dt>
<t>ESP SA:</t> <dd>
<ul empty="true" spacing="compact"> <dl spacing="compact">
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>Integrity: NONE</li> dd>
</ul> <dt>Integrity:</dt><dd>NONE</dd>
</li> </dl>
<li> </dd>
<t>IKEv2 SA: <dt>IKEv2 SA:</dt>
</t> <dd>
<ul empty="true" spacing="compact"> <dl spacing="compact">
<li>Encryption: ENCR_AES_GCM_16 (with key size 256 bits)</li> <dt>Encryption:</dt><dd>ENCR_AES_GCM_16 (with key size 256 bits)</
<li>PRF: PRF_HMAC_SHA2_512</li> dd>
<li>Integrity: NONE</li> <dt>PRF:</dt><dd>PRF_HMAC_SHA2_512</dd>
<li>Diffie-Hellman group: 4096-bit MODP Group</li> <dt>Integrity:</dt><dd>NONE</dd>
</ul> <dt>Diffie-Hellman group:</dt><dd>4096-bit MODP group</dd>
</li> </dl>
</ul> </dd>
</dl>
</section> </section>
<!-- suite-dh4k -->
</section> </section>
<!-- ui-suites -->
<section anchor="ikev2-authn" numbered="true" toc="default"> <section anchor="ikev2-authn" numbered="true" toc="default">
<name>IKEv2 Authentication</name> <name>IKEv2 Authentication</name>
<t>Authentication of the IKEv2 Security Association (SA) requires computat <t>Authentication of the IKEv2 Security Association (SA) requires computat
ion of a digital signature. To be CNSA compliant, digital signatures MUST be ge ion of a digital signature. To be CNSA compliant, digital signatures <bcp14>MUS
nerated with either ECDSA-384 as defined in [RFC4754] or RSA with 3072-bit or gr T</bcp14> be generated with SHA-384 as defined in <xref target="RFC8017" format=
eater modulus and SHA-384 as defined in <xref target="RFC8017" format="default"/ "default"/> together with either ECDSA-384 as defined in <xref target="RFC4754"/
>. (For applications with long data-protection requirements, somewhat different > or RSA with 3072-bit or greater modulus.
rules apply; see <xref target="long-life" format="default"/>.) (For applications with long data-protection requirements, somewhat different ru
les apply; see <xref target="long-life" format="default"/>.)
</t> </t>
<t>Initiators and responders MUST be able to verify ECDSA-384 signatures a nd MUST be able to verify RSA with 3072-bit or 4096-bit modulus and SHA-384 sign atures. <t>Initiators and responders <bcp14>MUST</bcp14> be able to verify ECDSA-3 84 signatures and <bcp14>MUST</bcp14> be able to verify RSA with 3072-bit or 409 6-bit modulus and SHA-384 signatures.
</t> </t>
<t>For CNSA compliant systems, authentication methods other than ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. A 3072-bit modulus or lar ger MUST be used for RSA. If the relying party receives a message signed with an y authentication method other than ECDSA-384 or RSA signature it MUST return an AUTHENTICATION_FAILED notification and stop processing the message. If the relyi ng 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 mes sage. <t>For CNSA-compliant systems, authentication methods other than ECDSA-384 or RSA <bcp14>MUST NOT</bcp14> be accepted for IKEv2 authentication. A 3072-bit modulus or larger <bcp14>MUST</bcp14> be used for RSA. If the relying party rec eives a message signed with any authentication method other than an ECDSA-384 or RSA signature, it <bcp14>MUST</bcp14> return an AUTHENTICATION_FAILED notificat ion and stop processing the message. If the relying party receives a message sig ned with RSA using less than a 3072-bit modulus, it <bcp14>MUST</bcp14> return a n AUTHENTICATION_FAILED notification and stop processing the message.
</t> </t>
</section> </section>
<!-- ikev2-authn -->
<section anchor="certs" numbered="true" toc="default"> <section anchor="certs" numbered="true" toc="default">
<name>Certificates</name> <name>Certificates</name>
<t>To be CNSA compliant, the initiator and responder MUST use X.509 certif icates that comply with <xref target="RFC8603" format="default"/>. Peer authenti cation decisions must be based on the Subject or Subject Alternative Name from t he certificate that contains the key used to validate the signature in the Authe ntication Payload defined in Section 3.8 of <xref target="RFC7296" format="defau lt"/>, rather than the Identification Data from the Identification Payload that is used to look up policy. <t>To be CNSA compliant, the initiator and responder <bcp14>MUST</bcp14> u se X.509 certificates that comply with <xref target="RFC8603" format="default"/> . Peer authentication decisions must be based on the Subject or Subject Alternat ive Name from the certificate that contains the key used to validate the signatu re in the Authentication Payload as defined in <xref target="RFC7296" sectionFor mat="of" section="3.8"/>, rather than the Identification Data from the Identific ation Payload that is used to look up policy.
</t> </t>
</section> </section>
<!-- certs -->
<section anchor="sa" numbered="true" toc="default"> <section anchor="sa" numbered="true" toc="default">
<name>IKEv2 Security Associations (SA)</name> <name>IKEv2 Security Associations (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 diffe r in the key exchange algorithm. 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"/>). <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 diffe r in the key exchange algorithm. 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 <xref target="RF C7296" sectionFormat="of" section="3.3"/>).
</t> </t>
<t>An initiator proposal SHOULD be constructed from one or more of the following suites: <t>An initiator proposal <bcp14>SHOULD</bcp14> be constructed from one or more o f the following suites:
</t> </t>
<ul empty="true" spacing="compact"> <ul spacing="compact">
<li>CNSA-GCM-256-ECDH-384,</li> <li>CNSA-GCM-256-ECDH-384</li>
<li>CNSA-GCM-256-DH-3072,</li> <li>CNSA-GCM-256-DH-3072</li>
<li>CNSA-GCM-256-DH-4096.</li> <li>CNSA-GCM-256-DH-4096</li>
</ul> </ul>
<t>A responder SHOULD accept proposals constructed from at least one of the thre e named suites. Other UI suites may result in acceptable proposals (such as thos e based on PRF_HMAC_SHA2_384); however, these are provided to promote interopera bility. <t>A responder <bcp14>SHOULD</bcp14> accept proposals constructed from at least one of the three named suites. Other UI suites may result in acceptable proposal s (such as those based on PRF_HMAC_SHA2_384); however, these are provided to pro mote interoperability.
</t> </t>
<t>Nonce construction for AES-GCM using a misuse-resistant technique <xref targ et="RFC8452" format="default"/> conforms with the requirements of this document and MAY be used if a Federal Information Processing Standard (FIPS) validated im plementation is available. <t>Nonce construction for AES-GCM using a misuse-resistant technique <xref targe t="RFC8452" format="default"/> conforms with the requirements of this document a nd <bcp14>MAY</bcp14> be used if a Federal Information Processing Standard (FIPS ) validated implementation is available.
</t> </t>
<t>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 <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 di fference in performance is negligible. However, SHA-384 is the official CNSA alg orithm for computing a condensed representation of information. Therefore, the P RF_HMAC_SHA2_384 transform is CNSA compliant if it is available to initiator and responder. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2_512 MUST NOT be used. <t>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 <xref targe t="RFC8247" format="default"/>; therefore, implementation of the latter is likel y to be scarce. The security level of PRF_HMAC_SHA2_512 is comparable, and the d ifference in performance is negligible. However, SHA-384 is the official CNSA al gorithm for computing a condensed representation of information. Therefore, the PRF_HMAC_SHA2_384 transform is CNSA compliant if it is available to the initiato r and responder. Any PRF transform other than PRF_HMAC_SHA2_384 or PRF_HMAC_SHA2 _512 <bcp14>MUST NOT</bcp14> be used.
</t> </t>
<t>If none of the proposals offered by the initiator consist solely of transform s based on CNSA algorithms (such as those in the UI Suites defined in <xref targ et="ui-suites" format="default"/>, the responder MUST return a Notify payload wi th the error NO_PROPOSAL_CHOSEN when operating in CNSA compliant mode. <t>If none of the proposals offered by the initiator consist solely of transform s based on CNSA algorithms (such as those in the UI suites defined in <xref targ et="ui-suites" format="default"/>), the responder <bcp14>MUST</bcp14> return a N otify payload with the error NO_PROPOSAL_CHOSEN when operating in CNSA-compliant mode.
</t> </t>
</section> </section>
<!-- sa -->
<section anchor="ike-sa-init" numbered="true" toc="default"> <section anchor="ike-sa-init" numbered="true" toc="default">
<name>The Key Exchange Payload in the IKE_SA_INIT Exchange</name> <name>The Key Exchange Payload in the IKE_SA_INIT Exchange</name>
<t>The key exchange payload is used to exchange Diffie-Hellman public numb ers as part of a Diffie-Hellman key exchange. The CNSA compliant initiator and r esponder MUST each generate an ephemeral key pair to be used in the key exchange . <t>The key exchange payload is used to exchange Diffie-Hellman public numb ers as part of a Diffie-Hellman key exchange. The CNSA-compliant initiator and r esponder <bcp14>MUST</bcp14> each generate an ephemeral key pair to be used in t he key exchange.
</t> </t>
<t>If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected fo r 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 store d in the key exchange payload as in <xref target="RFC7296" format="default"/>. <t>If the Elliptic Curve Diffie-Hellman (ECDH) key exchange is selected fo r the SA, the initiator and responder both <bcp14>MUST</bcp14> generate an ellip tic curve (EC) key pair using the P-384 elliptic curve. The ephemeral public key s <bcp14>MUST</bcp14> be stored in the key exchange payload as described in <xre f target="RFC5903" format="default"/>.
</t> </t>
<t>If the Diffie-Hellman (DH) key exchange is selected for the SA, the ini tiator and responder both MUST 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 gr eater modulus for the SA. <t>If the Diffie-Hellman (DH) key exchange is selected for the SA, the ini tiator and responder both <bcp14>MUST</bcp14> generate a key pair using the appr opriately sized MODP group as described in <xref target="RFC3526" format="defaul t"/>. The size of the MODP group will be determined by the selection of either a 3072-bit or greater modulus for the SA.
</t> </t>
</section> </section>
<!-- ike-sa-init -->
<section anchor="ikesa-keygen" numbered="true" toc="default"> <section anchor="ikesa-keygen" numbered="true" toc="default">
<name>Generating Key Material for the IKE SA</name> <name>Generating Key Material for the IKE SA</name>
<t>As noted in Section 7 of <xref target="RFC5903" format="default"/>, the share d secret result of a 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 ne eded to accomodate the prime (e.g. 384 octets for 3072 MODP) with leading zeros as necessary, as described in Section 2.1.2 of <xref target="RFC2631" format="de fault"/>. <t>As noted in <xref target="RFC5903" sectionFormat="of" section="7"/>, the shar ed secret result of an ECDH key exchange is the 384-bit x value of the ECDH comm on 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 <xref target="RFC2631" sectionFormat ="of" section="2.1.2"/>.
</t> </t>
<t>IKEv2, Section 2.12 <xref target="RFC7296" format="default"/> allows for the <t>IKEv2 allows for the reuse of Diffie-Hellman private keys; see <xref target="
reuse of Diffie-Hellman private keys. However, there are security concerns rela RFC7296" sectionFormat="of" section="2.12"/>. However, there are security conce
ted to this practice. Section 5.6.3.3 of <xref target="SP80056A" format="default rns related to this practice. Section&nbsp;5.6.3.3 of <xref target="SP80056A" fo
"/> states that an ephemeral private key MUST be used in exactly one key establi rmat="default"/> states that an ephemeral private key <bcp14>MUST</bcp14> be use
shment transaction and MUST be destroyed (zeroized) as soon as possible. Section d in exactly one key establishment transaction and <bcp14>MUST</bcp14> be destro
5.8 of <xref target="SP80056A" format="default"/> states that a Diffie-Hellman yed (zeroized) as soon as possible. Section&nbsp;5.8 of <xref target="SP80056A"
shared secret must be destroyed (zeroized) immediately after its use. CNSA compl format="default"/> states that any shared secret derived from key establishment
iant IPsec systems MUST follow the mandates in <xref target="SP80056A" format="d <bcp14>MUST</bcp14> be destroyed (zeroized) immediately after its use.
efault"/>. CNSA-compliant IPsec systems <bcp14>MUST</bcp14> follow the mandates in <xref t
arget="SP80056A" format="default"/>.
</t> </t>
</section> </section>
<!-- ikesa-keygen -->
<section anchor="addl-reqt" numbered="true" toc="default"> <section anchor="addl-reqt" numbered="true" toc="default">
<name>Additional Requirements</name> <name>Additional Requirements</name>
<t>The IPsec protocol AH MUST NOT be used in CNSA compliant implementation s. <t>The IPsec protocol AH <bcp14>MUST NOT</bcp14> be used in CNSA-compliant implementations.
</t> </t>
<t>A Diffie-Hellman group MAY be negotiated for a Child SA as described in <t>A Diffie-Hellman group <bcp14>MAY</bcp14> be negotiated for a Child SA
Section 1.3 of <xref target="RFC7296" format="default"/> allowing peers to empl as described in <xref target="RFC7296" sectionFormat="of" section="1.3"/>,
oy Diffie-Hellman in the CREATE_CHILD_SA exchange. If a transform of type 4 is s allowing peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange. If a tr
pecified for an SA for ESP, the value of that transform MUST match the value of ansform of type 4 is specified for an SA for ESP, the value of that transform <b
the transform used by the IKEv2 SA. cp14>MUST</bcp14> match the value of the transform used by the IKEv2 SA.
</t> </t>
<t>Per <xref target="RFC7296" format="default"/>, if a CREATE_CHILD_SA exc hange includes a KEi payload, at least one of the SA offers MUST include the Dif fie-Hellman group of the KEi. For CNSA compliant IPsec compliant implementations , the Diffie-Hellman group of the KEi MUST use the same group used in the IKE_IN IT_SA. <t>Per <xref target="RFC7296" format="default"/>, if a CREATE_CHILD_SA exc hange includes a KEi payload, at least one of the SA offers <bcp14>MUST</bcp14> include the Diffie-Hellman group of the KEi. For CNSA-compliant IPsec implementa tions, the Diffie-Hellman group of the KEi <bcp14>MUST</bcp14> use the same grou p used in the IKE_INIT_SA.
</t> </t>
<t>For IKEv2, rekeying of the CREATE_CHILD_SA MUST be supported by both pa rties. The initiator of this exchange MAY include a new Diffie-Hellman key; if i t is included, it MUST use the same group used in the IKE_INIT_SA. If the initia tor of the exchange includes a Diffie-Hellman key, the responder MUST include a Diffie-Hellman key, and it MUST use the same group. <t>For IKEv2, rekeying of the CREATE_CHILD_SA <bcp14>MUST</bcp14> be suppo rted by both parties. The initiator of this exchange <bcp14>MAY</bcp14> include a new Diffie-Hellman key; if it is included, it <bcp14>MUST</bcp14> use the same group used in the IKE_INIT_SA. If the initiator of the exchange includes a Diff ie-Hellman key, the responder <bcp14>MUST</bcp14> include a Diffie-Hellman key, and it <bcp14>MUST</bcp14> use the same group.
</t> </t>
<t>For CNSA compliant systems, the IKEv2 authentication method MUST use an end-entity certificate provided by the authenticating party. Identification Pay loads (Idi and IDr) in the IKE_AUTH exchanges MUST NOT be used for the IKEv2 aut hentication method , but may be used for policy lookup. <t>For CNSA-compliant systems, the IKEv2 authentication method <bcp14>MUST </bcp14> use an end-entity certificate provided by the authenticating party. Ide ntification Payloads (IDi and IDr) in the IKE_AUTH exchanges <bcp14>MUST NOT</bc p14> be used for the IKEv2 authentication method but may be used for policy look up.
</t> </t>
<t>The administrative user interface (UI) for a system that conforms to th is 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. <t>The administrative User Interface (UI) for a system that conforms to th is profile <bcp14>MUST</bcp14> allow the operator to specify a single suite. If only one suite is specified in the administrative UI, the IKEv2 implementation <bcp14>MUST</bcp14> only offer algorithms for that one suite.
</t> </t>
<t>The administrative UI MAY allow the operator to specify more than one s uite; 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 s pecified in the administrative UI, the IKEv2 implementation MUST only offer algo rithms of those suites. (Note that although this document does not define a UI s uite specifying PRF_HMAC_SHA2_384, a proposal containing such a transform is CNS A compliant.) <t>The administrative UI <bcp14>MAY</bcp14> allow the operator to specify more than one suite; if it allows this, it <bcp14>MUST</bcp14> allow the operato r 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 imple mentation <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> </t>
</section> </section>
<!-- addl-reqt -->
<section anchor="long-life" numbered="true" toc="default"> <section anchor="long-life" numbered="true" toc="default">
<name>Guidance for Applications With Long Data-Protection Requirements</na me> <name>Guidance for Applications with Long Data-Protection Requirements</na me>
<t>The CNSA mandate is to continue to use current algorithms with increased secu rity parameters, then transition to approved post-quantum resilient algorithms w hen they are identified. However, some applications have data-in-transit-protect ion requirements that are long enough that post-quantum resilient protection mus t be provided now. Lacking approved asymmetric post-quantum resilient confidenti ality algorithms, that means approved symmetric techniques must be used as descr ibed in this section until approved post-quantum resilient asymmetric algorithms are identified. <t>The CNSA mandate is to continue to use current algorithms with increased secu rity parameters, then transition to approved post-quantum resilient algorithms w hen they are identified. However, some applications have data-in-transit-protect ion requirements that are long enough that post-quantum resilient protection mus t be provided now. Lacking approved asymmetric post-quantum resilient confidenti ality algorithms, that means approved symmetric techniques must be used as descr ibed in this section until approved post-quantum resilient asymmetric algorithms are identified.
</t> </t>
<t>For new applications, confidentiality and integrity requirements from the sec <t>For new applications, confidentiality and integrity requirements from the sec
tions above MUST be followed, with the addition of a PSK mixed in as defined in tions above <bcp14>MUST</bcp14> be followed, with the addition of a Pre-Shared K
<xref target="RFC8784" format="default"/>. ey (PSK) mixed in as defined in <xref target="RFC8784" format="default"/>.
</t>
<t>Installations currently using IKEv1 with PSK MUST use AES in cipher block cha
ining mode (AES-CBC) in conjunction with a CNSA compliant integrity algorithm (e
.g. AUTH_HMAC_SHA2_384_192), and transition to IKEv2 with PSK <xref target="RFC8
784" format="default"/> as soon as implementations become available.
</t> </t>
<!-- Removed as redundant. <t>Installations currently using IKEv1 with PSKs <bcp14>MUST</bcp14> (1) use AES
<t>For all applications to which this section applies, PSK authentication MUST b in cipher block chaining mode (AES-CBC) in conjunction with a CNSA-compliant in
e performed using HMAC-SHA-384 <xref target="RFC4868" format="default"/>. tegrity algorithm (e.g., AUTH_HMAC_SHA2_384_192) and (2) transition to IKEv2 wit
h PSKs <xref target="RFC8784" format="default"/> as soon as implementations beco
me available.
</t> </t>
<t>Specific guidance for systems not compliant with the requirements of this doc <t>Specific guidance for systems not compliant with the requirements of this doc
ument, including non-GCM modes and PSK length and randomness, will be defined in ument, including non-GCM modes and PSK length, and PSK randomness, will be defin
solution specific requirements appropriate to the application. Details of those ed in
requirements will depend on the program under which the commercial NSS solution solution-specific requirements appropriate to the application.
is developed (e.g. Commercial Solutions for Classified Capability Package). Details of those requirements will depend on the program under which the commer
cial National Security Systems solution is developed (e.g., an NSA Commercial So
lutions for Classified Capability Package).
</t> </t>
</section> </section>
<!-- long-life -->
<section anchor="sec-considerations" numbered="true" toc="default"> <section anchor="sec-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document inherits all of the security considerations of the IPsec and IK Ev2 documents, including <xref target="RFC7296" format="default"/>, <xref target ="RFC4303" format="default"/>, <xref target="RFC4754" format="default"/>, and <x ref target="RFC8221" format="default"/>. <t>This document inherits all of the security considerations of the IPsec and IK Ev2 documents, including <xref target="RFC7296" format="default"/>, <xref target ="RFC4303" format="default"/>, <xref target="RFC4754" format="default"/>, and <x ref target="RFC8221" format="default"/>.
</t> </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 th ose 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>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 th ose 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>
<t>When selecting a mode for the AES encryption <xref target="RFC5116" format="d efault"/> , be aware that nonce reuse can result in a loss of confidentiality. N once reuse is catastrophic for GCM since it also results in a loss of integrity. <t>When selecting a mode for the AES encryption <xref target="RFC5116" format="d efault"/>, be aware that nonce reuse can result in a loss of confidentiality. No nce reuse is catastrophic for GCM, since it also results in a loss of integrity.
</t> </t>
</section> </section>
<!-- sec-considerations -->
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is asked to amend the registry titled "Cryptographic Suites for IK Ev1, IKEv2, and IPsec" 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 docu ment are listed, with this document as the RFC reference. <t>IANA has added the UI suites defined in this document to the "Cryptogra phic Suites for IKEv1, IKEv2, and IPsec" registry located at <eref target="https ://www.iana.org/assignments/crypto-suites" brackets="angle"/>:
</t> </t>
<table> <table>
<thead><tr><td align="center">Identifier</td><td align="center">Reference</td></ <thead><tr><th align="center">Identifier</th>
tr></thead> <th align="center">Reference</th></tr></thead>
<tbody> <tbody>
<tr><td>CNSA-GCM-256-ECDH-384</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>[this document when published]</td></tr> <tr><td>CNSA-GCM-256-DH-3072</td><td>RFC 9206</td></tr>
<tr><td>CNSA-GCM-256-DH-4096</td><td>[this document when published]</td></tr> <tr><td>CNSA-GCM-256-DH-4096</td><td>RFC 9206</td></tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- iana -->
</middle> </middle>
<back> <back>
<!-- *****BACK MATTER ***** -->
<references> <name>References</name> <references> <name>References</name>
<references> <name>Normative References</name> <references> <name>Normative References</name>
<reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Polic ies.htm"> <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/Issuances/Polic ies.htm">
<front> <front>
<title>Use of Public Standards for Secure Information Sharing</title > <title>Use of Public Standards for Secure Information Sharing</title >
<seriesInfo name="CNSSP" value="15"/>
<author> <author>
<organization>Committee for National Security Systems</organizatio n> <organization>Committee for National Security Systems</organizatio n>
</author> </author>
<date month="October" year="2016"/> <date month="October" year="2016"/>
</front> </front>
</reference> <!-- CNSA --> <refcontent>CNSSP 15</refcontent>
</reference>
<reference anchor="FIPS180" target="https://csrc.nist.gov/publications/det ail/fips/180/4/final"> <reference anchor="FIPS180" target="https://csrc.nist.gov/publications/det ail/fips/180/4/final">
<front> <front>
<title>Secure Hash Standard (SHS)</title> <title>Secure Hash Standard (SHS)</title>
<seriesInfo name="Federal Information Processing Standard" value="18 0-4"/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="August" year="2015"/> <date month="August" year="2015"/>
</front> </front>
</reference> <!-- FIPS180 --> <refcontent>Federal Information Processing Standard 180-4</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor="FIPS186" target="http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf"> <reference anchor="FIPS186" target="https://csrc.nist.gov/publications/det ail/fips/186/4/final">
<front> <front>
<title>Digital Signature Standard (DSS)</title> <title>Digital Signature Standard (DSS)</title>
<seriesInfo name="NIST Federal Information Processing Standard" valu e="186-4"/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="July" year="2013"/> <date month="July" year="2013"/>
</front> </front>
</reference> <!-- FIPS186 --> <refcontent>NIST Federal Information Processing Standard 186-4</refconte
nt>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
</reference>
<reference anchor="FIPS197" target="https://csrc.nist.gov/publications/det ail/fips/197/final"> <reference anchor="FIPS197" target="https://csrc.nist.gov/publications/det ail/fips/197/final">
<front> <front>
<title>Advanced Encryption Standard (AES)</title> <title>Advanced Encryption Standard (AES)</title>
<seriesInfo name="Federal Information Processing Standard" value="19 7"/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="November" year="2001"/> <date month="November" year="2001"/>
</front> </front>
</reference> <!-- FIPS197 --> <refcontent>Federal Information Processing Standard 197</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
</reference>
<reference anchor="SP80056A" target="https://nvlpubs.nist.gov/nistpubs/Spe cialPublications/NIST.SP.800-56Ar3.pdf"> <reference anchor="SP80056A" target="https://csrc.nist.gov/publications/de tail/sp/800-56a/rev-3/final">
<front> <front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title> <title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
<seriesInfo name="NIST Special Publication" value="800-56A, Revision 3"/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="April" year="2018"/> <date month="April" year="2018"/>
</front> </front>
</reference> <!-- SP80056A --> <refcontent>NIST Special Publication 800-56A, Revision 3</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2631.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.3526.xml"/> .2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4106.xml"/> .2631.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4303.xml"/> .3526.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4308.xml"/> .4106.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4754.xml"/> .4303.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.4868.xml"/> .4308.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.5116.xml"/> .4754.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.5280.xml"/> .5116.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.5903.xml"/> .5280.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.7296.xml"/> .5903.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8017.xml"/> .7296.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8174.xml"/> .8017.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8221.xml"/> .8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8247.xml"/> .8221.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8603.xml"/> .8247.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
ce.RFC.8784.xml"/> .8603.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8784.xml"/>
</references> <!-- Normative --> </references>
<references> <name>Informative References</name> <references> <name>Informative References</name>
<reference anchor="SP80059" target="https://csrc.nist.gov/publications/det ail/sp/800-59/final"> <reference anchor="SP80059" target="https://csrc.nist.gov/publications/det ail/sp/800-59/final">
<front> <front>
<title>Guideline for Identifying an Information System as a National Security System</title> <title>Guideline for Identifying an Information System as a National Security System</title>
<seriesInfo name="Special Publication 800-59" value=""/>
<author> <author>
<organization>National Institute of Standards and Technology</orga nization> <organization>National Institute of Standards and Technology</orga nization>
</author> </author>
<date month="August" year="2003"/> <date month="August" year="2003"/>
</front> </front>
</reference> <!-- SP80059 --> <refcontent>Special Publication 800-59</refcontent>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen </reference>
ce.RFC.8452.xml"/>
</references> <!-- Informative --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC .8452.xml"/>
</references> <!-- References --> </references>
</references>
</back> </back>
<!-- ===== END BACK MATTER ===== -->
</rfc> </rfc>
 End of changes. 110 change blocks. 
296 lines changed or deleted 285 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/