idnits 2.17.1 draft-pwouters-ikev1-ipsec-graveyard-00.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 RFC7296, 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 (March 11, 2019) is 1872 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network P. Wouters, Ed. 3 Internet-Draft Red Hat 4 Updates: 7296 (if approved) March 11, 2019 5 Intended status: Standards Track 6 Expires: September 12, 2019 8 Deprecation of IKEv1 and obsoleted algorithms 9 draft-pwouters-ikev1-ipsec-graveyard-00 11 Abstract 13 This document deprecates Internet Key Exchange version 1 (IKEv1) and 14 additionally deprecates a number of algorithms that are obsolete. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 12, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 52 3. Deprecating IKEv1 . . . . . . . . . . . . . . . . . . . . . . 2 53 4. Deprecating obsolete algorithms . . . . . . . . . . . . . . . 3 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 58 7.2. Informative References . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 IKEv1 [RFC2409] and its related documents for ISAKMP [RFC2408] and 64 IPsec DOI [RFC2407] were obsoleted by IKEv2 [RFC4306] in December 65 2005. The latest version of IKEv2 at the time of writing was 66 published in 2014 in [RFC7296]. The Internet Key Exchange (IKE) 67 version 2 has replaced version 1 over 15 years ago. IKEv2 has now 68 seen wide deployment and provides a full replacement for all IKEv1 69 functionality. No new modifications or new algorithms have been 70 accepted for IKEv1 for at least a decade. IKEv2 addresses various 71 issues present in IKEv1, such as IKEv1 being vulnerable to 72 amplification attacks. This document specifies the deprecation of 73 IKEv1. IKEv1 MUST NOT be deployed. 75 Algorithm implementation requirements and usage guidelines for IKEv2 76 [RFC8247] and ESP/AH [RFC8223] gives guidance to implementors but 77 limits that guidance to avoid broken or weak algorithms. It does not 78 deprecate algorithms that have aged and are no longer in use, but 79 leave these algorithms in a state of "MAY be used". This document 80 deprecates those algorithms that are no longer advised but for which 81 there are no known attacks resulting in their earlier deprecation. 83 2. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 3. Deprecating IKEv1 91 IKEv1 is deprecated and MUST NOT be deployed. Systems running IKEv1 92 should be upgraded and reconfigured to run IKEv2. Systems that 93 support IKEv1 but not IKEv2 are most likely also unsuitable 94 candidates for continued operation. Such unsupported systems have a 95 much higher chance of containing an implementation vulnerability that 96 will never be patched. IKEv1 systems can be abused for packet 97 amplification attacks. IKEv1 systems most likely do not support 98 modern algorithms such as AES-GCM or CHACHA20_POLY1305 and quite 99 often only support or have been configured to use the very weak 100 DiffieHellman Groups 2 and 5. IKEv1 systems must be upgraded or 101 replaced by IKEv2 systems. 103 IKEv1 and its way of using Preshared Keys (PSKs) protects against 104 quantum computer based attacks. IKEv2 updated its use of PSK to 105 improve the error reporting, but at the expense of post-quantum 106 security. If post-quantum security is required, these systems should 107 be migrated to use IKEv2 Postquantum Preshared Keys (PPK) 108 [draft-ietf-ipsecme-qr-ikev2]. 110 Some IKEv1 implementations support Labeled IPsec, a method to 111 negotiate an addition Security Context selector to the SPD, but this 112 method was never standarized in IKEv1. Those IKEv1 systems that 113 require Labeled IPsec should migrate to an IKEv2 system supporting 114 Labeled IPsec as specified in [draft-ietf-ipsecme-labeled-ipsec]. 116 EDITOR NOTE: This document is expected to be released only after the 117 PPK draft has become an RFC. While the same could be said for 118 Labeled IPsec, there is no IKEv1 RFC that specifies Labeled IPsec, so 119 pointing to a draft here does not demote a reference from RFC to a 120 draft. 122 4. Deprecating obsolete algorithms 124 This document deprecates the following algorithms: 126 o Encryption Algorithms: 1DES, RC5, IDEA, CAST, Blowfish and 3IDEA 128 o PRF Algorithms: HMAC-MD5 130 o Integrity Algorithms: HMAC-MD5-96, HMAC-MD5-128 and HMAC-SHA1-160 132 o Diffie-Hellman groups: 1, 2, 5, 22, 23 and 24 134 5. Security Considerations 136 There are only security benefits by deprecating IKEv1 for IKEv2. 138 The deprecated algorithms have long been in disuse and are no longer 139 actively deployed or researched. It presents an unknown security 140 risk that is best avoided. Additionally, these algorithms not being 141 supported in implementations simplifies those implementations and 142 reduces the accidental use of these deprecated algorithms through 143 misconfiguration or downgrade attacks. 145 6. IANA Considerations 147 This document instructs IANA to mark all IKEv1 registries as 148 DEPRECATED. 150 Additionally, this document instructs IANA to add an additional 151 Status column to the IKEv2 Transform Type registries and mark the 152 following entries as DEPRECATED: 154 Transform Type 1 - Encryption Algorithm IDs 156 Number Name Status 157 ------ --------------- ------ 158 1 ENCR_DES_IV64 DEPRECATED 159 2 ENCR_DES DEPRECATED 160 4 ENCR_RC5 DEPRECATED 161 5 ENCR_IDEA DEPRECATED 162 6 ENCR_CAST DEPRECATED 163 7 ENCR_BLOWFISH DEPRECATED 164 8 ENCR_3IDEA DEPRECATED 165 9 ENCR_DES_IV32 DEPRECATED 167 Figure 1 169 Transform Type 2 - Pseudorandom Function Transform IDs 171 Number Name Status 172 ------ ------------ ---------- 173 1 PRF_HMAC_MD5 DEPRECATED 175 Figure 2 177 Transform Type 3 - Integrity Algorithm Transform IDs 179 Number Name Status 180 ------ ----------------- ---------- 181 1 AUTH_HMAC_MD5_96 DEPRECATED 182 6 AUTH_HMAC_MD5_128 DEPRECATED 183 7 AUTH_HMAC_SHA1_160 DEPRECATED 185 Figure 3 187 Transform Type 4 - Diffie Hellman Group Transform IDs 189 Number Name Status 190 ------ ---------------------------- ---------- 191 1 768-bit MODP Group DEPRECATED 192 2 1024-bit MODP Group DEPRECATED 193 5 1536-bit MODP Group DEPRECATED 194 22 1024-bit MODP Group with 195 160-bit Prime Order Subgroup DEPRECATED 196 23 2048-bit MODP Group with 197 224-bit Prime Order Subgroup DEPRECATED 198 24 2048-bit MODP Group with 199 256-bit Prime Order Subgroup DEPRECATED 201 Figure 4 203 All entries not mentioned here should receive no value in the new 204 Status field. 206 7. References 208 7.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, 212 DOI 10.17487/RFC2119, March 1997, . 215 [RFC2407] Piper, D., "The Internet IP Security Domain of 216 Interpretation for ISAKMP", RFC 2407, 217 DOI 10.17487/RFC2407, November 1998, . 220 [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, 221 "Internet Security Association and Key Management Protocol 222 (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, 223 . 225 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 226 (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, 227 . 229 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 230 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 231 . 233 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 234 Kivinen, "Internet Key Exchange Protocol Version 2 235 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 236 2014, . 238 [RFC8223] Esale, S., Torvi, R., Jalil, L., Chunduri, U., and K. 239 Raza, "Application-Aware Targeted LDP", RFC 8223, 240 DOI 10.17487/RFC8223, August 2017, . 243 [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, 244 "Algorithm Implementation Requirements and Usage Guidance 245 for the Internet Key Exchange Protocol Version 2 (IKEv2)", 246 RFC 8247, DOI 10.17487/RFC8247, September 2017, 247 . 249 7.2. Informative References 251 [draft-ietf-ipsecme-labeled-ipsec] 252 Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector 253 support for IKEv2", draft-ietf-ipsecme-labeled-ipsec (work 254 in progress), March 2019. 256 [draft-ietf-ipsecme-qr-ikev2] 257 Fluhrer, S., McGre, D., Kampanakis, P., and V. Smyslov, 258 "Postquantum Preshared Keys for IKEv2", draft-ietf- 259 ipsecme-qr-ikev2 (work in progress), January 2019. 261 Author's Address 263 Paul Wouters (editor) 264 Red Hat 266 Email: pwouters@redhat.com