rfc9395xml2.original.xml   rfc9395.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.2407.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC2408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.2408.xml">
<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2409.xml">
<!ENTITY RFC4303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4303.xml">
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4306.xml">
<!ENTITY RFC6407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6407.xml">
<!ENTITY RFC7296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7296.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8221 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8221.xml">
<!ENTITY RFC8247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8247.xml">
<!ENTITY RFC8784 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8784.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc ipr="trust200902"
updates="8221,8247"
obsoletes=""
category="std"
docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" updates="8221,
<title abbrev="Deprecation of IKEv1 and some algorithms">Deprecation of IKEv 8247" obsoletes="" docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09" number
1 and obsoleted algorithms</title> ="9395"
submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="
true"
tocDepth="4" symRefs="true" sortRefs="true" version="3">
<author initials='P.' surname="Wouters" fullname='Paul Wouters' role="editor"> <front>
<organization>Aiven</organization> <title abbrev="IKEv1 Deprecation">Deprecation of the Internet Key Exchange V
<address> ersion 1 (IKEv1) Protocol and Obsoleted Algorithms</title>
<email>paul.wouters@aiven.io</email> <seriesInfo name="RFC" value="9395"/>
</address> <author initials="P." surname="Wouters" fullname="Paul Wouters" role="editor
">
<organization>Aiven</organization>
<address>
<email>paul.wouters@aiven.io</email>
</address>
</author> </author>
<date/> <date year="2023" month="April"/>
<area>General</area> <area>sec</area>
<workgroup>Network</workgroup> <workgroup>ipsecme</workgroup>
<keyword>IKEv1</keyword> <keyword>IKEv1</keyword>
<keyword>IKEv2</keyword> <keyword>IKEv2</keyword>
<keyword>IPsec</keyword> <keyword>IPsec</keyword>
<keyword>IKE</keyword> <keyword>IKE</keyword>
<abstract> <abstract>
<t> <t>
Internet Key Exchange version 1 (IKEv1) has been deprecated and its Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs
specification in RFC2407, RFC2408 and RFC2409 have been moved to 2407, 2408, and 2409 have been moved to Historic status. This document
Historic status. This document updates RFC 8221 and RFC 8247 to reflect updates RFCs 8221 and 8247 to reflect the usage guidelines of old
the usage guidelines of old algorithms that are associated with algorithms that are associated with IKEv1 and are not specified or
IKEv1, and are not specified or commonly implemented for IKEv2. This commonly implemented for IKEv2. This document further updates the IANA reg
document further updates the IANA IKEv2 Transform Type registries istries
to add a Status column where deprecation status can be listed. for IKEv2 "Transform Type Values" by adding a "Status" column where the de
precation
status can be listed.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
IKEv1 has been moved to Historic status. IKEv1 has been moved to Historic status. IKEv1 <xref target="RFC2409"
IKEv1 <xref target="RFC2409"/> and its related documents for ISAKMP format="default"/> and its related documents for the Internet Security
<xref target="RFC2408"/> and IPsec DOI <xref target="RFC2407"/> Association and Key Management Protocol (ISAKMP) <xref target="RFC2408"
were obsoleted by IKEv2 <xref target="RFC4306"/> in December format="default"/> and IPsec DOI <xref target="RFC2407"
2005. The latest version of IKEv2 at the time of writing was format="default"/> were obsoleted by IKEv2 <xref target="RFC4306"
published in 2014 in <xref target="RFC7296"/>. The Internet Key format="default"/> in December 2005. The latest version of IKEv2 at the
Exchange (IKE) version 2 has replaced version 1 over 15 years ago. time of writing was published in 2014 <xref target="RFC7296"
IKEv2 has now seen wide deployment and provides a full replacement format="default"/>. Since IKEv2 replaced IKEv1 over 15 years ago, IKEv2
for all IKEv1 functionality. No new modifications or new algorithms have has now seen wide deployment, and it provides a full replacement for all
been accepted for IKEv1 for at least a decade. IKEv2 addresses IKEv1 functionality. No new modifications or new algorithms have been
various issues present in IKEv1, such as IKEv1 being vulnerable accepted for IKEv1 for at least a decade. IKEv2 addresses various issues
to amplification attacks. present in IKEv1, such as IKEv1 being vulnerable to amplification
attacks.
</t> </t>
<t> <t>
Algorithm implementation requirements and usage guidelines Algorithm implementation requirements and usage guidelines
for IKEv2 <xref target="RFC8247"/> and ESP/AH <xref target="RFC8221"/> for IKEv2 <xref target="RFC8247" format="default"/> and Encapsulating Sec urity Payload (ESP) and Authentication Header (AH) <xref target="RFC8221" format ="default"/>
gives guidance to implementors but limits that guidance to avoid gives guidance to implementors but limits that guidance to avoid
broken or weak algorithms. These two RFCs do not deprecate algorithms tha t broken or weak algorithms. These two RFCs do not deprecate algorithms tha t
have aged and are not in use, but leave these algorithms in have aged and are not in use. Instead, they leave these algorithms in
a state of "MAY be used" by not mentioning them. This document deprecates a state of "<bcp14>MAY</bcp14> be used" by not mentioning them. This docu
ment deprecates
those unmentioned algorithms that are no longer advised but for which those unmentioned algorithms that are no longer advised but for which
there are no known attacks resulting in their earlier deprecation. there are no known attacks resulting in their earlier deprecation.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="ikev1_historic" numbered="true" toc="default">
<name>RFCs 2407, 2408, and 2409 Are Historic</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", As IKEv1 is deprecated, systems running IKEv1 should be upgraded and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.
</t>
</section>
<section title="RFC2407, RFC2408 and RFC2409 are Historic" anchor="ikev1_hist
oric">
<t>
IKEv1 is deprecated. Systems running IKEv1 should be upgraded and
reconfigured to run IKEv2. Systems that support IKEv1 but not reconfigured to run IKEv2. Systems that support IKEv1 but not
IKEv2 are most likely also unsuitable candidates for continued IKEv2 are most likely also unsuitable candidates for continued
operation: operation for the following reasons:
<list style="symbols"> </t>
<t> <ul spacing="normal">
IKEv1 development ceased over a decade ago and no new work will <li>
IKEv1 development ceased over a decade ago, and no new work will
happen. This poses the risk of unmaintained code in an otherwise happen. This poses the risk of unmaintained code in an otherwise
supported product which can result in security vulnerabilities. supported product, which can result in security vulnerabilities.
</t> </li>
<t> <li>
A number of IKEv1 systems have reached their End of Life and A number of IKEv1 systems have reached their End of Life and,
therefor will never be patched by the vendor if a vulnerability therefore, will never be patched by the vendor if a vulnerability
is found. is found.
</t> </li>
<t> <li>
There are vendors that still provide updates for their equipment There are vendors that still provide updates for their equipment
that supports IKEv1 and IKEv2, but have "frozen" their IKEv1 that supports IKEv1 and IKEv2 but have "frozen" their IKEv1
implementation. Such users might not be aware that they are implementation. Such users might not be aware that they are
running unmaintained code with its associated security risks. running unmaintained code with its associated security risks.
</t> </li>
<t> <li>
IKEv1 systems can be abused for packet amplification attacks, as IKEv1 systems can be abused for packet amplification attacks, as
documented in the Security Bulletin <xref target="CVE-2016-5361"/>. documented in the Security Bulletin <xref target="CVE-2016-5361" format="de
</t> fault"/>.
<t> </li>
<li>
Great strides have been made in cryptography since IKEv1 development Great strides have been made in cryptography since IKEv1 development
ceased. While some modern cryptographic algorithms were added to ceased. While some modern cryptographic algorithms were added to
IKEv1, interoperability concerns mean that the defacto algorithms IKEv1, interoperability concerns mean that the defacto algorithms
negotiated by IKEv1 will consist of dated or deprecated algorithms negotiated by IKEv1 will consist of dated or deprecated algorithms,
like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 provides like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 provides
state-of-the-art suite of cryptographic algorithms that IKEv1 lacks. a state-of-the-art suite of cryptographic algorithms that IKEv1 lacks.
</t> </li>
</ul>
</list> <t>
IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more
modern cryptographic primitives, proper defense against denial of service modern cryptographic primitives, proper defense against denial-of-service
attacks, improved authentication via EAP methods, PAKE support and is attacks, improved authentication via Extensible Authentication Protocol (EA
actively worked on with respect to defending against quantum computer attac P) methods, and password-authenticated key exchange (PAKE) support. Also, IKEv2
ks. is
</t> actively worked on with respect to defending against quantum-computer attac
<t> ks.
</t>
<t>
IKEv1-only systems should be upgraded or replaced by systems supporting IKEv1-only systems should be upgraded or replaced by systems supporting
IKEv2. IKEv2 implementations SHOULD NOT directly import IKEv1 configuration s IKEv2. IKEv2 implementations <bcp14>SHOULD NOT</bcp14> directly import IKEv 1 configurations
without updating the cryptographic algorithms used. without updating the cryptographic algorithms used.
</t> </t>
</section> </section>
<section anchor="feature_eq" numbered="true" toc="default">
<section title="IKEv1 feature equivalents for IKEv2" anchor="feature_eq"> <name>IKEv1 Feature Equivalents for IKEv2</name>
<t> <t>
A few notable IKEv1 features are not present in the IKEv2 core specificati on A few notable IKEv1 features are not present in the IKEv2 core specificati on
<xref target="RFC7296"/> but are available for IKEv2 via an additional spe <xref target="RFC7296" format="default"/> but are available for IKEv2 via
cification: an additional specification.
</t> </t>
<section anchor="ikev2_postq" numbered="true" toc="default">
<section title="IKEv2 postquantum support" anchor="ikev2_postq"> <name>IKEv2 Post-Quantum Support</name>
<t> <t>
IKEv1 and its way of using Preshared Keys (PSKs) protects against IKEv1 and its way of using Preshared Keys (PSKs) protects against
quantum computer based attacks. IKEv2 updated its use of PSK to improve quantum-computer-based attacks. IKEv2 updated its use of PSKs to improve
the error reporting, but at the expense of post-quantum security. If the error reporting but at the expense of post-quantum security. If
post-quantum security is required, these systems should be migrated post-quantum security is required, these systems should be migrated
to use IKEv2 Postquantum Preshared Keys (PPK) <xref target="RFC8784"/> to use IKEv2 Post-quantum Preshared Keys (PPKs) <xref target="RFC8784" fo
</t> rmat="default"/>.
</section> </t>
</section>
<section title="IKEv2 Labeled IPsec support" anchor="ikev2_labeled"> <section anchor="ikev2_labeled" numbered="true" toc="default">
<t> <name>IKEv2 Labeled IPsec Support</name>
<t>
Some IKEv1 implementations support Labeled IPsec, a method Some IKEv1 implementations support Labeled IPsec, a method
to negotiate an additional Security Context selector to the to negotiate an additional Security Context selector to the
SPD, but this method was never standardized in IKEv1. Those IKEv1 Security Policy Database (SPD), but this method was never standardized in IKEv1. Those IKEv1
systems that require Labeled IPsec should migrate to an systems that require Labeled IPsec should migrate to an
IKEv2 system supporting Labeled IPsec as specified in IKEv2 system supporting Labeled IPsec as specified in
<xref target="draft-ietf-ipsecme-labeled-ipsec"/>. <xref target="I-D.ietf-ipsecme-labeled-ipsec" format="default"/>.
</t> </t>
</section> </section>
<section anchor="ikev2_groupsa" numbered="true" toc="default">
<section title="IKEv2 Group SA / Multicast support" anchor="ikev2_groupsa"> <name>IKEv2 Group SA and Multicast Support</name>
<t> <t>
The Group Domain of Interpretation (GDOI, <xref target="RFC6407"/>) proto The Group Domain of Interpretation (GDOI) protocol <xref target="RFC6407"
col, format="default"/>,
based on IKEv1 defines the support for Multicast Group SAs. For IKEv2, th which is based on IKEv1, defines the support for Multicast Group SAs. For
is IKEv2, this
work is currently in progress via <xref target="draft-ietf-ipsecme-g-ikev work is currently in progress via <xref target="I-D.ietf-ipsecme-g-ikev2"
2"/> format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="deprecating_algos" numbered="true" toc="default">
<section title="Deprecating obsolete algorithms" anchor="deprecating_algos"> <name>Deprecating Obsolete Algorithms</name>
<t>This document deprecates the following algorithms: <t>This document deprecates the following algorithms:
<list style="symbols"> </t>
<t> Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecified <ul spacing="normal">
3IDEA, <li> Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecifi
ENCR_DES_IV64 and ENCR_DES_IV32</t> ed 3IDEA,
<t> PRF Algorithms: the unspecified PRF_HMAC_TIGER</t> ENCR_DES_IV64, and ENCR_DES_IV32</li>
<t> Integrity Algorithms: HMAC-MD5-128</t> <li> PRF Algorithms: the unspecified PRF_HMAC_TIGER</li>
<t> Diffie-Hellman groups: none</t> <li> Integrity Algorithms: HMAC-MD5-128</li>
</list> <li> Diffie-Hellman groups: none</li>
</t> </ul>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<t>There are only security benefits by deprecating IKEv1 for IKEv2. <name>Security Considerations</name>
</t> <t>There are only security benefits if IKEv1 is deprecated and IKEv2 is us
<t> ed.
</t>
<t>
The deprecated algorithms have long been in disuse and are no longer The deprecated algorithms have long been in disuse and are no longer
actively deployed or researched. It presents an unknown security actively deployed or researched; this presents an unknown security
risk that is best avoided. Additionally, these algorithms not being risk that is best avoided. Additionally, these algorithms not being
supported in implementations simplifies those implementations and supported in implementations simplifies those implementations and
reduces the accidental use of these deprecated algorithms through reduces the accidental use of deprecated algorithms through
misconfiguration or downgrade attacks. misconfiguration or downgrade attacks.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document instructs IANA to insert the following line at the top <t>IANA has added the following line at the top
of the Notes of the Notes section of the "Internet Key Exchange (IKE) Attributes"
section of the 'Internet Key Exchange (IKE) Attributes' registry and the and '"Magic Numbers" for ISAKMP Protocol' registries: "All
'"Magic Numbers" for ISAKMP Protocol' registry: All registries listed be registries listed below have been closed. See RFC 9395." In addition, this
low have document has been added to the "Reference" column in these two registries, and
been closed, see RFCxxxx. their registration procedures have been changed to "Registry closed".
[Note to RFC Editor: change RFCxxx to this document's RFC number] </t>
</t> <t>IANA has added a "Status" column to the following IKEv2 "Transform Type
Values" registries:
<t>This document further instructs IANA to add an additional Status colu </t>
mn to <ul empty="true" spacing="compact">
the IKEv2 Transform Type registries and mark the following entries as DE <li>Transform Type 1 - Encryption Algorithm Transform IDs</li>
PRECATED: <li>Transform Type 2 - Pseudorandom Function Transform IDs</li>
<figure align="center" anchor="iana_requests_type1"> <li>Transform Type 3 - Integrity Algorithm Transform IDs</li>
<artwork align="left"><![CDATA[ <li>Transform Type 4 - Key Exchange Method Transform IDs</li>
</ul>
Transform Type 1 - Encryption Algorithm IDs <t>
Also, the following entries have been marked as DEPRECATED:
Number Name Status </t>
------ --------------- ------
1 ENCR_DES_IV64 DEPRECATED [this document]
2 ENCR_DES DEPRECATED [RFC8247]
4 ENCR_RC5 DEPRECATED [this document]
5 ENCR_IDEA DEPRECATED [this document]
6 ENCR_CAST DEPRECATED [this document]
7 ENCR_BLOWFISH DEPRECATED [this document]
8 ENCR_3IDEA DEPRECATED [this document]
9 ENCR_DES_IV32 DEPRECATED [this document]
]]></artwork>
</figure>
<figure align="center" anchor="iana_requests_type2">
<artwork align="left"><![CDATA[
Transform Type 2 - Pseudorandom Function Transform IDs
Number Name Status
------ ------------ ----------
1 PRF_HMAC_MD5 DEPRECATED [RFC8247]
3 PRF_HMAC_TIGER DEPRECATED [this document]
]]></artwork>
</figure>
<figure align="center" anchor="iana_requests_typ3">
<artwork align="left"><![CDATA[
Transform Type 3 - Integrity Algorithm Transform IDs <table anchor="iana_requests_type1" align="center">
<name>Transform Type 1 - Encryption Algorithm Transform IDs</name>
<thead>
<tr>
<th>Number</th>
<th>Name</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>ENCR_DES_IV64</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>2</td>
<td>ENCR_DES</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>4</td>
<td>ENCR_RC5</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>5</td>
<td>ENCR_IDEA</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>6</td>
<td>ENCR_CAST</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>7</td>
<td>ENCR_BLOWFISH</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>8</td>
<td>ENCR_3IDEA</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>9</td>
<td>ENCR_DES_IV32</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
</tbody>
</table>
Number Name Status <table anchor="iana_requests_type2" align="center">
------ ----------------- ---------- <name>Transform Type 2 - Pseudorandom Function Transform IDs</name>
1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247] <thead>
3 AUTH_DES_MAC DEPRECATED [RFC8247] <tr>
4 AUTH_KPDK_MD5 DEPRECATED [RFC8247] <th>Number</th>
6 AUTH_HMAC_MD5_128 DEPRECATED [this document] <th>Name</th>
7 AUTH_HMAC_SHA1_160 DEPRECATED [this document] <th>Status</th>
]]></artwork> </tr>
</figure> </thead>
<figure align="center" anchor="iana_requests_type4"> <tbody>
<artwork align="left"><![CDATA[ <tr>
<td>1</td>
<td>PRF_HMAC_MD5</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>3</td>
<td>PRF_HMAC_TIGER</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
</tbody>
</table>
Transform Type 4 - Diffie Hellman Group Transform IDs <table anchor="iana_requests_typ3" align="center">
<name>Transform Type 3 - Integrity Algorithm Transform IDs</name>
<thead>
<tr>
<th>Number</th>
<th>Name</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>AUTH_HMAC_MD5_96</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>3</td>
<td>AUTH_DES_MAC</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>4</td>
<td>AUTH_KPDK_MD5</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>6</td>
<td>AUTH_HMAC_MD5_128</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
<tr>
<td>7</td>
<td>AUTH_HMAC_SHA1_160</td>
<td>DEPRECATED (RFC 9395)</td>
</tr>
</tbody>
</table>
Number Name Status <table anchor="iana_requests_type4" align="center">
------ ---------------------------- ---------- <name>Transform Type 4 - Key Exchange Method Transform IDs</name>
1 768-bit MODP Group DEPRECATED [RFC8247] <thead>
22 1024-bit MODP Group with <tr>
160-bit Prime Order Subgroup DEPRECATED [RFC8247] <th>Number</th>
]]></artwork> <th>Name</th>
</figure> <th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>768-bit MODP Group</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
<tr>
<td>22</td>
<td>1024-bit MODP Group with 160-bit Prime Order Subgroup</td>
<td>DEPRECATED <xref target="RFC8247" format="default"/></td>
</tr>
</tbody>
</table>
<t>
All entries not mentioned here should receive no value in the new Status field. All entries not mentioned here should receive no value in the new Status field.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-ipsecme-labeled-ipsec" to="LABELED-IPSEC"/>
&RFC2119; <displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/>
&RFC8174;
&RFC8247; <references>
</references> <name>References</name>
<references title="Informative References"> <references>
&RFC2407; <name>Normative References</name>
&RFC2408; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC2409; 119.xml"/>
&RFC6407; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC4306; 174.xml"/>
&RFC7296; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
&RFC8221; 247.xml"/>
&RFC8784; </references>
<reference anchor='draft-ietf-ipsecme-labeled-ipsec'> <references>
<front> <name>Informative References</name>
<title>Labeled IPsec Traffic Selector support for IKEv2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author initials='P.' surname="Wouters" fullname='Paul Wouters'> 407.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="Sahana Prasad" initials="S." surname="Prasad"> 408.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<date month='October' day='25' year='2021' /> 409.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t> 407.xml"/>
This document defines a new Traffic Selector (TS) Type for <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
Internet Key Exchange version 2 to add support for negotiating 306.xml"/>
Mandatory Access Control (MAC) security labels as a traffic selector <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
of the Security Policy Database (SPD). Security Labels for IPsec 296.xml"/>
are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
which consists of a variable length opaque field specifying the 221.xml"/>
security label. This document updates the IKEv2 TS negotiation <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
specified in RFC 7296 Section 2.9. 784.xml"/>
</t>
</abstract> <!-- [I-D.ietf-ipsecme-labeled-ipsec] IESG state Publication Requested as of 4/2
</front> 1/23 -->
<seriesInfo name='Internet-Draft' value='draft-ietf-ipsecme-labeled-ipsec' <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
/> .ietf-ipsecme-labeled-ipsec.xml"/>
<format type='TXT'
target='https://tools.ietf.org/id/draft-ietf-ipsecme-labeled-ipsec-0
6.txt' />
</reference>
<reference anchor='draft-ietf-ipsecme-g-ikev2'>
<front>
<title>Group Key Management using IKEv2</title>
<author initials='V.' surname="Smyslov" fullname='Valery Smyslov'>
<organization>ELVIS-PLUS</organization>
</author>
<author fullname="Brian Weis" initials="B." surname="Weis">
<organization>Independent</organization>
</author>
<date month='January' day='11' year='2021' />
<abstract>
<t>
This document presents an extension to the Internet Key Exchange
version 2 (IKEv2) protocol for the purpose of a group key management.
The protocol is in conformance with the Multicast Security (MSEC) key
management architecture, which contains two components: member
registration and group rekeying. Both components require a Group
Controller/Key Server to download IPsec group security associations
to authorized members of a group. The group members then exchange IP
multicast or other group traffic as IPsec packets. This document
obsoletes RFC 6407.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-ipsecme-g-ikev2' />
<format type='TXT'
target='https://www.ietf.org/archive/id/draft-ietf-ipsecme-g-ikev2-0
3.txt' />
</reference>
<reference anchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/detail/CV
E-2016-5361">
<front>
<title>National Vulnerability Database - CVE-2016-5361</title>
<author>
<organization>National Institute of Science and Technology (NIST)</o
rganization>
</author>
<date day="16" month="June" year="2016"/>
</front>
</reference>
<!-- [I-D.ietf-ipsecme-g-ikev2] IESG state I-D Exists as of 4/21/23 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.draft-ietf-ipsecme-g-ikev2.xml"/>
<reference anchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/deta
il/CVE-2016-5361">
<front>
<title>CVE-2016-5361 Detail</title>
<author>
<organization>NIST National Vulnerability Database</organization>
</author>
<date day="16" month="June" year="2016"/>
</front>
</reference>
</references>
</references> </references>
</back> </back>
</rfc> </rfc>
 End of changes. 42 change blocks. 
321 lines changed or deleted 369 lines changed or added

This html diff was produced by rfcdiff 1.48.