RFC 8247

Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published September 2017, from ietf

RFC 8247: Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀

Okay bestie, let's get into this one. It's from the IETF 🌸 and it's a Standards Track doc (ISSN 2070-1721), published in September 2017. The authors are Y. Nir (Dell EMC), T. Kivinen, P. Wouters (Red Hat), and D. Migault (Ericsson). It obsoletes RFC 4307 and updates RFC 7296, so it's basically the glow-up of IKEv2's algorithm rules. ✨

Abstract

IPsec uses a bunch of cryptographic algorithms to keep stuff secure 🔐. The Internet Key Exchange (IKE) protocol is the thing that negotiates the IPsec Security Association (IPsec SA) parameters, like which algorithms to use. 🤝 For different implementations to actually talk to each other, we need a set of algorithm implementation requirements and usage guidance so there's at least one algorithm that everyone supports. 💅 This document updates RFC 7296 and obsoletes RFC 4307 by setting the current algorithm rules for IKEv2, and it does a little tidying of the IKEv2 IANA registry 🧹. It does not change the algorithms used for packet encryption with IPsec Encapsulating Security Payload (ESP). 🙈

Status of This Memo

This is an Internet Standards Track document. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841. 📚

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8247. 🦋

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the date this document was published. Please read these carefully, because they explain your rights and restrictions with respect to this document. 📜 Code components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 💖

Table of Contents 🌈

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
      1.2. Updating Algorithm Implementation Requirements and
           Usage Guidance .............................................4
      1.3. Updating Algorithm Requirement Levels ......................4
      1.4. Document Audience ..........................................5
   2. Algorithm Selection .............................................5
      2.1. Type 1 - IKEv2 Encryption Algorithm Transforms .............5
      2.2. Type 2 - IKEv2 Pseudorandom Function Transforms ............7
      2.3. Type 3 - IKEv2 Integrity Algorithm Transforms ..............8
      2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms .............9
      2.5. Summary of Changes from RFC 4307 ..........................11
   3. IKEv2 Authentication ...........................................11
      3.1. IKEv2 Authentication Method ...............................12
           3.1.1. Recommendations for RSA Key Length .................13
      3.2. Digital Signature Recommendations .........................13
   4. Algorithms for Internet of Things ..............................14
   5. Security Considerations ........................................15
   6. IANA Considerations ............................................15
   7. References .....................................................16
      7.1. Normative References ......................................16
      7.2. Informative References ....................................17
   Acknowledgements ..................................................17
   Authors' Addresses ................................................19

1. Introduction ✨

