<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC2407 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2407.xml">zwsp "​"> <!ENTITYRFC2408 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2408.xml">nbhy "‑"> <!ENTITYRFC2409 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">wj "⁠"> ]><?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 xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" updates="8221,8247" obsoletes="" docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09" number="9395" submissionType="IETF" category="std"docName="draft-ietf-ipsecme-ikev1-algo-to-historic-09">consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <front> <titleabbrev="Deprecation of IKEv1 and some algorithms">Deprecationabbrev="IKEv1 Deprecation">Deprecation ofIKEv1the Internet Key Exchange Version 1 (IKEv1) Protocol andobsoleted algorithms</title>Obsoleted Algorithms</title> <seriesInfo name="RFC" value="9395"/> <authorinitials='P.'initials="P." surname="Wouters"fullname='Paul Wouters'fullname="Paul Wouters" role="editor"> <organization>Aiven</organization> <address> <email>paul.wouters@aiven.io</email> </address> </author><date/> <area>General</area> <workgroup>Network</workgroup><date year="2023" month="April"/> <area>sec</area> <workgroup>ipsecme</workgroup> <keyword>IKEv1</keyword> <keyword>IKEv2</keyword> <keyword>IPsec</keyword> <keyword>IKE</keyword> <abstract> <t> 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> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> IKEv1 has been moved to Historic status. IKEv1 <xreftarget="RFC2409"/>target="RFC2409" format="default"/> and its related documents forISAKMPthe Internet Security Association and Key Management Protocol (ISAKMP) <xreftarget="RFC2408"/>target="RFC2408" format="default"/> and IPsec DOI <xreftarget="RFC2407"/>target="RFC2407" format="default"/> were obsoleted by IKEv2 <xreftarget="RFC4306"/>target="RFC4306" format="default"/> 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"/>. 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> Algorithm implementation requirements and usage guidelines for IKEv2 <xreftarget="RFC8247"/>target="RFC8247" format="default"/> andESP/AHEncapsulating Security Payload (ESP) and Authentication Header (AH) <xreftarget="RFC8221"/>target="RFC8221" format="default"/> 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">numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="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">anchor="ikev1_historic" numbered="true" toc="default"> <name>RFCs 2407, 2408, and 2409 Are Historic</name> <t> 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"> <li> 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> 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> 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> 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"/>. </li> <li> 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> 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> 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 equivalentsanchor="feature_eq" numbered="true" toc="default"> <name>IKEv1 Feature Equivalents forIKEv2" anchor="feature_eq">IKEv2</name> <t> A few notable IKEv1 features are not present in the IKEv2 core specification <xreftarget="RFC7296"/>target="RFC7296" format="default"/> but are available for IKEv2 via an additionalspecification:specification. </t> <sectiontitle="IKEv2 postquantum support" anchor="ikev2_postq">anchor="ikev2_postq" numbered="true" toc="default"> <name>IKEv2 Post-Quantum Support</name> <t> 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"/>. </t> </section> <sectiontitle="IKEv2anchor="ikev2_labeled" numbered="true" toc="default"> <name>IKEv2 Labeled IPsecsupport" anchor="ikev2_labeled">Support</name> <t> 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"/>. </t> </section> <sectiontitle="IKEv2anchor="ikev2_groupsa" numbered="true" toc="default"> <name>IKEv2 Group SA/and Multicastsupport" anchor="ikev2_groupsa">Support</name> <t> The Group Domain of Interpretation(GDOI,(GDOI) protocol <xreftarget="RFC6407"/>) protocol,target="RFC6407" format="default"/>, 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"/>. </t> </section> </section> <sectiontitle="Deprecating obsolete algorithms" anchor="deprecating_algos">anchor="deprecating_algos" numbered="true" toc="default"> <name>Deprecating Obsolete Algorithms</name> <t>This document deprecates the following algorithms:<list style="symbols"> <t></t> <ul spacing="normal"> <li> 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> PRF Algorithms: the unspecifiedPRF_HMAC_TIGER</t> <t>PRF_HMAC_TIGER</li> <li> Integrity Algorithms:HMAC-MD5-128</t> <t>HMAC-MD5-128</li> <li> Diffie-Hellman groups:none</t> </list> </t>none</li> </ul> </section> <section anchor="Security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>There are only security benefitsby deprecatingif IKEv1for IKEv2.is deprecated and IKEv2 is used. </t> <t> 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="default"> <name>IANA Considerations</name> <t>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>IANA has added a "Status" column to the following IKEv2 "Transform Type Values" registries: </t> <ul empty="true" spacing="compact"> <li>Transform Type 1 - Encryption Algorithm Transform IDs</li> <li>Transform Typeregistries and mark2 - Pseudorandom Function Transform IDs</li> <li>Transform Type 3 - Integrity Algorithm Transform IDs</li> <li>Transform Type 4 - Key Exchange Method Transform IDs</li> </ul> <t> Also, the following entries have been marked as DEPRECATED:<figure align="center" anchor="iana_requests_type1"> <artwork align="left"><![CDATA[ Transform</t> <table anchor="iana_requests_type1" align="center"> <name>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>Number</th> <th>Name</th> <th>Status</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>ENCR_DES_IV64</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>2</td> <td>ENCR_DES</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>4</td> <td>ENCR_RC5</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>5</td> <td>ENCR_IDEA</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>6</td> <td>ENCR_CAST</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>7</td> <td>ENCR_BLOWFISH</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>8</td> <td>ENCR_3IDEA</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>9</td> <td>ENCR_DES_IV32</td> <td>DEPRECATED (RFC 9395)</td> </tr> </tbody> </table> <table anchor="iana_requests_type2" align="center"> <name>Transform Type 2 - Pseudorandom Function TransformIDs Number Name Status ------ ------------ ---------- 1 PRF_HMAC_MD5 DEPRECATED [RFC8247] 3 PRF_HMAC_TIGER DEPRECATED [this document] ]]></artwork> </figure> <figure align="center" anchor="iana_requests_typ3"> <artwork align="left"><![CDATA[ TransformIDs</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>Status</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>PRF_HMAC_MD5</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>3</td> <td>PRF_HMAC_TIGER</td> <td>DEPRECATED (RFC 9395)</td> </tr> </tbody> </table> <table anchor="iana_requests_typ3" align="center"> <name>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> <figure align="center" anchor="iana_requests_type4"> <artwork align="left"><![CDATA[ TransformIDs</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>Status</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>AUTH_HMAC_MD5_96</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>3</td> <td>AUTH_DES_MAC</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>4</td> <td>AUTH_KPDK_MD5</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>6</td> <td>AUTH_HMAC_MD5_128</td> <td>DEPRECATED (RFC 9395)</td> </tr> <tr> <td>7</td> <td>AUTH_HMAC_SHA1_160</td> <td>DEPRECATED (RFC 9395)</td> </tr> </tbody> </table> <table anchor="iana_requests_type4" align="center"> <name>Transform Type 4 -Diffie Hellman GroupKey Exchange Method TransformIDs Number Name Status ------ ---------------------------- ---------- 1 768-bitIDs</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>Status</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>768-bit MODPGroup DEPRECATED [RFC8247] 22 1024-bitGroup</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> <tr> <td>22</td> <td>1024-bit MODP Group with 160-bit Prime OrderSubgroup DEPRECATED [RFC8247] ]]></artwork> </figure>Subgroup</td> <td>DEPRECATED <xref target="RFC8247" format="default"/></td> </tr> </tbody> </table> <t> All entries not mentioned here should receive no value in the new Status field. </t> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC8174; &RFC8247;<displayreference target="I-D.ietf-ipsecme-labeled-ipsec" to="LABELED-IPSEC"/> <displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEV2"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml"/> </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<references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2407.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2409.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6407.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4306.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml"/> <!-- [I-D.ietf-ipsecme-labeled-ipsec] IESG state Publication Requested asa traffic selectorofthe Security Policy Database (SPD). Security Labels for IPsec are also known4/21/23 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ipsecme-labeled-ipsec.xml"/> <!-- [I-D.ietf-ipsecme-g-ikev2] IESG state I-D Exists as"Labeled IPsec". The new TS type is TS_SECLABEL, which consistsofa 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-06.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-03.txt' /> </reference>4/21/23 --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.draft-ietf-ipsecme-g-ikev2.xml"/> <reference anchor="CVE-2016-5361" target="https://nvd.nist.gov/vuln/detail/CVE-2016-5361"> <front><title>National Vulnerability Database - CVE-2016-5361</title><title>CVE-2016-5361 Detail</title> <author><organization>National Institute of Science and Technology (NIST)</organization><organization>NIST National Vulnerability Database</organization> </author> <date day="16" month="June" year="2016"/> </front> </reference> </references> </references> </back> </rfc>