<?xml version="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" ?>
<rfc ipr="trust200902"
    updates="7296,8221,8247"
    obsoletes=""
    category="std"
    docName="draft-ietf-ipsecme-ikev1-algo-to-historic-04">

  <front>
    <title abbrev="Deprecation of IKEv1 and some algorithms">Deprecation of IKEv1 and obsoleted algorithms</title>

<author initials='P.' surname="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>
    <keyword>IKEv1</keyword>
    <keyword>IKEv2</keyword>
    <keyword>IPsec</keyword>
    <keyword>IKE</keyword>
    
    <abstract>
      <t>
      Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly,
      IKEv1 has been moved to Historic status. A number of old algorithms
      that are associated with IKEv1, and not widely implemented for IKEv2
      are deprecated as well. This document adds a Status column to the
      IANA IKEv2 Transform Type registries.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
      IKEv1 <xref target="RFC2409"/> and its related documents for ISAKMP
      <xref target="RFC2408"/> and IPsec DOI <xref target="RFC2407"/>
      were obsoleted by IKEv2 <xref target="RFC4306"/> in December
      2005. The latest version of IKEv2 at the time of writing was
      published in 2014 in <xref target="RFC7296"/>.  The Internet Key
      Exchange (IKE) version 2 has replaced version 1 over 15 years ago.
      IKEv2 has now seen wide deployment and 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. IKEv1 has been moved to Historic status.
      </t>
      <t>
       Algorithm implementation requirements and usage guidelines
       for IKEv2 <xref target="RFC8247"/> and ESP/AH <xref target="RFC8221"/>
       gives guidance to implementors but limits that guidance to avoid
       broken or weak algorithms. It does not deprecate algorithms that
       have aged and are not in use, but leave these algorithms in
       a state of "MAY be used". This document deprecates those algorithms that
       are no longer advised but for which there are no known attacks
       resulting in their earlier deprecation.
      </t>
    </section>
    
   <section title="Requirements Language">
      <t>
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
       and "OPTIONAL" in this document are to be interpreted as described in
       BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.
      </t>
   </section>
      
   <section title="RFC 2409 to Historic" anchor="ikev1_historic">
   <t>
     IKEv1 is deprecated. 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 continued
     operation:
   <list style="symbols">
   <t>
     IKEv1 development ceased over a decade ago and no new work will
     happen. This poses the risk of unmaintained code in an otherwise
     supported product which can result in security vulnerabilities.
   </t>
   <t>
     A number of IKEv1 systems have reached their End of Life and
     therefor will never be patched by the vendor if a vulnerability
     is found.
   </t>
   <t>
     There are vendors that still provide updates for their equipment
     that supports IKEv1 and 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>
     IKEv1 systems can be abused for packet amplification attacks, as
     documented in the Security Bulletin CVE-2016-5361.
   </t>
   <t>
     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 deprecated algorithms
     like AES-CBC, SHA1, and Diffie-Hellman groups 1 or 2. IKEv2 provides
     state-of-the-art suite of cryptographic algorithms that IKEv1 lacks.
   </t>

   </list>
     IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 offers more
     modern cryptographic primitives, proper defense against denial of service
     attacks, improved authentication via EAP methods, PAKE support and is
     actively worked on with respect to defending against quantum computer attacks.
    </t>
    <t>
     IKEv1-only systems should be upgraded or replaced by systems supporting
     IKEv2. IKEv1 configurations SHOULD NOT be directly translated to IKEv2
     configurations without updating the cryptographic algorithms used.
    </t>

    </section>

    <section title="IKEv1 feature equivalents for IKEv2" anchor="feature_eq">
    <t>
      A few notably IKEv1 features are not present in the IKEv2 core specification
      <xref target="RFC7296"/> but are available for IKEv2 via an additional specification:
    </t>

     <section title="IKEv2 postquantum support" anchor="ikev2_postq">
     <t>
       IKEv1 and its way of using Preshared Keys (PSKs) protects against
       quantum computer based attacks. IKEv2 updated its use of PSK to improve
       the error reporting, but at the expense of post-quantum security. If
       post-quantum security is required, these systems should be migrated
       to use IKEv2 Postquantum Preshared Keys (PPK) <xref target="RFC8784"/>
     </t>
     </section>

     <section title="IKEv2 Labeled IPsec support" anchor="ikev2_labeled">
     <t>
       Some IKEv1 implementations support Labeled IPsec, a method
       to negotiate an addition Security Context selector to the
       SPD, but this method was never standarized in IKEv1. Those IKEv1
       systems that require Labeled IPsec should migrate to an
       IKEv2 system supporting Labeled IPsec as specified in
       <xref target="draft-ietf-ipsecme-labeled-ipsec"/>.
     </t>
     </section>

     <section title="IKEv2 Group SA / Multicast support" anchor="ikev2_groupsa">
     <t>
       The Group Domain of Interpretation (GDOI, <xref target="RFC6407"/>) protocol,
       based on IKEv1 defines the support for Multicast Group SAs. For IKEv2, this
       work is currently in progress via <xref target="draft-ietf-ipsecme-g-ikev2"/>
     </t>
     </section>
   </section>

   <section title="Deprecating obsolete algorithms" anchor="deprecating_algos">
     <t>This document deprecates the following algorithms:
       <list style="symbols">
       <t> Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the unspecified 3IDEA,
           ENCR_DES_IV64 and ENCR_DES_IV32</t>
       <t> PRF Algorithms: the unspecified PRF_HMAC_TIGER</t>
       <t> Integrity Algorithms: HMAC-MD5-128</t>
       <t> Diffie-Hellman groups: none</t>
       </list>
       </t>
   </section>
<section anchor="Security" title="Security Considerations">
    <t>There are only security benefits by deprecating IKEv1 for IKEv2.
    </t>
    <t>
     The deprecated algorithms have long been in disuse and are no longer
     actively deployed or researched. It 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 of these deprecated algorithms through
     misconfiguration or downgrade attacks.
    </t>
</section>

    <section anchor="IANA" title="IANA Considerations">
        <t>This document instructs IANA to add an additional Status column to
        the IKEv2 Transform Type registries and mark the following entries as DEPRECATED:
        <figure align="center" anchor="iana_requests_type1">
            <artwork align="left"><![CDATA[
                
          Transform Type 1 - Encryption Algorithm IDs

          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 Type 2 - Pseudorandom Function Transform IDs

          Number    Name                Status
          ------    ------------        ----------
          1         PRF_HMAC_MD5        DEPRECATED [RFC8247]
          1         PRF_HMAC_TIGER      DEPRECATED [this document]
            ]]></artwork>
        </figure>
        <figure align="center" anchor="iana_requests_typ3">
            <artwork align="left"><![CDATA[

          Transform Type 3 - Integrity Algorithm Transform IDs

          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[

          Transform Type 4 - Diffie Hellman Group Transform IDs

          Number    Name                           Status
          ------    ----------------------------   ----------
          1         768-bit MODP Group             DEPRECATED [RFC8247]
          22        1024-bit MODP Group with
                    160-bit Prime Order Subgroup   DEPRECATED [RFC8247]
            ]]></artwork>
        </figure>
        All entries not mentioned here should receive no value in the new Status field.
        </t>
    </section>
  </middle>
  <back>

    <references title="Normative References">
     &RFC2119;
     &RFC2407;
     &RFC2408;
     &RFC2409;
     &RFC6407;
     &RFC4306;
     &RFC7296;
     &RFC8174;
     &RFC8221;
     &RFC8247;
     &RFC8784;
    </references>
   <references title="Informative References">
 <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-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>
    </references>
  </back>
</rfc>
