rfc9395xml2.original.xml		rfc9395.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
			nsus="true" docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09" indexInclude=
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		"true" ipr="trust200902" number="9395" prepTime="2023-04-24T15:26:03" scripts="C
	.2119.xml">		ommon,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" t
	<!ENTITY RFC2407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		ocInclude="true" updates="8221,8247" xml:lang="en">
	.2407.xml">		<link href="https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-
	<!ENTITY RFC2408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		historic-09" rel="prev"/>
	.2408.xml">		<link href="https://dx.doi.org/10.17487/rfc9395" rel="alternate"/>
	<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC		<link href="urn:issn:2070-1721" rel="alternate"/>
	.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>		<front>
	<title abbrev="Deprecation of IKEv1 and some algorithms">Deprecation of IKEv		<title abbrev="IKEv1 Deprecation">Deprecation of the Internet Key Exchange V
	1 and obsoleted algorithms</title>		ersion 1 (IKEv1) Protocol and Obsoleted Algorithms</title>
			<seriesInfo name="RFC" value="9395" stream="IETF"/>
	<author initials='P.' surname="Wouters" fullname='Paul Wouters' role="editor">		<author initials="P." surname="Wouters" fullname="Paul Wouters" role="editor
	<organization>Aiven</organization>		">
	<address>		<organization showOnFrontPage="true">Aiven</organization>
	<email>paul.wouters@aiven.io</email>		<address>
	</address>		<email>paul.wouters@aiven.io</email>
			</address>
	</author>		</author>
	<date/>		<date month="04" year="2023"/>
	<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 pn="section-abstract">
	<abstract>		<t indent="0" pn="section-abstract-1">
	<t>		Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs
	Internet Key Exchange version 1 (IKEv1) has been deprecated and its		2407, 2408, and 2409 have been moved to Historic status. This document
	specification in RFC2407, RFC2408 and RFC2409 have been moved to		updates RFCs 8221 and 8247 to reflect the usage guidelines of old
	Historic status. This document updates RFC 8221 and RFC 8247 to reflect		algorithms that are associated with IKEv1 and are not specified or
	the usage guidelines of old algorithms that are associated with		commonly implemented for IKEv2. This document further updates the IANA reg
	IKEv1, and are not specified or commonly implemented for IKEv2. This		istries
	document further updates the IANA IKEv2 Transform Type registries		for IKEv2 "Transform Type Values" by adding a "Status" column where the de
	to add a Status column where deprecation status can be listed.		precation
			status can be listed.
	</t>		</t>
	</abstract>		</abstract>
			<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
			"exclude" pn="section-boilerplate.1">
			<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
			>
			<t indent="0" pn="section-boilerplate.1-1">
			This is an Internet Standards Track document.
			</t>
			<t indent="0" pn="section-boilerplate.1-2">
			This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by
			the Internet Engineering Steering Group (IESG). Further
			information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc9395" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2023 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document. Code Components extracted from this
			document must include Revised BSD License text as described in
			Section 4.e of the Trust Legal Provisions and are provided without
			warranty as described in the Revised BSD License.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
			ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-requirements-l
			anguage">Requirements Language</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
			ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-rfcs-2407-2408
			-and-2409-are">RFCs 2407, 2408, and 2409 Are Historic</xref></t>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-ikev1-feature-equivalents-f">IKEv1
			Feature Equivalents for IKEv2</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.4.2">
			<li pn="section-toc.1-1.4.2.1">
			<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
			"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-ikev2-post-quantum-sup
			port">IKEv2 Post-Quantum Support</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.2">
			<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
			"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-ikev2-labeled-ipsec-su
			pport">IKEv2 Labeled IPsec Support</xref></t>
			</li>
			<li pn="section-toc.1-1.4.2.3">
			<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
			"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-ikev2-group-sa-and-mul
			ticas">IKEv2 Group SA and Multicast Support</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-deprecating-obsolete-algori">Depre
			cating Obsolete Algorithms</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
			at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.8.2">
			<li pn="section-toc.1-1.8.2.1">
			<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
			"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.8.2.2">
			<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
			"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
			t="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent=""
			format="title" sectionFormat="of" target="name-authors-address">Author's Addres
			s</xref></t>
			</li>
			</ul>
			</section>
			</toc>
	</front>		</front>
	<middle>		<middle>
	<section title="Introduction">		<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
	<t>		<name slugifiedName="name-introduction">Introduction</name>
	IKEv1 has been moved to Historic status.		<t indent="0" pn="section-1-1">
	IKEv1 <xref target="RFC2409"/> and its related documents for ISAKMP		IKEv1 has been moved to Historic status. IKEv1 <xref target="RFC2409" form
	<xref target="RFC2408"/> and IPsec DOI <xref target="RFC2407"/>		at="default" sectionFormat="of" derivedContent="RFC2409"/> and its related docum
	were obsoleted by IKEv2 <xref target="RFC4306"/> in December		ents for the Internet Security
	2005. The latest version of IKEv2 at the time of writing was		Association and Key Management Protocol (ISAKMP) <xref target="RFC2408" fo
	published in 2014 in <xref target="RFC7296"/>. The Internet Key		rmat="default" sectionFormat="of" derivedContent="RFC2408"/> and IPsec DOI <xref
	Exchange (IKE) version 2 has replaced version 1 over 15 years ago.		target="RFC2407" format="default" sectionFormat="of" derivedContent="RFC2407"/>
	IKEv2 has now seen wide deployment and provides a full replacement		were obsoleted by IKEv2 <xref target="RFC4306" format="default" sectionFormat="
	for all IKEv1 functionality. No new modifications or new algorithms have		of" derivedContent="RFC4306"/> in December 2005. The latest version of IKEv2 at
	been accepted for IKEv1 for at least a decade. IKEv2 addresses		the
	various issues present in IKEv1, such as IKEv1 being vulnerable		time of writing was published in 2014 <xref target="RFC7296" format="defau
	to amplification attacks.		lt" sectionFormat="of" derivedContent="RFC7296"/>. Since IKEv2 replaced IKEv1 o
			ver 15 years ago, IKEv2
			has now seen wide deployment, and it provides a full replacement for all
			IKEv1 functionality. No new modifications or new algorithms have been
			accepted for IKEv1 for at least a decade. IKEv2 addresses various issues
			present in IKEv1, such as IKEv1 being vulnerable to amplification
			attacks.
	</t>		</t>
	<t>		<t indent="0" pn="section-1-2">
	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" sectionFormat="of" deri vedContent="RFC8247"/> and Encapsulating Security Payload (ESP) and Authenticati on Header (AH) <xref target="RFC8221" format="default" sectionFormat="of" derive dContent="RFC8221"/>
	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="include" removeInRFC="false" pn="section-2">
	<section title="Requirements Language">		<name slugifiedName="name-requirements-language">Requirements Language</na
	<t>		me>
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t indent="0" pn="section-2-1">
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	and "OPTIONAL" in this document are to be interpreted as described in		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
	BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only		D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
	when, they appear in all capitals, as shown here.		OT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
			f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
			mat="of" derivedContent="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
	</t>		</t>
	</section>		</section>
			<section anchor="ikev1_historic" numbered="true" toc="include" removeInRFC="
	<section title="RFC2407, RFC2408 and RFC2409 are Historic" anchor="ikev1_hist		false" pn="section-3">
	oric">		<name slugifiedName="name-rfcs-2407-2408-and-2409-are">RFCs 2407, 2408, an
	<t>		d 2409 Are Historic</name>
	IKEv1 is deprecated. Systems running IKEv1 should be upgraded and		<t indent="0" pn="section-3-1">
			As 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" bare="false" empty="false" indent="3" pn="section-3-2
	IKEv1 development ceased over a decade ago and no new work will		">
			<li pn="section-3-2.1">
			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 pn="section-3-2.2">
	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 pn="section-3-2.3">
	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 pn="section-3-2.4">
	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" sectionFormat="of" derivedContent="CVE-2016-5361"/>.
	<t>		</li>
			<li pn="section-3-2.5">
	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 indent="0" pn="section-3-3">
	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 indent="0" pn="section-3-4">
	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="include" removeInRFC="fals
	<section title="IKEv1 feature equivalents for IKEv2" anchor="feature_eq">		e" pn="section-4">
	<t>		<name slugifiedName="name-ikev1-feature-equivalents-f">IKEv1 Feature Equiv
			alents for IKEv2</name>
			<t indent="0" pn="section-4-1">
	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" sectionFormat="of" derivedContent=
	cification:		"RFC7296"/> but are available for IKEv2 via an additional specification.
	</t>		</t>
			<section anchor="ikev2_postq" numbered="true" toc="include" removeInRFC="f
	<section title="IKEv2 postquantum support" anchor="ikev2_postq">		alse" pn="section-4.1">
	<t>		<name slugifiedName="name-ikev2-post-quantum-support">IKEv2 Post-Quantum
			Support</name>
			<t indent="0" pn="section-4.1-1">
	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" sectionFormat="of" derivedContent="RFC8784"/>.
	</section>		</t>
			</section>
	<section title="IKEv2 Labeled IPsec support" anchor="ikev2_labeled">		<section anchor="ikev2_labeled" numbered="true" toc="include" removeInRFC=
	<t>		"false" pn="section-4.2">
			<name slugifiedName="name-ikev2-labeled-ipsec-support">IKEv2 Labeled IPs
			ec Support</name>
			<t indent="0" pn="section-4.2-1">
	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" sectionFor
	</t>		mat="of" derivedContent="LABELED-IPSEC"/>.
	</section>		</t>
			</section>
	<section title="IKEv2 Group SA / Multicast support" anchor="ikev2_groupsa">		<section anchor="ikev2_groupsa" numbered="true" toc="include" removeInRFC=
	<t>		"false" pn="section-4.3">
	The Group Domain of Interpretation (GDOI, <xref target="RFC6407"/>) proto		<name slugifiedName="name-ikev2-group-sa-and-multicas">IKEv2 Group SA an
	col,		d Multicast Support</name>
	based on IKEv1 defines the support for Multicast Group SAs. For IKEv2, th		<t indent="0" pn="section-4.3-1">
	is		The Group Domain of Interpretation (GDOI) protocol <xref target="RFC6407"
	work is currently in progress via <xref target="draft-ietf-ipsecme-g-ikev		format="default" sectionFormat="of" derivedContent="RFC6407"/>,
	2"/>		which is based on IKEv1, defines the support for Multicast Group SAs. For
	</t>		IKEv2, this
	</section>		work is currently in progress via <xref target="I-D.ietf-ipsecme-g-ikev2"
	</section>		format="default" sectionFormat="of" derivedContent="G-IKEV2"/>.
			</t>
	<section title="Deprecating obsolete algorithms" anchor="deprecating_algos">		</section>
	<t>This document deprecates the following algorithms:		</section>
	<list style="symbols">		<section anchor="deprecating_algos" numbered="true" toc="include" removeInRF
	<t> Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecified		C="false" pn="section-5">
	3IDEA,		<name slugifiedName="name-deprecating-obsolete-algori">Deprecating Obsolet
	ENCR_DES_IV64 and ENCR_DES_IV32</t>		e Algorithms</name>
	<t> PRF Algorithms: the unspecified PRF_HMAC_TIGER</t>		<t indent="0" pn="section-5-1">This document deprecates the following algo
	<t> Integrity Algorithms: HMAC-MD5-128</t>		rithms:
	<t> Diffie-Hellman groups: none</t>		</t>
	</list>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2
	</t>		">
	</section>		<li pn="section-5-2.1"> Encryption Algorithms: RC5, IDEA, CAST, Blowfish
	<section anchor="Security" title="Security Considerations">		, and the unspecified 3IDEA,
	<t>There are only security benefits by deprecating IKEv1 for IKEv2.		ENCR_DES_IV64, and ENCR_DES_IV32</li>
	</t>		<li pn="section-5-2.2"> PRF Algorithms: the unspecified PRF_HMAC_TIGER</
	<t>		li>
			<li pn="section-5-2.3"> Integrity Algorithms: HMAC-MD5-128</li>
			<li pn="section-5-2.4"> Diffie-Hellman groups: none</li>
			</ul>
			</section>
			<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
			pn="section-6">
			<name slugifiedName="name-security-considerations">Security Considerations
			</name>
			<t indent="0" pn="section-6-1">There are only security benefits if IKEv1 i
			s deprecated and IKEv2 is used.
			</t>
			<t indent="0" pn="section-6-2">
	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="include" removeInRFC="false" pn=
	<section anchor="IANA" title="IANA Considerations">		"section-7">
	<t>This document instructs IANA to insert the following line at the top		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	of the Notes		<t indent="0" pn="section-7-1">IANA has added the following line at the to
	section of the 'Internet Key Exchange (IKE) Attributes' registry and the		p
	'"Magic Numbers" for ISAKMP Protocol' registry: All registries listed be		of the Notes section of the "Internet Key Exchange (IKE) Attributes"
	low have		and '"Magic Numbers" for ISAKMP Protocol' registries: "All
	been closed, see RFCxxxx.		registries listed below have been closed. See RFC 9395." In addition, this
	[Note to RFC Editor: change RFCxxx to this document's RFC number]		document has been added to the "Reference" column in these two registries, and
	</t>		their registration procedures have been changed to "Registry closed".
			</t>
	<t>This document further instructs IANA to add an additional Status colu		<t indent="0" pn="section-7-2">IANA has added a "Status" column to the fol
	mn to		lowing IKEv2 "Transform Type Values" registries:
	the IKEv2 Transform Type registries and mark the following entries as DE		</t>
	PRECATED:		<ul empty="true" spacing="compact" bare="false" indent="3" pn="section-7-3
	<figure align="center" anchor="iana_requests_type1">		">
	<artwork align="left"><![CDATA[		<li pn="section-7-3.1">Transform Type 1 - Encryption Algorithm Transform
			IDs</li>
	Transform Type 1 - Encryption Algorithm IDs		<li pn="section-7-3.2">Transform Type 2 - Pseudorandom Function Transfor
			m IDs</li>
	Number Name Status		<li pn="section-7-3.3">Transform Type 3 - Integrity Algorithm Transform
	------ --------------- ------		IDs</li>
	1 ENCR_DES_IV64 DEPRECATED [this document]		<li pn="section-7-3.4">Transform Type 4 - Key Exchange Method Transform
	2 ENCR_DES DEPRECATED [RFC8247]		IDs</li>
	4 ENCR_RC5 DEPRECATED [this document]		</ul>
	5 ENCR_IDEA DEPRECATED [this document]		<t indent="0" pn="section-7-4">
	6 ENCR_CAST DEPRECATED [this document]		Also, the following entries have been marked as DEPRECATED:
	7 ENCR_BLOWFISH DEPRECATED [this document]		</t>
	8 ENCR_3IDEA DEPRECATED [this document]		<table anchor="iana_requests_type1" align="center" pn="table-1">
	9 ENCR_DES_IV32 DEPRECATED [this document]		<name slugifiedName="name-transform-type-1-encryption">Transform Type 1
	]]></artwork>		- Encryption Algorithm Transform IDs</name>
	</figure>		<thead>
	<figure align="center" anchor="iana_requests_type2">		<tr>
	<artwork align="left"><![CDATA[		<th align="left" colspan="1" rowspan="1">Number</th>
			<th align="left" colspan="1" rowspan="1">Name</th>
	Transform Type 2 - Pseudorandom Function Transform IDs		<th align="left" colspan="1" rowspan="1">Status</th>
			</tr>
	Number Name Status		</thead>
	------ ------------ ----------		<tbody>
	1 PRF_HMAC_MD5 DEPRECATED [RFC8247]		<tr>
	3 PRF_HMAC_TIGER DEPRECATED [this document]		<td align="left" colspan="1" rowspan="1">1</td>
	]]></artwork>		<td align="left" colspan="1" rowspan="1">ENCR_DES_IV64</td>
	</figure>		<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
	<figure align="center" anchor="iana_requests_typ3">		</tr>
	<artwork align="left"><![CDATA[		<tr>
			<td align="left" colspan="1" rowspan="1">2</td>
	Transform Type 3 - Integrity Algorithm Transform IDs		<td align="left" colspan="1" rowspan="1">ENCR_DES</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
	Number Name Status		C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
	------ ----------------- ----------		</tr>
	1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247]		<tr>
	3 AUTH_DES_MAC DEPRECATED [RFC8247]		<td align="left" colspan="1" rowspan="1">4</td>
	4 AUTH_KPDK_MD5 DEPRECATED [RFC8247]		<td align="left" colspan="1" rowspan="1">ENCR_RC5</td>
	6 AUTH_HMAC_MD5_128 DEPRECATED [this document]		<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
	7 AUTH_HMAC_SHA1_160 DEPRECATED [this document]		</tr>
	]]></artwork>		<tr>
	</figure>		<td align="left" colspan="1" rowspan="1">5</td>
	<figure align="center" anchor="iana_requests_type4">		<td align="left" colspan="1" rowspan="1">ENCR_IDEA</td>
	<artwork align="left"><![CDATA[		<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
	Transform Type 4 - Diffie Hellman Group Transform IDs		<tr>
			<td align="left" colspan="1" rowspan="1">6</td>
	Number Name Status		<td align="left" colspan="1" rowspan="1">ENCR_CAST</td>
	------ ---------------------------- ----------		<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
	1 768-bit MODP Group DEPRECATED [RFC8247]		</tr>
	22 1024-bit MODP Group with		<tr>
	160-bit Prime Order Subgroup DEPRECATED [RFC8247]		<td align="left" colspan="1" rowspan="1">7</td>
	]]></artwork>		<td align="left" colspan="1" rowspan="1">ENCR_BLOWFISH</td>
	</figure>		<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">8</td>
			<td align="left" colspan="1" rowspan="1">ENCR_3IDEA</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">9</td>
			<td align="left" colspan="1" rowspan="1">ENCR_DES_IV32</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			</tbody>
			</table>
			<table anchor="iana_requests_type2" align="center" pn="table-2">
			<name slugifiedName="name-transform-type-2-pseudorand">Transform Type 2
			- Pseudorandom Function Transform IDs</name>
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Number</th>
			<th align="left" colspan="1" rowspan="1">Name</th>
			<th align="left" colspan="1" rowspan="1">Status</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
			<td align="left" colspan="1" rowspan="1">PRF_HMAC_MD5</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">3</td>
			<td align="left" colspan="1" rowspan="1">PRF_HMAC_TIGER</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			</tbody>
			</table>
			<table anchor="iana_requests_typ3" align="center" pn="table-3">
			<name slugifiedName="name-transform-type-3-integrity-">Transform Type 3
			- Integrity Algorithm Transform IDs</name>
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Number</th>
			<th align="left" colspan="1" rowspan="1">Name</th>
			<th align="left" colspan="1" rowspan="1">Status</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
			<td align="left" colspan="1" rowspan="1">AUTH_HMAC_MD5_96</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">3</td>
			<td align="left" colspan="1" rowspan="1">AUTH_DES_MAC</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">4</td>
			<td align="left" colspan="1" rowspan="1">AUTH_KPDK_MD5</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">6</td>
			<td align="left" colspan="1" rowspan="1">AUTH_HMAC_MD5_128</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">7</td>
			<td align="left" colspan="1" rowspan="1">AUTH_HMAC_SHA1_160</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td>
			</tr>
			</tbody>
			</table>
			<table anchor="iana_requests_type4" align="center" pn="table-4">
			<name slugifiedName="name-transform-type-4-key-exchan">Transform Type 4
			- Key Exchange Method Transform IDs</name>
			<thead>
			<tr>
			<th align="left" colspan="1" rowspan="1">Number</th>
			<th align="left" colspan="1" rowspan="1">Name</th>
			<th align="left" colspan="1" rowspan="1">Status</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td align="left" colspan="1" rowspan="1">1</td>
			<td align="left" colspan="1" rowspan="1">768-bit MODP Group</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">22</td>
			<td align="left" colspan="1" rowspan="1">1024-bit MODP Group with 16
			0-bit Prime Order Subgroup</td>
			<td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RF
			C8247" format="default" sectionFormat="of" derivedContent="RFC8247"/></td>
			</tr>
			</tbody>
			</table>
			<t indent="0" pn="section-7-9">
	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>
			<displayreference target="I-D.ietf-ipsecme-labeled-ipsec" to="LABELED-IPSEC"
			/>
			<displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/>
			<references pn="section-8">
			<name slugifiedName="name-references">References</name>
			<references pn="section-8.1">
			<name slugifiedName="name-normative-references">Normative References</na
			me>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<author fullname="S. Bradner" initials="S." surname="Bradner"/>
			<date month="March" year="1997"/>
			<abstract>
			<t indent="0">In many standards track documents several words are
			used to signify the requirements in the specification. These words are often ca
			pitalized. This document defines these words as they should be interpreted in I
			ETF documents. This document specifies an Internet Best Current Practices for t
			he Internet Community, and requests discussion and suggestions for improvements.
			</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author fullname="B. Leiba" initials="B." surname="Leiba"/>
			<date month="May" year="2017"/>
			<abstract>
			<t indent="0">RFC 2119 specifies common key words that may be used
			in protocol specifications. This document aims to reduce the ambiguity by clar
			ifying that only UPPERCASE usage of the key words have the defined special meani
			ngs.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			<reference anchor="RFC8247" target="https://www.rfc-editor.org/info/rfc8
			247" quoteTitle="true" derivedAnchor="RFC8247">
			<front>
			<title>Algorithm Implementation Requirements and Usage Guidance for
			the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
			<author fullname="Y. Nir" initials="Y." surname="Nir"/>
			<author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
			<author fullname="P. Wouters" initials="P." surname="Wouters"/>
			<author fullname="D. Migault" initials="D." surname="Migault"/>
			<date month="September" year="2017"/>
			<abstract>
			<t indent="0">The IPsec series of protocols makes use of various c
			ryptographic algorithms in order to provide security services. The Internet Key
			Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IP
			sec SA) parameters, such as which algorithms should be used. To ensure interope
			rability between different implementations, it is necessary to specify a set of
			algorithm implementation requirements and usage guidance to ensure that there is
			at least one algorithm that all implementations support. This document updates
			RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementatio
			n requirements and usage guidance for IKEv2, and does minor cleaning up of the I
			KEv2 IANA registry. This document does not update the algorithms used for packe
			t encryption using IPsec Encapsulating Security Payload (ESP).</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8247"/>
			<seriesInfo name="DOI" value="10.17487/RFC8247"/>
			</reference>
			</references>
			<references pn="section-8.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/deta
			il/CVE-2016-5361" quoteTitle="true" derivedAnchor="CVE-2016-5361">
			<front>
			<title>CVE-2016-5361 Detail</title>
			<author>
			<organization showOnFrontPage="true">NIST National Vulnerability D
			atabase</organization>
			</author>
			<date day="16" month="June" year="2016"/>
			</front>
			</reference>
			<reference anchor="I-D.ietf-ipsecme-g-ikev2" target="https://datatracker
			.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-09" quoteTitle="true" derivedAncho
			r="G-IKEV2">
			<front>
			<title>Group Key Management using IKEv2</title>
			<author initials="V." surname="Smyslov" fullname="Valery Smyslov">
			<organization showOnFrontPage="true">ELVIS-PLUS</organization>
			</author>
			<author initials="B." surname="Weis" fullname="Brian Weis">
			<organization showOnFrontPage="true">Independent</organization>
			</author>
			<date month="April" day="19" year="2023"/>
			<abstract>
			<t indent="0"> This document presents an extension to the Intern
			et 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.
	<references title="Normative References">		This document obsoletes RFC 6407. This documents also updates RFC
	&RFC2119;		7296 by renaming a transform type 5 from "Extended Sequence Numbers
	&RFC8174;		(ESN)" to the "Replay Protection (RP)" and by renaming IKEv2
	&RFC8247;		authentication method 0 from "Reserved" to "NONE".
	</references>
	<references title="Informative References">
	&RFC2407;
	&RFC2408;
	&RFC2409;
	&RFC6407;
	&RFC4306;
	&RFC7296;
	&RFC8221;
	&RFC8784;
	<reference anchor='draft-ietf-ipsecme-labeled-ipsec'>
	<front>
	<title>Labeled IPsec Traffic Selector support for IKEv2</title>
	<author initials='P.' surname="Wouters" fullname='Paul Wouters'>
	</author>
	<author fullname="Sahana Prasad" initials="S." surname="Prasad">
	</author>
	<date month='October' day='25' year='2021' />
	<abstract>
	<t>
	This document defines a new Traffic Selector (TS) Type for
	Internet Key Exchange version 2 to add support for negotiating
	Mandatory Access Control (MAC) security labels as a traffic selector
	of the Security Policy Database (SPD). Security Labels for IPsec
	are also known as "Labeled IPsec". The new TS type is TS_SECLABEL,
	which consists of a variable length opaque field specifying the
	security label. This document updates the IKEv2 TS negotiation
	specified in RFC 7296 Section 2.9.
	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-ipsecme-labeled-ipsec'
	/>
	<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>
			</t>
			</abstract>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-g-ikev2-09
			"/>
			<refcontent>Work in Progress</refcontent>
			</reference>
			<reference anchor="I-D.ietf-ipsecme-labeled-ipsec" target="https://datat
			racker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-11" quoteTitle="true"
			derivedAnchor="LABELED-IPSEC">
			<front>
			<title>Labeled IPsec Traffic Selector support for IKEv2</title>
			<author initials="P." surname="Wouters" fullname="Paul Wouters">
			<organization showOnFrontPage="true">Aiven</organization>
			</author>
			<author initials="S." surname="Prasad" fullname="Sahana Prasad">
			<organization showOnFrontPage="true">Red Hat</organization>
			</author>
			<date month="April" day="10" year="2023"/>
			<abstract>
			<t indent="0"> This document defines a new Traffic Selector (TS)
			Type for Internet
			Key Exchange version 2 to add support for negotiating Mandatory
			Access Control (MAC) security labels as a traffic selector of the
			Security Policy Database (SPD). Security Labels for IPsec are also
			known as "Labeled IPsec". The new TS type is TS_SECLABEL, which
			consists of a variable length opaque field specifying the security
			label.
			</t>
			</abstract>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-ipsecme-labeled-ip
			sec-11"/>
			<refcontent>Work in Progress</refcontent>
			</reference>
			<reference anchor="RFC2407" target="https://www.rfc-editor.org/info/rfc2
			407" quoteTitle="true" derivedAnchor="RFC2407">
			<front>
			<title>The Internet IP Security Domain of Interpretation for ISAKMP<
			/title>
			<author fullname="D. Piper" initials="D." surname="Piper"/>
			<date month="November" year="1998"/>
			<abstract>
			<t indent="0">This document defines the Internet IP Security DOI (
			IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to neg
			otiate security associations. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2407"/>
			<seriesInfo name="DOI" value="10.17487/RFC2407"/>
			</reference>
			<reference anchor="RFC2408" target="https://www.rfc-editor.org/info/rfc2
			408" quoteTitle="true" derivedAnchor="RFC2408">
			<front>
			<title>Internet Security Association and Key Management Protocol (IS
			AKMP)</title>
			<author fullname="D. Maughan" initials="D." surname="Maughan"/>
			<author fullname="M. Schertler" initials="M." surname="Schertler"/>
			<author fullname="M. Schneider" initials="M." surname="Schneider"/>
			<author fullname="J. Turner" initials="J." surname="Turner"/>
			<date month="November" year="1998"/>
			<abstract>
			<t indent="0">This memo describes a protocol utilizing security co
			ncepts necessary for establishing Security Associations (SA) and cryptographic k
			eys in an Internet environment. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2408"/>
			<seriesInfo name="DOI" value="10.17487/RFC2408"/>
			</reference>
			<reference anchor="RFC2409" target="https://www.rfc-editor.org/info/rfc2
			409" quoteTitle="true" derivedAnchor="RFC2409">
			<front>
			<title>The Internet Key Exchange (IKE)</title>
			<author fullname="D. Harkins" initials="D." surname="Harkins"/>
			<author fullname="D. Carrel" initials="D." surname="Carrel"/>
			<date month="November" year="1998"/>
			<abstract>
			<t indent="0">This memo describes a hybrid protocol. The purpose
			is to negotiate, and provide authenticated keying material for, security associa
			tions in a protected manner. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="2409"/>
			<seriesInfo name="DOI" value="10.17487/RFC2409"/>
			</reference>
			<reference anchor="RFC4306" target="https://www.rfc-editor.org/info/rfc4
			306" quoteTitle="true" derivedAnchor="RFC4306">
			<front>
			<title>Internet Key Exchange (IKEv2) Protocol</title>
			<author fullname="C. Kaufman" initials="C." role="editor" surname="K
			aufman"/>
			<date month="December" year="2005"/>
			<abstract>
			<t indent="0">This document describes version 2 of the Internet Ke
			y Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutua
			l authentication and establishing and maintaining security associations (SAs).</
			t>
			<t indent="0">This version of the IKE specification combines the c
			ontents of what were previously separate documents, including Internet Security
			Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the
			Internet Domain of Interpretation (DOI, RFC 2407), Network Address Translation (
			NAT) Traversal, Legacy authentication, and remote address acquisition.</t>
			<t indent="0">Version 2 of IKE does not interoperate with version
			1, but it has enough of the header format in common that both versions can unamb
			iguously run over the same UDP port. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4306"/>
			<seriesInfo name="DOI" value="10.17487/RFC4306"/>
			</reference>
			<reference anchor="RFC6407" target="https://www.rfc-editor.org/info/rfc6
			407" quoteTitle="true" derivedAnchor="RFC6407">
			<front>
			<title>The Group Domain of Interpretation</title>
			<author fullname="B. Weis" initials="B." surname="Weis"/>
			<author fullname="S. Rowles" initials="S." surname="Rowles"/>
			<author fullname="T. Hardjono" initials="T." surname="Hardjono"/>
			<date month="October" year="2011"/>
			<abstract>
			<t indent="0">This document describes the Group Domain of Interpre
			tation (GDOI) protocol specified in RFC 3547. The GDOI provides group key manag
			ement to support secure group communications according to the architecture speci
			fied in RFC 4046. The GDOI manages group security associations, which are used
			by IPsec and potentially other data security protocols. This document replaces
			RFC 3547. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6407"/>
			<seriesInfo name="DOI" value="10.17487/RFC6407"/>
			</reference>
			<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7
			296" quoteTitle="true" derivedAnchor="RFC7296">
			<front>
			<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
			<author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
			<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
			<author fullname="Y. Nir" initials="Y." surname="Nir"/>
			<author fullname="P. Eronen" initials="P." surname="Eronen"/>
			<author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
			<date month="October" year="2014"/>
			<abstract>
			<t indent="0">This document describes version 2 of the Internet Ke
			y Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutu
			al authentication and establishing and maintaining Security Associations (SAs).
			This document obsoletes RFC 5996, and includes all of the errata for it. It ad
			vances IKEv2 to be an Internet Standard.</t>
			</abstract>
			</front>
			<seriesInfo name="STD" value="79"/>
			<seriesInfo name="RFC" value="7296"/>
			<seriesInfo name="DOI" value="10.17487/RFC7296"/>
			</reference>
			<reference anchor="RFC8221" target="https://www.rfc-editor.org/info/rfc8
			221" quoteTitle="true" derivedAnchor="RFC8221">
			<front>
			<title>Cryptographic Algorithm Implementation Requirements and Usage
			Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH
			)</title>
			<author fullname="P. Wouters" initials="P." surname="Wouters"/>
			<author fullname="D. Migault" initials="D." surname="Migault"/>
			<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
			<author fullname="Y. Nir" initials="Y." surname="Nir"/>
			<author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
			<date month="October" year="2017"/>
			<abstract>
			<t indent="0">This document replaces RFC 7321, "Cryptographic Algo
			rithm Implementation Requirements and Usage Guidance for Encapsulating Security
			Payload (ESP) and Authentication Header (AH)". The goal of this document is to
			enable ESP and AH to benefit from cryptography that is up to date while making I
			Psec interoperable.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8221"/>
			<seriesInfo name="DOI" value="10.17487/RFC8221"/>
			</reference>
			<reference anchor="RFC8784" target="https://www.rfc-editor.org/info/rfc8
			784" quoteTitle="true" derivedAnchor="RFC8784">
			<front>
			<title>Mixing Preshared Keys in the Internet Key Exchange Protocol V
			ersion 2 (IKEv2) for Post-quantum Security</title>
			<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
			<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/
			>
			<author fullname="D. McGrew" initials="D." surname="McGrew"/>
			<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
			<date month="June" year="2020"/>
			<abstract>
			<t indent="0">The possibility of quantum computers poses a serious
			challenge to cryptographic algorithms deployed widely today. The Internet Key
			Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could
			be broken; someone storing VPN communications today could decrypt them at a late
			r time when a quantum computer is available. It is anticipated that IKEv2 will
			be extended to support quantum-secure key exchange algorithms; however, that is
			not likely to happen in the near term. To address this problem before then, thi
			s document describes an extension of IKEv2 to allow it to be resistant to a quan
			tum computer by using preshared keys.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8784"/>
			<seriesInfo name="DOI" value="10.17487/RFC8784"/>
			</reference>
			</references>
	</references>		</references>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.a">
			<name slugifiedName="name-authors-address">Author's Address</name>
			<author initials="P." surname="Wouters" fullname="Paul Wouters" role="edit
			or">
			<organization showOnFrontPage="true">Aiven</organization>
			<address>
			<email>paul.wouters@aiven.io</email>
			</address>
			</author>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 37 change blocks.
	332 lines changed or deleted		833 lines changed or added
This html diff was produced by rfcdiff 1.48.