<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC2407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2407.xml"> <!ENTITY RFC2408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.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" ?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09" indexInclude="true" ipr="trust200902" number="9395" prepTime="2023-04-24T15:26:03" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" updates="8221,8247"obsoletes="" category="std" docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09">xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic-09" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9395" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="Deprecationabbrev="IKEv1 Deprecation">Deprecation ofIKEv1 and some algorithms">Deprecation of IKEv1the Internet Key Exchange Version 1 (IKEv1) Protocol andobsoleted algorithms</title>Obsoleted Algorithms</title> <seriesInfo name="RFC" value="9395" stream="IETF"/> <authorinitials='P.'initials="P." surname="Wouters"fullname='Paul Wouters'fullname="Paul Wouters" role="editor"><organization>Aiven</organization><organization showOnFrontPage="true">Aiven</organization> <address> <email>paul.wouters@aiven.io</email> </address> </author><date/> <area>General</area> <workgroup>Network</workgroup><date month="04" year="2023"/> <area>sec</area> <workgroup>ipsecme</workgroup> <keyword>IKEv1</keyword> <keyword>IKEv2</keyword> <keyword>IPsec</keyword> <keyword>IKE</keyword><abstract> <t><abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"> Internet Key ExchangeversionVersion 1 (IKEv1) has beendeprecateddeprecated, andits specification in RFC2407, RFC2408RFCs 2407, 2408, andRFC24092409 have been moved to Historic status. This document updatesRFCRFCs 8221 andRFC8247 to reflect the usage guidelines of old algorithms that are associated withIKEv1,IKEv1 and are not specified or commonly implemented for IKEv2. This document further updates the IANA registries for IKEv2Transform"Transform Typeregistries to addValues" by adding aStatus"Status" column where the deprecation status can be listed. </t> </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="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">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 derivedContent="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" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-ikev2-post-quantum-support">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 derivedContent="" format="title" sectionFormat="of" target="name-ikev2-labeled-ipsec-support">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 derivedContent="" format="title" sectionFormat="of" target="name-ikev2-group-sa-and-multicas">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" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-deprecating-obsolete-algori">Deprecating 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" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" 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="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <sectiontitle="Introduction"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1"> IKEv1 has been moved to Historic status. IKEv1 <xreftarget="RFC2409"/>target="RFC2409" format="default" sectionFormat="of" derivedContent="RFC2409"/> and its related documents forISAKMPthe Internet Security Association and Key Management Protocol (ISAKMP) <xreftarget="RFC2408"/>target="RFC2408" format="default" sectionFormat="of" derivedContent="RFC2408"/> and IPsec DOI <xreftarget="RFC2407"/>target="RFC2407" format="default" sectionFormat="of" derivedContent="RFC2407"/> were obsoleted by IKEv2 <xreftarget="RFC4306"/>target="RFC4306" format="default" sectionFormat="of" derivedContent="RFC4306"/> in December 2005. The latest version of IKEv2 at the time of writing was published in 2014in<xreftarget="RFC7296"/>. The Internet Key Exchange (IKE) version 2 hastarget="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296"/>. Since IKEv2 replacedversion 1IKEv1 over 15 yearsago.ago, IKEv2 has now seen widedeploymentdeployment, 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 indent="0" pn="section-1-2"> Algorithm implementation requirements and usage guidelines for IKEv2 <xreftarget="RFC8247"/>target="RFC8247" format="default" sectionFormat="of" derivedContent="RFC8247"/> and Encapsulating Security Payload (ESP) andESP/AHAuthentication Header (AH) <xreftarget="RFC8221"/>target="RFC8221" format="default" sectionFormat="of" derivedContent="RFC8221"/> gives guidance to implementors but limits that guidance to avoid broken or weak algorithms. These two RFCs do not deprecate algorithms that have aged and are not inuse, butuse. Instead, they leave these algorithms in a state of"MAY"<bcp14>MAY</bcp14> be used" by not mentioning them. This document deprecates those unmentioned algorithms that are no longer advised but for which there are no known attacks resulting in their earlier deprecation. </t> </section> <sectiontitle="Requirements Language"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-requirements-language">Requirements Language</name> <t indent="0" pn="section-2-1"> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xreftarget="RFC8174"/>target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="RFC2407, RFC2408 and RFC2409 are Historic" anchor="ikev1_historic"> <t>anchor="ikev1_historic" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-rfcs-2407-2408-and-2409-are">RFCs 2407, 2408, and 2409 Are Historic</name> <t indent="0" pn="section-3-1"> As IKEv1 isdeprecated. Systemsdeprecated, systems running IKEv1 should be upgraded and reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2 are most likely also unsuitable candidates for continuedoperation: <list style="symbols"> <t>operation for the following reasons: </t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-2"> <li pn="section-3-2.1"> IKEv1 development ceased over a decadeagoago, and no new work will happen. This poses the risk of unmaintained code in an otherwise supportedproductproduct, which can result in security vulnerabilities.</t> <t></li> <li pn="section-3-2.2"> A number of IKEv1 systems have reached their End of Lifeand thereforand, therefore, will never be patched by the vendor if a vulnerability is found.</t> <t></li> <li pn="section-3-2.3"> There are vendors that still provide updates for their equipment that supports IKEv1 andIKEv2,IKEv2 but have "frozen" their IKEv1 implementation. Such users might not be aware that they are running unmaintained code with its associated security risks.</t> <t></li> <li pn="section-3-2.4"> IKEv1 systems can be abused for packet amplification attacks, as documented in the Security Bulletin <xreftarget="CVE-2016-5361"/>. </t> <t>target="CVE-2016-5361" format="default" sectionFormat="of" derivedContent="CVE-2016-5361"/>. </li> <li pn="section-3-2.5"> Great strides have been made in cryptography since IKEv1 development ceased. While some modern cryptographic algorithms were added to IKEv1, interoperability concerns mean that the defacto algorithms negotiated by IKEv1 will consist of dated or deprecatedalgorithmsalgorithms, like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 provides a state-of-the-art suite of cryptographic algorithms that IKEv1 lacks.</t> </list></li> </ul> <t indent="0" pn="section-3-3"> IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more modern cryptographic primitives, proper defense againstdenial of servicedenial-of-service attacks, improved authentication viaEAPExtensible Authentication Protocol (EAP) methods,PAKE supportand password-authenticated key exchange (PAKE) support. Also, IKEv2 is actively worked on with respect to defending againstquantum computerquantum-computer attacks. </t><t><t indent="0" pn="section-3-4"> IKEv1-only systems should be upgraded or replaced by systems supporting IKEv2. IKEv2 implementationsSHOULD NOT<bcp14>SHOULD NOT</bcp14> directly import IKEv1 configurations without updating the cryptographic algorithms used. </t> </section> <sectiontitle="IKEv1 feature equivalents for IKEv2" anchor="feature_eq"> <t>anchor="feature_eq" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-ikev1-feature-equivalents-f">IKEv1 Feature Equivalents for IKEv2</name> <t indent="0" pn="section-4-1"> A few notable IKEv1 features are not present in the IKEv2 core specification <xreftarget="RFC7296"/>target="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296"/> but are available for IKEv2 via an additionalspecification:specification. </t> <sectiontitle="IKEv2 postquantum support" anchor="ikev2_postq"> <t>anchor="ikev2_postq" numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <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 againstquantum computer basedquantum-computer-based attacks. IKEv2 updated its use ofPSKPSKs to improve the errorreporting,reporting but at the expense of post-quantum security. If post-quantum security is required, these systems should be migrated to use IKEv2PostquantumPost-quantum Preshared Keys(PPK)(PPKs) <xreftarget="RFC8784"/>target="RFC8784" format="default" sectionFormat="of" derivedContent="RFC8784"/>. </t> </section> <sectiontitle="IKEv2anchor="ikev2_labeled" numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-ikev2-labeled-ipsec-support">IKEv2 Labeled IPsecsupport" anchor="ikev2_labeled"> <t>Support</name> <t indent="0" pn="section-4.2-1"> Some IKEv1 implementations support Labeled IPsec, a method to negotiate an additional Security Context selector to theSPD,Security Policy Database (SPD), but this method was never standardized in IKEv1. Those IKEv1 systems that require Labeled IPsec should migrate to an IKEv2 system supporting Labeled IPsec as specified in <xreftarget="draft-ietf-ipsecme-labeled-ipsec"/>.target="I-D.ietf-ipsecme-labeled-ipsec" format="default" sectionFormat="of" derivedContent="LABELED-IPSEC"/>. </t> </section> <sectiontitle="IKEv2anchor="ikev2_groupsa" numbered="true" toc="include" removeInRFC="false" pn="section-4.3"> <name slugifiedName="name-ikev2-group-sa-and-multicas">IKEv2 Group SA/and Multicastsupport" anchor="ikev2_groupsa"> <t>Support</name> <t indent="0" pn="section-4.3-1"> The Group Domain of Interpretation(GDOI,(GDOI) protocol <xreftarget="RFC6407"/>) protocol,target="RFC6407" format="default" sectionFormat="of" derivedContent="RFC6407"/>, which is based onIKEv1IKEv1, defines the support for Multicast Group SAs. For IKEv2, this work is currently in progress via <xreftarget="draft-ietf-ipsecme-g-ikev2"/>target="I-D.ietf-ipsecme-g-ikev2" format="default" sectionFormat="of" derivedContent="G-IKEV2"/>. </t> </section> </section> <sectiontitle="Deprecating obsolete algorithms" anchor="deprecating_algos"> <t>Thisanchor="deprecating_algos" numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-deprecating-obsolete-algori">Deprecating Obsolete Algorithms</name> <t indent="0" pn="section-5-1">This document deprecates the following algorithms:<list style="symbols"> <t></t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2"> <li pn="section-5-2.1"> Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecified 3IDEA,ENCR_DES_IV64ENCR_DES_IV64, andENCR_DES_IV32</t> <t>ENCR_DES_IV32</li> <li pn="section-5-2.2"> PRF Algorithms: the unspecifiedPRF_HMAC_TIGER</t> <t>PRF_HMAC_TIGER</li> <li pn="section-5-2.3"> Integrity Algorithms:HMAC-MD5-128</t> <t>HMAC-MD5-128</li> <li pn="section-5-2.4"> Diffie-Hellman groups:none</t> </list> </t>none</li> </ul> </section> <section anchor="Security"title="Security Considerations"> <t>Therenumbered="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 benefitsby deprecatingif IKEv1for IKEv2.is deprecated and IKEv2 is used. </t><t><t indent="0" pn="section-6-2"> The deprecated algorithms have long been in disuse and are no longer actively deployed orresearched. Itresearched; this presents an unknown security risk that is best avoided. Additionally, these algorithms not being supported in implementations simplifies those implementations and reduces the accidental use ofthesedeprecated algorithms through misconfiguration or downgrade attacks. </t> </section> <section anchor="IANA"title="IANA Considerations"> <t>This document instructs IANA to insertnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-7-1">IANA has added the following line at the top of the Notes section of the'Internet"Internet Key Exchange (IKE)Attributes' registryAttributes" andthe'"Magic Numbers" for ISAKMP Protocol'registry: Allregistries: "All registries listed below have beenclosed, see RFCxxxx. [Note toclosed. See RFCEditor: change RFCxxx to9395." In addition, thisdocument's RFC number] </t> <t>Thisdocumentfurther instructs IANAhas been added toadd an additional Statusthe "Reference" column in these two registries, and their registration procedures have been changed to "Registry closed". </t> <t indent="0" pn="section-7-2">IANA has added a "Status" column to the following IKEv2 "Transform Type Values" registries: </t> <ul empty="true" spacing="compact" bare="false" indent="3" pn="section-7-3"> <li pn="section-7-3.1">Transform Type 1 - Encryption Algorithm Transform IDs</li> <li pn="section-7-3.2">Transform Typeregistries and mark2 - Pseudorandom Function Transform IDs</li> <li pn="section-7-3.3">Transform Type 3 - Integrity Algorithm Transform IDs</li> <li pn="section-7-3.4">Transform Type 4 - Key Exchange Method Transform IDs</li> </ul> <t indent="0" pn="section-7-4"> Also, the following entries have been marked as DEPRECATED:<figure</t> <table anchor="iana_requests_type1" align="center"anchor="iana_requests_type1"> <artwork align="left"><![CDATA[ Transformpn="table-1"> <name slugifiedName="name-transform-type-1-encryption">Transform Type 1 - Encryption AlgorithmIDs Number Name Status ------ --------------- ------ 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 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">ENCR_DES_IV64</td> <td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1">ENCR_DES</td> <td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RFC8247" 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">ENCR_RC5</td> <td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">5</td> <td align="left" colspan="1" rowspan="1">ENCR_IDEA</td> <td align="left" colspan="1" rowspan="1">DEPRECATED (RFC 9395)</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">6</td> <td align="left" colspan="1" rowspan="1">ENCR_CAST</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">ENCR_BLOWFISH</td> <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 TransformIDs Number Name Status ------ ------------ ---------- 1 PRF_HMAC_MD5 DEPRECATED [RFC8247] 3 PRF_HMAC_TIGER DEPRECATED [this document] ]]></artwork> </figure> <figureIDs</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="RFC8247" 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"anchor="iana_requests_typ3"> <artwork align="left"><![CDATA[ Transformpn="table-3"> <name slugifiedName="name-transform-type-3-integrity-">Transform Type 3 - Integrity Algorithm TransformIDs Number Name Status ------ ----------------- ---------- 1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247] 3 AUTH_DES_MAC DEPRECATED [RFC8247] 4 AUTH_KPDK_MD5 DEPRECATED [RFC8247] 6 AUTH_HMAC_MD5_128 DEPRECATED [this document] 7 AUTH_HMAC_SHA1_160 DEPRECATED [this document] ]]></artwork> </figure> <figureIDs</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="RFC8247" 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="RFC8247" 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="RFC8247" 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"anchor="iana_requests_type4"> <artwork align="left"><![CDATA[ Transformpn="table-4"> <name slugifiedName="name-transform-type-4-key-exchan">Transform Type 4 -Diffie Hellman GroupKey Exchange Method TransformIDs Number Name Status ------ ---------------------------- ---------- 1 768-bitIDs</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 MODPGroup DEPRECATED [RFC8247] 22 1024-bitGroup</td> <td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RFC8247" 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 160-bit Prime OrderSubgroup DEPRECATED [RFC8247] ]]></artwork> </figure>Subgroup</td> <td align="left" colspan="1" rowspan="1">DEPRECATED <xref target="RFC8247" 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. </t> </section> </middle> <back> <displayreference target="I-D.ietf-ipsecme-labeled-ipsec" to="LABELED-IPSEC"/> <displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/> <referencestitle="Normative References"> &RFC2119; &RFC8174; &RFC8247; </references>pn="section-8"> <name slugifiedName="name-references">References</name> <referencestitle="Informative References"> &RFC2407; &RFC2408; &RFC2409; &RFC6407; &RFC4306; &RFC7296; &RFC8221; &RFC8784;pn="section-8.1"> <name slugifiedName="name-normative-references">Normative References</name> <referenceanchor='draft-ietf-ipsecme-labeled-ipsec'>anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front><title>Labeled IPsec Traffic Selector support<title>Key words forIKEv2</title> <author initials='P.' surname="Wouters" fullname='Paul Wouters'> </author>use in RFCs to Indicate Requirement Levels</title> <authorfullname="Sahana Prasad"fullname="S. Bradner" initials="S."surname="Prasad"> </author>surname="Bradner"/> <datemonth='October' day='25' year='2021' />month="March" year="1997"/> <abstract><t><t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document definesa new Traffic Selector (TS) Typethese words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</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/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 KeyExchange version 2Words</title> <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 toadd support for negotiating Mandatory Access Control (MAC) security labels as a traffic selectorreduce the ambiguity by clarifying that only UPPERCASE usage of theSecurity Policy Database (SPD). Security Labelskey words have the defined special meanings.</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/rfc8247" 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 IPsecare also known as "Labeled IPsec".series of protocols makes use of various cryptographic algorithms in order to provide security services. Thenew TS typeInternet Key Exchange (IKE) protocol isTS_SECLABEL,used to negotiate the IPsec Security Association (IPsec SA) parameters, such as whichconsists ofalgorithms should be used. To ensure interoperability between different implementations, it is necessary to specify avariable length opaque field specifying the security label.set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updatesthe IKEv2 TS negotiation specified inRFC 7296Section 2.9. </t>and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).</t> </abstract> </front> <seriesInfoname='Internet-Draft' value='draft-ietf-ipsecme-labeled-ipsec' /> <format type='TXT' target='https://tools.ietf.org/id/draft-ietf-ipsecme-labeled-ipsec-06.txt' />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> <referenceanchor='draft-ietf-ipsecme-g-ikev2'>anchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/detail/CVE-2016-5361" quoteTitle="true" derivedAnchor="CVE-2016-5361"> <front> <title>CVE-2016-5361 Detail</title> <author> <organization showOnFrontPage="true">NIST National Vulnerability Database</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" derivedAnchor="G-IKEV2"> <front> <title>Group Key Management using IKEv2</title> <authorinitials='V.'initials="V." surname="Smyslov"fullname='Valery Smyslov'> <organization>ELVIS-PLUS</organization>fullname="Valery Smyslov"> <organization showOnFrontPage="true">ELVIS-PLUS</organization> </author> <authorfullname="Brian Weis"initials="B."surname="Weis"> <organization>Independent</organization>surname="Weis" fullname="Brian Weis"> <organization showOnFrontPage="true">Independent</organization> </author> <datemonth='January' day='11' year='2021' />month="April" day="19" year="2023"/> <abstract><t><t indent="0"> 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. This documents also updates RFC 7296 by renaming a transform type 5 from "Extended Sequence Numbers (ESN)" to the "Replay Protection (RP)" and by renaming IKEv2 authentication method 0 from "Reserved" to "NONE". </t> </abstract> </front> <seriesInfoname='Internet-Draft' value='draft-ietf-ipsecme-g-ikev2' /> <format type='TXT' target='https://www.ietf.org/archive/id/draft-ietf-ipsecme-g-ikev2-03.txt' />name="Internet-Draft" value="draft-ietf-ipsecme-g-ikev2-09"/> <refcontent>Work in Progress</refcontent> </reference> <referenceanchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/detail/CVE-2016-5361">anchor="I-D.ietf-ipsecme-labeled-ipsec" target="https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-11" quoteTitle="true" derivedAnchor="LABELED-IPSEC"> <front><title>National Vulnerability<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- CVE-2016-5361</title> <author> <organization>National Institute(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-ipsec-11"/> <refcontent>Work in Progress</refcontent> </reference> <reference anchor="RFC2407" target="https://www.rfc-editor.org/info/rfc2407" quoteTitle="true" derivedAnchor="RFC2407"> <front> <title>The Internet IP Security Domain ofScienceInterpretation 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 negotiate 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/rfc2408" quoteTitle="true" derivedAnchor="RFC2408"> <front> <title>Internet Security Association andTechnology (NIST)</organization> </author>Key Management Protocol (ISAKMP)</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 concepts necessary for establishing Security Associations (SA) and cryptographic keys 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/rfc2409" 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 associations 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/rfc4306" quoteTitle="true" derivedAnchor="RFC4306"> <front> <title>Internet Key Exchange (IKEv2) Protocol</title> <author fullname="C. Kaufman" initials="C." role="editor" surname="Kaufman"/> <date month="December" year="2005"/> <abstract> <t indent="0">This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs).</t> <t indent="0">This version of the IKE specification combines the contents 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 unambiguously 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/rfc6407" 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 Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified 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/rfc7296" 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 Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.</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/rfc8221" 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 Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.</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/rfc8784" quoteTitle="true" derivedAnchor="RFC8784"> <front> <title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 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"/> <dateday="16"month="June"year="2016"/>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 later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</t> </abstract> </front> <seriesInfo name="RFC" value="8784"/> <seriesInfo name="DOI" value="10.17487/RFC8784"/> </reference> </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="editor"> <organization showOnFrontPage="true">Aiven</organization> <address> <email>paul.wouters@aiven.io</email> </address> </author> </section> </back> </rfc>