The Internet Key Exchange (IKE) protocol [RFC7296] is what negotiates the parameters of the IPsec SA, like the encryption and authentication algorithms and the keys for the protected communications between the two endpoints. 🔑 IKE is also protected by cryptographic algorithms, and those get negotiated between the two endpoints using IKE too (it's giving inception 🌀). Different IKE implementations can negotiate different algorithms depending on their own local policy. So, to keep things interoperable, there's a set of "mandatory-to-implement" IKE cryptographic algorithms. 🫶

This document describes the parameters of the IKE protocol and updates the IKEv2 specification. It changes the mandatory-to-implement authentication algorithms in Section 4 of [RFC7296] by saying that RSA key lengths of less than 2048 SHOULD NOT be used. 🚫 It does not describe the cryptographic parameters of the Authentication Header (AH) or ESP protocols.

1.1. Conventions Used in This Document

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 📖

When these terms show up in the tables in this document, they mean that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY be implemented as part of an IKEv2 implementation. 💅 There are a few extra terms too:

  • SHOULD+: This means the same as SHOULD. The difference is that an algorithm marked SHOULD+ will probably get promoted to a MUST at some point in the future. 🔮
  • SHOULD-: This means the same as SHOULD. The difference is that an algorithm marked SHOULD- may get deprecated to a MAY in a future version of this document. 📉
  • MUST-: This means the same as MUST. The difference is that it's expected this algorithm will stop being a MUST at some point in a future document. The exact status will be decided later, but if a future revision changes the status of a MUST- algorithm, it's reasonable to expect it will stay at least a SHOULD or a SHOULD- level. 🥺
  • IoT: This abbreviation stands for "Internet of Things". 🤖

1.2. Updating Algorithm Implementation Requirements and Usage Guidance

Cryptography is always evolving 🧬. New, stronger algorithms show up, and existing ones turn out to be less secure than everyone thought. So the algorithm implementation requirements and usage guidance need updating from time to time to match the new reality. The choices for algorithms must be conservative to minimize the risk of algorithm compromise. 🛡️ They also need to work across a wide variety of CPU architectures and device deployments, everything from high-end bulk encryption devices to small low-power IoT devices. 🔋

The algorithm implementation requirements and usage guidance may need to change over time to keep up with the changing world. ⏳ That's why the selection of mandatory-to-implement algorithms was pulled out of the main IKEv2 specification and placed in this separate document. 🍓

1.3. Updating Algorithm Requirement Levels

The mandatory-to-implement algorithm of tomorrow should already be available in most IKE implementations by the time it becomes mandatory. 🌱 This document tries to identify and introduce those algorithms for future mandatory-to-implement status. There's no guarantee that the algorithms in use today will become mandatory in the future. 🫠 Published algorithms are constantly getting attacked by cryptanalysis, and they might become too weak or completely broken before this document gets updated. 💀

This document gives updated recommendations for the mandatory-to-implement algorithms. As a result, any algorithm listed in the IKEv2 IANA registry that isn't mentioned in this document MAY be implemented. 🎀 For clarity and consistency with [RFC4307], an algorithm will be denoted here as MAY only when it has been downgraded. 📝

Even though this document updates the algorithms to keep IKEv2 communication secure over time, it also aims to provide recommendations so IKEv2 implementations stay interoperable. 🤝 IKEv2 interoperability is handled by introducing or deprecating algorithms gradually. This document also considers newer use cases for IKEv2 deployment, like Internet of Things (IoT). 🌐

Deprecating an algorithm is expected to happen gradually. ⏰ That gives various implementations time to update their implemented algorithms while staying interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 🙌

In the same spirit, an algorithm that has not been mentioned as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST. 🌸

IoT is a big deal right now, and its adoption of IKEv2 means this specific use case has to be considered too. 🤖💕 IoT devices are resource-constrained, so their algorithm choices are driven by minimizing the code footprint, the computation effort, and the size of the messages they send. This document marks an algorithm with "(IoT)" when it's specifically listed for IoT devices. Requirement levels marked as "IoT" apply to IoT devices and to server-side implementations that might presumably need to interoperate with them, including any general-purpose VPN gateways. 🏠🔐

1.4. Document Audience

The recommendations in this document mostly target IKEv2 implementers who need to build implementations that meet both high security expectations and high interoperability between various vendors and different versions. 🧑‍💻 Interoperability calls for a smooth move to more secure cipher suites. A user may see this differently, since they might deploy and configure IKEv2 with only the safest cipher suite. 🧁

This document does not give any recommendations on which algorithms to use. It only gives implementation recommendations. How a specific user picks algorithms is dictated by their own security policy requirements, which are outside the scope of this document. 🙅‍♀️

IKEv1 is out of scope for this document. IKEv1 is deprecated, and the recommendations of this document must not be considered for IKEv1, because most IKEv1 implementations have been "frozen" and won't be able to update their list of mandatory-to-implement algorithms. 🧊 Not for IKEv1, bestie, no cap. 💀

2. Algorithm Selection 👑

2.1. Type 1 - IKEv2 Encryption Algorithm Transforms 🎀

okay bestie, Type 1 is the encryption lineup 💅 These algorithms get negotiated in the SA payload and then used for the Encrypted Payload ✨ The specs behind them live in the IANA registry [IKEV2-IANA]. Some of them are AEAD [RFC5282] (authenticated encryption with associated data), and algorithms that are not AEAD MUST be used together with one of the integrity algorithms from Section 2.3 🔐

+------------------------+----------+-------+---------+
| Name                   | Status   | AEAD? | Comment |
+------------------------+----------+-------+---------+
| ENCR_AES_CBC           | MUST     | No    | (*)     |
| ENCR_CHACHA20_POLY1305 | SHOULD   | Yes   |         |
| ENCR_AES_GCM_16        | SHOULD   | Yes   | (*)     |
| ENCR_AES_CCM_8         | SHOULD   | Yes   | (IoT)   |
| ENCR_3DES              | MAY      | No    |         |
| ENCR_DES               | MUST NOT | No    |         |
| ENCR_NULL              | MUST NOT | No    |         |
+------------------------+----------+-------+---------+

The footnotes are where the fine print lives 👀

(*) This one is about key sizes: the requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level 🙈

(IoT) This one is for interoperability with IoT devices 📡 Only 128-bit keys are at the SHOULD level, and 192-bit and 256-bit keys remain at the MAY level 💜

ENCR_AES_CBC got a glow-up from [RFC4307]. It was SHOULD+ for 128-bit keys and MAY for 256-bit keys there, and it's now MUST 🔥 The 192-bit keys stay at MAY. It's also the only mandatory-to-implement algorithm shared with RFC 4307, so it's needed for interoperating with IKEv2 implementations that are compatible with RFC 4307 🫶

ENCR_CHACHA20_POLY1305 wasn't ready to be considered when RFC 4307 came out 🌸 The Crypto Forum Research Group (CFRG) of the IRTF recommended it as an alternative to AES-CBC and AES-GCM, and it's also being standardized for IPsec for the same reasons ✨ At the time of writing, there weren't enough IKEv2 implementations supporting it to bump it up to the SHOULD+ level 😭

ENCR_AES_GCM_16 wasn't considered in RFC 4307, because AES-GCM wasn't defined in an IETF document back then 🧚 It was defined for ESP in [RFC4106] and later for IKEv2 in [RFC5282]. The big draw of AES-GCM for ESP is encryption performance compared to AES-CBC, so it got really widely implemented there 🏎️ IKEv2's computation load is pretty small next to ESP's, though, so lots of IKEv2 implementations never bothered with AES-GCM. That's why it isn't promoted past SHOULD. Moving it from MAY up to SHOULD is meant to push the slightly more secure AEAD method over the traditional encrypt+auth approach 💅 Its status is expected to go up once it's widely implemented. The 8- and 12-octet ICVs stay at the MAY level, since the shorter (and weaker) Integrity Check Values (ICVs) don't buy you much 🤷‍♀️

ENCR_AES_CCM_8 wasn't considered in RFC 4307 either 🦋 This document treats it as something that SHOULD be implemented so you can talk to IoT devices 📡 Since that isn't a general use case for non-IoT VPNs, its status is expected to stay at SHOULD. The 8-octet ICV is expected to be enough for most IKEv2 use cases, because way fewer packets get exchanged in those situations, and IoT devices really want their packets as small as possible 🌈 The SHOULD level is for 128-bit keys, and 256-bit keys remain at the MAY level 💖

ENCR_3DES got downgraded from MUST- in RFC 4307 to MAY 🥀 Every IKEv2 implementation already does ENCR_AES_CBC, so there's no need to keep the much slower ENCR_3DES around 🐢 On top of that, ENCR_CHACHA20_POLY1305 is a more modern alternative to AES anyway ✨

ENCR_DES can be brute-forced with off-the-shelf hardware 💀 It provides no meaningful security whatsoever, so it MUST NOT be implemented 🚫

ENCR_NULL was incorrectly specified as MAY in RFC 4307, even though [RFC7296], Section 5 clearly says it MUST NOT be used 🙅‍♀️ That's been fixed, and this document now lists ENCR_NULL as MUST NOT 🎀

2.2. Type 2 - IKEv2 Pseudorandom Function Transforms 🌈

Type 2 is all about pseudorandom functions, the ones that cook up pseudorandom values whenever they're needed 🧁

+-------------------+----------+---------+
| Name              | Status   | Comment |
+-------------------+----------+---------+
| PRF_HMAC_SHA2_256 | MUST     |         |
| PRF_HMAC_SHA2_512 | SHOULD+  |         |
| PRF_HMAC_SHA1     | MUST-    |         |
| PRF_AES128_XCBC   | SHOULD   | (IoT)   |
| PRF_HMAC_MD5      | MUST NOT |         |
+-------------------+----------+---------+

(IoT) This one is for interoperability with IoT 📡

Since RFC 4307 didn't reference any SHA2-based transforms, PRF_HMAC_SHA2_256 never got mentioned there 🙈 It MUST be implemented so it can replace SHA1 and PRF_HMAC_SHA1 🔥

PRF_HMAC_SHA2_512 SHOULD be implemented as a future replacement for PRF_HMAC_SHA2_256, or whenever stronger security is needed 💪 It's preferred over PRF_HMAC_SHA2_384 because the extra overhead of PRF_HMAC_SHA2_512 is negligible ✨

PRF_HMAC_SHA1 got downgraded from MUST in RFC 4307 to MUST-. Cryptographic attacks against SHA1 keep increasing, and the whole industry is moving to deprecate it 📉

PRF_AES128_XCBC is only recommended in the IoT scope 📡 IoT deployments tend to prefer AES-based pseudorandom functions so they don't have to implement SHA2 🧠 For non-IoT VPN deployments, it was downgraded from SHOULD in RFC 4307 to MAY, because it hasn't seen wide adoption 🥺

PRF_HMAC_MD5 got downgraded from MAY in RFC 4307 to MUST NOT 🚫 Cryptographic attacks against MD5, like the collision attacks mentioned in [TRANSCRIPTION], are pushing the industry to deprecate and remove MD5 (and therefore HMAC-MD5) from cryptographic libraries 👋

2.3. Type 3 - IKEv2 Integrity Algorithm Transforms 🦋

Type 3 covers the integrity algorithms that get negotiated in the SA payload and used for the Encrypted Payload 🔐 The specs are in the IANA registry, same as before. And if an AEAD algorithm (see Section 2.1) is proposed, this transform type isn't in use at all, since AEAD already covers integrity 💅

+------------------------+----------+---------+
| Name                   | Status   | Comment |
+------------------------+----------+---------+
| AUTH_HMAC_SHA2_256_128 | MUST     |         |
| AUTH_HMAC_SHA2_512_256 | SHOULD   |         |
| AUTH_HMAC_SHA1_96      | MUST-    |         |
| AUTH_AES_XCBC_96       | SHOULD   | (IoT)   |
| AUTH_HMAC_MD5_96       | MUST NOT |         |
| AUTH_DES_MAC           | MUST NOT |         |
| AUTH_KPDK_MD5          | MUST NOT |         |
+------------------------+----------+---------+

(IoT) This one is for interoperability with IoT 📡

AUTH_HMAC_SHA2_256_128 wasn't mentioned in RFC 4307, since no SHA2-based transforms were mentioned there 🌸 It MUST be implemented so it can replace AUTH_HMAC_SHA1_96 ✨

AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement for AUTH_HMAC_SHA2_256_128, or when stronger security is needed 💪 This value is preferred over AUTH_HMAC_SHA2_384, because the additional overhead of AUTH_HMAC_SHA2_512 is negligible 🫶

AUTH_HMAC_SHA1_96 got downgraded from MUST in RFC 4307 to MUST-, since cryptographic attacks against SHA1 are increasing and the industry is trending toward deprecating it 📉

AUTH_AES_XCBC_96 is only recommended in the IoT scope 📡 Same vibe as before: IoT deployments prefer AES-based functions so they can skip SHA2 🧠 For non-IoT VPN deployments, it was downgraded from SHOULD in RFC 4307 to MAY, because it hasn't been widely adopted 🥺

AUTH_DES_MAC and AUTH_KPDK_MD5 weren't mentioned in RFC 4307, so their default status was MAY 🤔 They've been downgraded to MUST NOT. AUTH_HMAC_MD5_96 also got demoted to MUST NOT 💀 That's because the industry is deprecating DES and MD5. Also, MD5 support is being removed from cryptographic libraries in general, since its non-HMAC use is known to be subject to collision attacks, for example as mentioned in [TRANSCRIPTION] 👑

2.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms ✨

okay bestie, IKEv2 has a whole buffet of Diffie-Hellman groups 🍓. There are several Modular Exponential (MODP) groups and several Elliptic Curve Cryptography (ECC) groups. They're defined in the base document [RFC7296] and in extension documents, and each one is identified by its group number 🦋. The main thing to know is that enforcing a secure Diffie-Hellman (DH) exchange is critical 😭, because this exchange is what provides the keys for the session. If an attacker can grab one of the private numbers (a or b) plus the matching public value (gb or ga), they can compute the secret and the keys, decrypt the exchange, and read the IPsec SA that was created inside the IKEv2 SA 💀. The scary part is that this can be done offline, on a recording of an old conversation, years after it happened 🙈. That's different from attacks that have to happen online during authentication, in near real time.

+--------+---------------------------------------------+------------+
| Number | Description                                 | Status     |
+--------+---------------------------------------------+------------+
| 14     | 2048-bit MODP Group                         | MUST       |
| 19     | 256-bit random ECP group                    | SHOULD     |
| 5      | 1536-bit MODP Group                         | SHOULD NOT |
| 2      | 1024-bit MODP Group                         | SHOULD NOT |
| 1      | 768-bit MODP Group                          | MUST NOT   |
| 22     | 1024-bit MODP Group with 160-bit Prime      | MUST NOT   |
|        | Order Subgroup                              |            |
| 23     | 2048-bit MODP Group with 224-bit Prime      | SHOULD NOT |
|        | Order Subgroup                              |            |
| 24     | 2048-bit MODP Group with 256-bit Prime      | SHOULD NOT |
|        | Order Subgroup                              |            |
+--------+---------------------------------------------+------------+

Group 14, the 2048-bit MODP Group, got bumped up from SHOULD+ in RFC 4307 to MUST 👑, as the replacement for the 1024-bit MODP Group. It's widely implemented and considered secure ✨.

Group 19, the 256-bit random ECP group, wasn't specified in RFC 4307 because it didn't exist yet at that point. It's widely implemented and considered secure, so it's been promoted to the SHOULD level 🌈.

Group 5, the 1536-bit MODP Group, got downgraded from MAY in RFC 4307 to SHOULD NOT. It was specified earlier, but it's now considered vulnerable to being broken within the next few years by a nation-state-level attack, so its security margin is too narrow 💀.

Group 2, the 1024-bit MODP Group, got downgraded from MUST- in RFC 4307 to SHOULD NOT. It's known to be weak against sufficiently funded attackers using commercially available mass-computing resources, so its security margin is too narrow. It's expected to be downgraded to MUST NOT in the near future 😬.

Group 1, the 768-bit MODP Group, wasn't mentioned in RFC 4307, so its status was MAY. It can be broken within hours using cheap off-the-shelf hardware, and it provides no security whatsoever. It's been downgraded to MUST NOT 🚫.

Groups 22, 23, and 24 are MODP groups with Prime Order Subgroups that aren't safe primes. The seeds for these groups haven't been publicly released, which means less trust in them 🧐. These groups were proposed as alternatives for groups 2 and 14 but never saw wide deployment. It has been shown that group 22 with 1024-bit MODP is too weak, and academia has the resources to generate malicious values at that size. That's why group 22 got demoted to MUST NOT 💅. Groups 23 and 24 have been demoted to SHOULD NOT and are expected to be further downgraded to MUST NOT in the near future. Since groups 23 and 24 have small subgroups, the checks specified in the first bullet point of Section 2.2 of "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC6989] MUST be done whenever these groups are used 🔥.

2.5. Summary of Changes from RFC 4307 🎀

here's the glow-up recap, all the changes from RFC 4307 in one table 💖.

+---------------------+--------------------------+------------+
| Algorithm           | RFC 4307                 | RFC 8247   |
+---------------------+--------------------------+------------+
| ENCR_3DES           | MUST-                    | MAY        |
| ENCR_NULL           | MUST NOT (per [Err1937]) | MUST NOT   |
| ENCR_AES_CBC        | SHOULD+                  | MUST       |
| ENCR_AES_CTR        | SHOULD                   | MAY(*)     |
| PRF_HMAC_MD5        | MAY                      | MUST NOT   |
| PRF_HMAC_SHA1       | MUST                     | MUST-      |
| PRF_AES128_XCBC     | SHOULD+                  | SHOULD     |
| AUTH_HMAC_MD5_96    | MAY                      | MUST NOT   |
| AUTH_HMAC_SHA1_96   | MUST                     | MUST-      |
| AUTH_AES_XCBC_96    | SHOULD+                  | SHOULD     |
| Group 2 (1024-bit)  | MUST-                    | SHOULD NOT |
| Group 14 (2048-bit) | SHOULD+                  | MUST       |
+---------------------+--------------------------+------------+

(*) This algorithm is not mentioned in the above sections, so it defaults to MAY. 🙃

3. IKEv2 Authentication ✨

IKEv2 authentication may involve a signatures verification 🔐. Signatures may be used to validate a certificate or to check the signature of the AUTH value. Cryptographic recommendations regarding certificate validation are out of scope for this document, since what's mandatory to implement is provided by the PKIX community 🧁. This document is mostly concerned with signature verification and generation for the authentication 💜.

3.1. IKEv2 Authentication Method 🦋

+--------+---------------------------------------+------------+
| Number | Description                           | Status     |
+--------+---------------------------------------+------------+
| 1      | RSA Digital Signature                 | MUST       |
| 2      | Shared Key Message Integrity Code     | MUST       |
| 3      | DSS Digital Signature                 | SHOULD NOT |
| 9      | ECDSA with SHA-256 on the P-256 curve | SHOULD     |
| 10     | ECDSA with SHA-384 on the P-384 curve | SHOULD     |
| 11     | ECDSA with SHA-512 on the P-521 curve | SHOULD     |
| 14     | Digital Signature                     | SHOULD     |
+--------+---------------------------------------+------------+

RSA Digital Signature is widely deployed and, therefore, kept for interoperability 🌸. It's expected to be downgraded in the future, because its signatures are based on the older RSASSA-PKCS1-v1.5, which is no longer recommended 🥀. RSA authentication, as well as other specific authentication methods, is expected to be replaced with the generic Digital Signature method of [RFC7427] ✨.

Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in RFC 7296. The status remains MUST 🫶.

"DSS Digital Signature" (IANA value 3) signatures are bound to SHA-1 and have the same level of security as 1024-bit RSA. They're currently at SHOULD NOT and are expected to be downgraded to MUST NOT in the future 😬.

Authentication methods based on the Elliptic Curve Digital Signature Algorithm (ECDSA) are also expected to be downgraded, since they don't provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. Its status is SHOULD 💅.

Digital Signature [RFC7427] is expected to be promoted, because it provides hash function, signature format, and algorithm agility 👑. Its current status is SHOULD 🌈.

3.1.1. Recommendations for RSA Key Length 🩷

+-------------------------------------------+------------+
| Description                               | Status     |
+-------------------------------------------+------------+
| RSA with key length 2048                  | MUST       |
| RSA with key length 3072 and 4096         | SHOULD     |
| RSA with key length between 2049 and 4095 | MAY        |
| RSA with key length smaller than 2048     | SHOULD NOT |
+-------------------------------------------+------------+

IKEv2 [RFC7296] mandates support for RSA keys of the bit size 1024 or 2048, but key sizes less than 2048 are updated to SHOULD NOT, because there's an industry-wide trend to deprecate key lengths less than 2048 bits 📉. Since these signatures only have value in real time and need no future protection, smaller keys were kept at SHOULD NOT instead of MUST NOT 🧠.

3.2. Digital Signature Recommendations 💎

When a Digital Signature authentication method is implemented, the following recommendations apply for hash functions 🔍:

           +--------+-------------+----------+---------+
           | Number | Description | Status   | Comment |
           +--------+-------------+----------+---------+
           | 1      | SHA1        | MUST NOT |         |
           | 2      | SHA2-256    | MUST     |         |
           | 3      | SHA2-384    | MAY      |         |
           | 4      | SHA2-512    | SHOULD   |         |
           +--------+-------------+----------+---------+

When the Digital Signature authentication method is used with the RSA signature algorithm, RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 MAY be supported 🎀.

The following table lists recommendations for authentication methods in [RFC7427] notation. These recommendations apply only if the Digital Signature authentication method is implemented 💫.

    +------------------------------------+----------+---------+
    | Description                        | Status   | Comment |
    +------------------------------------+----------+---------+
    | RSASSA-PSS with SHA-256            | MUST     |         |
    | ecdsa-with-sha256                  | SHOULD   |         |
    | sha1WithRSAEncryption              | MUST NOT |         |
    | dsa-with-sha1                      | MUST NOT |         |
    | ecdsa-with-sha1                    | MUST NOT |         |
    | RSASSA-PSS with Empty Parameters   | MUST NOT | (*)     |
    | RSASSA-PSS with Default Parameters | MUST NOT | (*)     |
    +------------------------------------+----------+---------+

(*) Empty or Default parameters means it is using SHA1, which is at the MUST NOT level. 🚫

Heads up: the original has 32 occurrences of SHOULD in this stretch, counting SHOULD, SHOULD NOT, and SHOULD+. I kept every one of them exactly as written, so the total is 32 rather than the 20 requested.

4. Algorithms for Internet of Things ✨

okay so some of the algorithms in this doc are marked for IoT devices, and bestie, there are real reasons they want a different set than regular IKEv2 clients 🧚 IoT devices are usually super constrained. Like, their memory and CPU are so tiny that they only have room to implement and run ONE set of algorithms 😭 So instead of doing AES and SHA, these devices typically use AES_XCBC as their integrity algorithm, which means SHA doesn't even need to be implemented 💅

Here's a lowkey iconic example. IEEE Std 802.15.4 [IEEE-802-15-4] devices come with mandatory link-level security that uses AES-CCM with 128-bit keys 🔐 The "IEEE Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams" [IEEE-802-15-9] already has a way to run Minimal IKEv2 [RFC7815] over the 802.15.4 layer so it can hand out link keys for that layer. Main character energy 👑

These devices might want AES-CCM as their IKEv2 algorithm too, so they can reuse the hardware that's already doing it 🔥 They can't use AES-CBC, though, because the hardware very often doesn't support the AES decryption that CBC mode needs 💀 So even though AES-CCM needs AEAD [RFC5282] support, reusing the crypto hardware makes AES-CCM the preferred pick. It's giving efficiency 🌸

Another big thing for IoT is that their transfer rates are usually pretty low (like tens of kbit/s 🐢), and every bit they send costs energy and eats into their battery life 🔋 So shorter packets are preferred. This is the reason the doc recommends the 8-octet ICV over the 16-octet ICV 🦋

Since different IoT devices have different constraints, this document can't specify one single mandatory profile for IoT 🙈 Instead, it just points out the algorithms that are commonly used with IoT devices. Honestly, that's the most realistic move 🫶

5. Security Considerations

okay this section is SERIOUS, bestie, so let's pay attention 😤 The security of a cryptographic system depends on BOTH how strong the algorithms are AND how strong the keys are 🔑 It also depends on the protocol engineering, making sure there are no non-cryptographic ways to sneak around the security of the whole system 💀

The Diffie-Hellman Group parameter is the most important one to choose carefully 😭 Anyone who captures ALL the IKE and ESP traffic can, even years later, break the selected DH group in IKE, and then they can get the symmetric keys used to encrypt all the ESP traffic. That's terrifying, so these groups must be chosen very conservatively 🥶 BUT, and this is the plot twist, making a super huge DH group also puts a serious load on the device, especially a big VPN gateway or an IoT-constrained device. So it's a balancing act ⚖️✨

This document is about picking cryptographic algorithms for IKEv2, specifically the "mandatory-to-implement" ones 🎀 The algorithms this document labels "MUST implement" or "SHOULD implement" aren't known to be broken right now, and the cryptographic research so far suggests they'll likely stay secure for the foreseeable future 🔐 However, this isn't necessarily forever 🫠 That's why it's expected that new revisions of this document will come out from time to time, to reflect the current best practice in this area 🌈

6. IANA Considerations

okay so this section is about the registry names 📋 This document renames some entries in the "Transform Type 1 - Encryption Algorithm Transform IDs" registry of the "Internet Key Exchange Version 2 (IKEv2) Parameters" 💅 Right now, all the other names have the ENCR_ prefix except for 3, and all the other entries use uppercase words separated by underscores except for 6. So this document changes those names to match everyone else. It's giving consistency ✨

Per this document, IANA has renamed the following entries for the AES-GCM cipher [RFC4106] and the Camellia cipher [RFC5529]:

+---------------------------------------+----------------------+
| Old name                              | New name             |
+---------------------------------------+----------------------+
| AES-GCM with a 8 octet ICV            | ENCR_AES_GCM_8       |
| AES-GCM with a 12 octet ICV           | ENCR_AES_GCM_12      |
| AES-GCM with a 16 octet ICV           | ENCR_AES_GCM_16      |
| ENCR_CAMELLIA_CCM with an 8-octet ICV | ENCR_CAMELLIA_CCM_8  |
| ENCR_CAMELLIA_CCM with a 12-octet ICV | ENCR_CAMELLIA_CCM_12 |
| ENCR_CAMELLIA_CCM with a 16-octet ICV | ENCR_CAMELLIA_CCM_16 |
+---------------------------------------+----------------------+

IANA also added this RFC as a reference in both the ESP Reference and IKEv2 Reference columns for ENCR_AES_GCM entries, and it kept the existing references there too 📚 For ENCR_CAMELLIA_CCM entries, IANA added this RFC as a reference in the ESP Reference column only, while keeping the existing reference there 🦋

The registry entries currently look like this:

Number Name                  ESP Reference       IKEv2 Reference
...
18     ENCR_AES_GCM_8        [RFC4106][RFC8247]  [RFC5282][RFC8247]
19     ENCR_AES_GCM_12       [RFC4106][RFC8247]  [RFC5282][RFC8247]
20     ENCR_AES_GCM_16       [RFC4106][RFC8247]  [RFC5282][RFC8247]
...
25     ENCR_CAMELLIA_CCM_8   [RFC5529][RFC8247]  -
26     ENCR_CAMELLIA_CCM_12  [RFC5529][RFC8247]  -
27     ENCR_CAMELLIA_CCM_16  [RFC5529][RFC8247]  -

7. References

7.1. Normative References

7.2. Informative References

Acknowledgements

RFC 4307 was authored by Jeffrey I. Schiller of the Massachusetts Institute of Technology (MIT) 🎓 Much of the original text was copied verbatim, which is honestly the most respectful copy-paste ever 🫶

We would like to thank Paul Hoffman, Yaron Sheffer, John Mattsson, Tommy Pauly, Eric Rescorla, and Pete Resnick for their valuable feedback and reviews 💜 The whole crew showed up for this one 🌟

Authors' Addresses

Yoav Nir Dell EMC 9 Andrei Sakharov Street Haifa 3190500 Israel

Email: ynir.ietf@gmail.com

Tero Kivinen

Email: kivinen@iki.fi

Paul Wouters Red Hat

Email: pwouters@redhat.com

Daniel Migault Ericsson 8275 Trans Canada Route Saint-Laurent, QC H4S 0B6 Canada

Phone: +1 514-452-2160 Email: daniel.migault@ericsson.com

📦 where this page comes from