idnits 2.17.1 draft-ietf-ipsecme-ikev1-algo-to-historic-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8247, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7296, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8221, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 April 2022) is 725 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network P. Wouters, Ed. 3 Internet-Draft Aiven 4 Updates: 7296, 8221, 8247 (if approved) 29 April 2022 5 Intended status: Standards Track 6 Expires: 31 October 2022 8 Deprecation of IKEv1 and obsoleted algorithms 9 draft-ietf-ipsecme-ikev1-algo-to-historic-03 11 Abstract 13 Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, 14 IKEv1 has been moved to Historic status. A number of old algorithms 15 that are associated with IKEv1, and not widely implemented for IKEv2 16 are deprecated as well. This document adds a Status column to the 17 IANA IKEv2 Transform Type registries. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 31 October 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. RFC 2409 to Historic . . . . . . . . . . . . . . . . . . . . 3 55 4. IKEv1 feature equivalents for IKEv2 . . . . . . . . . . . . . 3 56 4.1. IKEv2 postquantum support . . . . . . . . . . . . . . . . 4 57 4.2. IKEv2 Labeled IPsec support . . . . . . . . . . . . . . . 4 58 4.3. IKEv2 Group SA / Multicast support . . . . . . . . . . . 4 59 5. Deprecating obsolete algorithms . . . . . . . . . . . . . . . 4 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 IKEv1 [RFC2409] and its related documents for ISAKMP [RFC2408] and 70 IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December 71 2005. The latest version of IKEv2 at the time of writing was 72 published in 2014 in [RFC7296]. The Internet Key Exchange (IKE) 73 version 2 has replaced version 1 over 15 years ago. IKEv2 has now 74 seen wide deployment and provides a full replacement for all IKEv1 75 functionality. No new modifications or new algorithms have been 76 accepted for IKEv1 for at least a decade. IKEv2 addresses various 77 issues present in IKEv1, such as IKEv1 being vulnerable to 78 amplification attacks. IKEv1 has been moved to Historic status. 80 Algorithm implementation requirements and usage guidelines for IKEv2 81 [RFC8247] and ESP/AH [RFC8223] gives guidance to implementors but 82 limits that guidance to avoid broken or weak algorithms. It does not 83 deprecate algorithms that have aged and are not in use, but leave 84 these algorithms in a state of "MAY be used". This document 85 deprecates those algorithms that are no longer advised but for which 86 there are no known attacks resulting in their earlier deprecation. 88 2. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 3. RFC 2409 to Historic 98 IKEv1 is deprecated. Systems running IKEv1 should be upgraded and 99 reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2 100 are most likely also unsuitable candidates for continued operation: 102 * IKEv1 development ceased over a decade ago and no new work will 103 happen. This poses the risk of unmaintained code in an otherwise 104 supported product which can result in security vulnerabilities. 106 * A number of IKEv1 systems have reached their End of Life and 107 therefor will never be patched by the vendor if a vulnerability is 108 found. 110 * There are vendors that still provide updates for their equipment 111 that supports IKEv1 and IKEv2, but have "frozen" their IKEv1 112 implementation. Such users might not be aware that they are 113 running unmaintained code with its associated security risks. 115 * IKEv1 systems can be abused for packet amplification attacks, as 116 documented in the Security Bulletin CVE-2016-5361. 118 * Great strides have been made in cryptography since IKEv1 119 development ceased. While some modern cryptographic algorithms 120 were added to IKEv1, interoperability concerns mean that the 121 defacto algorithms negotiated by IKEv1 will consist of dated or 122 deprecated algorithms like AES-CBC, SHA1, and Diffie-Hellman 123 groups 1 or 2. IKEv2 provides state-of-the-art suite of 124 cryptographic algorithms that IKEv1 lacks. 126 IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 127 offers more modern cryptographic primitives, proper defense against 128 denial of service attacks, improved authentication via EAP methods, 129 PAKE support and is actively worked on with respect to defending 130 against quantum computer attacks. 132 IKEv1-only systems should be upgraded or replaced by systems 133 supporting IKEv2. IKEv1 configurations SHOULD NOT be directly 134 translated to IKEv2 configurations without updating the cryptographic 135 algorithms used. 137 4. IKEv1 feature equivalents for IKEv2 139 A few notably IKEv1 features are not present in the IKEv2 core 140 specification [RFC7296] but are available for IKEv2 via an additional 141 specification: 143 4.1. IKEv2 postquantum support 145 IKEv1 and its way of using Preshared Keys (PSKs) protects against 146 quantum computer based attacks. IKEv2 updated its use of PSK to 147 improve the error reporting, but at the expense of post-quantum 148 security. If post-quantum security is required, these systems should 149 be migrated to use IKEv2 Postquantum Preshared Keys (PPK) [RFC8784] 151 4.2. IKEv2 Labeled IPsec support 153 Some IKEv1 implementations support Labeled IPsec, a method to 154 negotiate an addition Security Context selector to the SPD, but this 155 method was never standarized in IKEv1. Those IKEv1 systems that 156 require Labeled IPsec should migrate to an IKEv2 system supporting 157 Labeled IPsec as specified in [draft-ietf-ipsecme-labeled-ipsec]. 159 4.3. IKEv2 Group SA / Multicast support 161 The Group Domain of Interpretation (GDOI, [RFC6407]) protocol, based 162 on IKEv1 defines the support for Multicast Group SAs. For IKEv2, 163 this work is currently in progress via [draft-ietf-ipsecme-g-ikev2] 165 5. Deprecating obsolete algorithms 167 This document deprecates the following algorithms: 169 * Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the 170 unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32 172 * PRF Algorithms: the unspecified PRF_HMAC_TIGER 174 * Integrity Algorithms: HMAC-MD5-128 176 * Diffie-Hellman groups: none 178 6. Security Considerations 180 There are only security benefits by deprecating IKEv1 for IKEv2. 182 The deprecated algorithms have long been in disuse and are no longer 183 actively deployed or researched. It presents an unknown security 184 risk that is best avoided. Additionally, these algorithms not being 185 supported in implementations simplifies those implementations and 186 reduces the accidental use of these deprecated algorithms through 187 misconfiguration or downgrade attacks. 189 7. IANA Considerations 191 This document instructs IANA to add an additional Status column to 192 the IKEv2 Transform Type registries and mark the following entries as 193 DEPRECATED: 195 Transform Type 1 - Encryption Algorithm IDs 197 Number Name Status 198 ------ --------------- ------ 199 1 ENCR_DES_IV64 DEPRECATED [this document] 200 2 ENCR_DES DEPRECATED [RFC8247] 201 4 ENCR_RC5 DEPRECATED [this document] 202 5 ENCR_IDEA DEPRECATED [this document] 203 6 ENCR_CAST DEPRECATED [this document] 204 7 ENCR_BLOWFISH DEPRECATED [this document] 205 8 ENCR_3IDEA DEPRECATED [this document] 206 9 ENCR_DES_IV32 DEPRECATED [this document] 208 Figure 1 210 Transform Type 2 - Pseudorandom Function Transform IDs 212 Number Name Status 213 ------ ------------ ---------- 214 1 PRF_HMAC_MD5 DEPRECATED [RFC8247] 215 1 PRF_HMAC_TIGER DEPRECATED [this document] 217 Figure 2 219 Transform Type 3 - Integrity Algorithm Transform IDs 221 Number Name Status 222 ------ ----------------- ---------- 223 1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247] 224 3 AUTH_DES_MAC DEPRECATED [RFC8247] 225 4 AUTH_KPDK_MD5 DEPRECATED [RFC8247] 226 6 AUTH_HMAC_MD5_128 DEPRECATED [this document] 227 7 AUTH_HMAC_SHA1_160 DEPRECATED [this document] 229 Figure 3 231 Transform Type 4 - Diffie Hellman Group Transform IDs 233 Number Name Status 234 ------ ---------------------------- ---------- 235 1 768-bit MODP Group DEPRECATED [RFC8247] 236 22 1024-bit MODP Group with 237 160-bit Prime Order Subgroup DEPRECATED [RFC8247] 239 Figure 4 241 All entries not mentioned here should receive no value in the new 242 Status field. 244 8. References 246 8.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC2407] Piper, D., "The Internet IP Security Domain of 254 Interpretation for ISAKMP", RFC 2407, 255 DOI 10.17487/RFC2407, November 1998, 256 . 258 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 259 "Internet Security Association and Key Management Protocol 260 (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, 261 . 263 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 264 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 265 . 267 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 268 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 269 . 271 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 272 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 273 October 2011, . 275 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 276 Kivinen, "Internet Key Exchange Protocol Version 2 277 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 278 2014, . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC8223] Esale, S., Torvi, R., Jalil, L., Chunduri, U., and K. 285 Raza, "Application-Aware Targeted LDP", RFC 8223, 286 DOI 10.17487/RFC8223, August 2017, 287 . 289 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 290 "Algorithm Implementation Requirements and Usage Guidance 291 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 292 RFC 8247, DOI 10.17487/RFC8247, September 2017, 293 . 295 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 296 "Mixing Preshared Keys in the Internet Key Exchange 297 Protocol Version 2 (IKEv2) for Post-quantum Security", 298 RFC 8784, DOI 10.17487/RFC8784, June 2020, 299 . 301 8.2. Informative References 303 [draft-ietf-ipsecme-g-ikev2] 304 Smyslov, V. and B. Weis, "Group Key Management using 305 IKEv2", Work in Progress, Internet-Draft, draft-ietf- 306 ipsecme-g-ikev2, 11 January 2021, 307 . 310 [draft-ietf-ipsecme-labeled-ipsec] 311 Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector 312 support for IKEv2", Work in Progress, Internet-Draft, 313 draft-ietf-ipsecme-labeled-ipsec, 25 October 2021, 314 . 317 Author's Address 319 Paul Wouters (editor) 320 Aiven 321 Email: paul.wouters@aiven.io