RFC 6989

Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)

📅 published July 2013, from ietf

RFC 6989: Additional Diffie-Hellman Tests for IKEv2 🎀

okay bestie, let's get the basics out of the way first 💅

  • Who wrote it: Y. Sheffer (Porticor) and S. Fluhrer (Cisco) 🫶
  • Where it came from: the Internet Engineering Task Force (IETF) 🌸
  • Category: Standards Track, so it's an official Internet Standard ✨
  • Date: July 2013 🦋
  • ISSN: 2070-1721
  • Updates: 5996, which is RFC 5996, the IKEv2 protocol itself 🔐

Abstract 🌈

okay so this doc adds a small number of mandatory tests that IKEv2 needs to stay secure when it uses elliptic curve groups 😤 MODP groups don't need any changes, except a few rarely used so-called Digital Signature Algorithm (DSA) groups 🙈 This doc updates the IKEv2 protocol, RFC 5996.

Status of This Memo 📜

This is an Internet Standards Track document. 💖

This document is a product of the IETF. It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741. For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6989.

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 📚

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Group Membership Tests ..........................................3
      2.1. Sophie Germain Prime MODP Groups ...........................3
      2.2. MODP Groups with Small Subgroups ...........................3
      2.3. Elliptic Curve Groups ......................................4
      2.4. Transition .................................................4
      2.5. Protocol Behavior ..........................................5
   3. Side-Channel Attacks ............................................5
   4. Security Considerations .........................................6
      4.1. DH Key Reuse and Multiple Peers ............................6
      4.2. DH Key Reuse: Variants .....................................7
      4.3. Groups Not Covered by This RFC .............................7
      4.4. Behavior upon Test Failure .................................7
   5. IANA Considerations .............................................8
   6. Acknowledgements ................................................8
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References .....................................9

1. Introduction ✨

okay so IKEv2 [RFC5996] has two main steps: the peers first agree on a shared secret using the Diffie-Hellman (DH) protocol, and then they authenticate each other 🤝 Existing implementations usually use modular exponential (MODP) DH groups, like the ones defined in [RFC3526].

here's the tea 🫖 IKEv2 doesn't require a peer that receives a public Diffie-Hellman key from the other peer to run any tests. That's fine for the common case of MODP groups 👌 But for other DH groups, when peers reuse DH values across multiple IKE sessions, skipping those tests creates a potential vulnerability (see Section 4.1 for more details). This is especially true for Elliptic Curve (EC) groups, which are getting more and more popular 📈 This document defines those tests for several types of DH groups.

This document also covers another attack related to reusing DH keys: a timing attack ⏱️ This extra material is taken from [RFC2412].

This document updates [RFC5996] by adding security requirements that apply to many of the protocol's implementations 🔒

1.1. Conventions Used in This Document 🧐

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Group Membership Tests 🫧

This section describes the tests that IKE peers need to run when they receive a Key Exchange (KE) payload. The tests are RECOMMENDED for all implementations 💫 but only REQUIRED for the ones that reuse DH private keys (as defined in [RFC5996], Section 2.12). The tests apply to the recipient of a KE payload, and they explain how it should check the payload it got. They're listed according to the DH group being used.

2.1. Sophie Germain Prime MODP Groups 👑

These are the most commonly used groups right now. All of them have the property that (p-1)/2 is also prime, and this section applies to any MODP group like that. Each recipient MUST verify that the peer's public value r is in the legal range (1 < r < p-1). According to [Menezes], Section 2.2, even with this check there's still a chance of leaking a single bit of the secret exponent when DH keys get reused, but that amount of leakage is insignificant 🤏

See Section 5 for the specific groups covered by this section.

2.2. MODP Groups with Small Subgroups 🐣

[RFC5114] defines modular exponential groups with small subgroups. These are MODP groups with comparatively small subgroups, and all of them have (p-1)/2 composite. Section 2.1 of [Menezes] describes some informational leakage from a small-subgroup attack on these groups if the DH private value is reused.

This leakage can be prevented if the recipient performs a test on the peer's public value. The catch is that this test is expensive, roughly as expensive as what reusing DH private values saves 💸 On top of that, the NIST standard ([NIST-800-56A], Section 5.6.2.4) requires that test, so anyone who needs to conform to that standard will have to implement it anyway.

So because of all that, the IKE implementation MUST choose between one of the following two options:

  • It MUST check both that the peer's public value is in range (1 < r < p-1) and that r^q = 1 mod p (where q is the size of the subgroup, as listed in the RFC defining the group). DH private values MAY then be reused. This option is appropriate if conformance to [NIST-800-56A] is required.
  • It MUST NOT reuse DH private values (that is, the DH private value for each DH exchange MUST be generated from a fresh output of a cryptographically secure random number generator), and it MUST check that the peer's public value is in range (1 < r < p-1). This option is more appropriate if conformance to [NIST-800-56A] is not required.

See Section 5 for the specific groups covered by this section.

2.3. Elliptic Curve Groups ⭐

IKEv2 can be used with elliptic curve groups defined over a field GF(p) [RFC5903] [RFC5114]. According to [Menezes], Section 2.3, some informational leakage is possible. A receiving peer MUST check that its peer's public value is valid. In other words, the x and y parameters from the peer's public value have to satisfy the curve equation, y^2 = x^3 + ax + b mod p (where for groups 19, 20, and 21, a=-3 (mod p), and all other values of a, b, and p for the group are listed in the RFC defining the group).

We note that you don't need an extra check to make sure the public value isn't the point at infinity 🙅 IKE (see Section 7 of [RFC5903]) doesn't allow that value to be encoded at all, so there's nothing to check.

See Section 5 for the specific groups covered by this section.

2.4. Transition 🦋

Existing IKEv2 implementations with Elliptic Curve Diffie-Hellman (ECDH) groups can be modified to include the tests in this document, even if they don't reuse DH keys. The tests can be treated as sanity checks, and they keep the code from having to handle inputs it may not have been designed to handle 🧹

ECDH implementations that do reuse DH keys MUST be enhanced to include the above tests.

2.5. Protocol Behavior 💌

The recipient of a DH public key that fails one of the above tests must assume that the sender is either truly malicious or has a bug in its implementation. The behavior defined below tries to balance two things: resisting attackers who are trying to disrupt the IKE exchange, and helping a badly implemented peer by giving useful error indications 🥹

If this error happens during the IKE_SA_INIT exchange, then the recipient MUST drop the message that contains an invalid KE payload, and it MUST NOT use that message when creating the IKE security association (SA) 🚫

If the implementation uses the DoS-resistant behavior proposed in Section 2.4 of [RFC5996], it may simply ignore the erroneous request or response message and keep waiting for a later message that contains a legitimate KE payload.

If DoS-resistant behavior is not implemented and the invalid KE payload was in the IKE_SA_INIT request, the implementation MAY send an INVALID_SYNTAX error notification back and remove the in-progress IKE SA. If the invalid KE payload was in the IKE_SA_INIT response, then the implementation MAY simply delete the half-created IKE SA and re-initiate the exchange.

If the invalid KE payload is received during the CREATE_CHILD_SA exchange (or any other exchange after the IKE SA has been established) and the invalid KE payload is in the request message, the Responder MUST reply with an INVALID_SYNTAX error notification and drop the IKE SA. If the invalid KE payload is in a response, the Initiator getting this reply MUST immediately delete the IKE SA by sending an IKE SA Delete notification as a new exchange. In this case, the sender clearly has an implementation bug, and dropping the IKE SA makes that bug easier to detect 🔍✨

3. Side-Channel Attacks ✨

okay so besides the small-subgroup attack, there's ALSO a timing attack that can hit IKE peers when they reuse their Diffie-Hellman secret values 👀. this is a side-channel attack, which basically means it might or might not be a real vulnerability 💅, depending on the implementation details and the threat model. it's giving "it depends" energy 🙈

the rest of this section is quoted from [RFC2412], Section 5, with a few minor clarifications 🎀. this attack still applies to IKEv2 implementations, and it hits both MODP groups and ECDH groups 😭. we also note that more efficient countermeasures exist for EC groups in projective form 🦋, but those are outside the scope of this document, so we're not going there today 🫶

timing attacks that can recover the exponent used in Diffie-Hellman calculations were described by Paul Kocher [Kocher] 🔥. to nullify the attack, implementors MUST take pains to obscure the sequence of operations involved in carrying out modular exponentiations 💖. wait, correction: the original says "must take pains," so the requirement here is lowercase in the source, and I'm keeping it exactly that way, no upgrades ✨

one potential way to foil these timing attacks is a "blinding factor" 🧚. here's the vibe: pick a group element, r, at random, then compute its multiplicative inverse modulo p, which we'll call r_inv 🌸. you can get r_inv with the Extended Euclidean Method, using r and p as inputs 🍓. when an exponent x is chosen, the value r_inv^x is also calculated. then, when calculating (g^y)^x, the implementation runs this sequence:

   A = r*g^y
   B = A^x = (r*g^y)^x = (r^x)(g^(xy))
   C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy)

the blinding factor is only necessary if the exponent x is used more than 100 times 💅. that's the whole plot 💀

4. Security Considerations 🩷

this entire document is concerned with the IKEv2 security protocol and the need to harden it in some cases 👑. it's literally the main character of this whole RFC 🎀

4.1. DH Key Reuse and Multiple Peers 🌈

this section describes one variant of the attack prevented by the tests defined above 😭.

picture this: IKE peer Alice keeps IKE security associations with peers Bob and Eve 🙈. Alice uses the same secret ECDH key for both SAs, which is allowed with some restrictions 💅. if Alice does not implement these tests, Eve can send a malformed public key, and that would let her efficiently determine Alice's private key (as described in Section 2 of [Menezes]) 💀. since the key is shared, Eve can also get Alice's shared IKE SA key with Bob 😱. not okay!! 🚨

4.2. DH Key Reuse: Variants 🦋

private DH keys can be reused in different ways, and each one has subtly different security implications 🔮. for example:

  1. DH keys are reused for multiple connections (IKE SAs) to the same peer and for connections to different peers 💖.
  2. DH keys are reused for multiple connections to the same peer (e.g., when the peer is identified by its IP address) but not for different peers 🌸.
  3. DH keys are reused only when they had not been used to complete an exchange, e.g., when the peer replies with an INVALID_KE_PAYLOAD notification 🧚.

both the small-subgroup attack and the timing attack described in this document apply at least to options #1 and #2 🫶. so those two are the ones to watch out for, periodt 💅

4.3. Groups Not Covered by This RFC 🎀

there are a number of group types that this RFC doesn't specifically address 🌈. a document that defines such a group MUST describe the tests required by that group ✨.

one specific type would be an even-characteristic elliptic curve group 🔥. these curves have cofactors greater than 1, which creates a possibility of some information leakage 😬. there are several ways to address that leakage, such as performing a test analogous to the test in Section 2.2, or adjusting the ECDH operation so the leakage doesn't happen (like Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH), where the shared secret really is hxyG) 🦋. since the right test depends on how the group is defined, we can't document it in advance 🙃

4.4. Behavior upon Test Failure 🙈

the behavior recommended in Section 2.5 lines up with generic error treatment during the IKE_SA_INIT exchange, per Section 2.21.1 of [RFC5996] 💅. the sender is not required to send back an error notification 💁. the recipient can't depend on that notification either, because it's unauthenticated and may have been sent by an attacker trying to launch a DoS attack on the connection 😤. so the notification is only really useful for debugging implementation errors 🔧

on the other hand, the error notification is secure in the sense that no secret information leaks 🔐. all IKEv2 Diffie-Hellman groups are publicly known, and none of the tests defined here depend on any private key 🌸. in fact, anyone eavesdropping can perform the tests 👀

the situation is different when the failure happens in the CREATE_CHILD_SA exchange, since everything is protected by an IKE SA 🛡️. the peers are authenticated there, so error notifications can be relied on 💖. see Section 2.21.3 of [RFC5996] for more details on error handling in this case ✨

5. IANA Considerations 📋

IANA has added a column named "Recipient Tests" to the Transform Type 4 - Diffie-Hellman Group Transform IDs registry for IKEv2 [IANA-IKEv2-Registry] 🎀

this column was initially populated as follows 🌈:

   +------------------------------------+-----------------------+
   |               Number               |    Recipient Tests    |
   +------------------------------------+-----------------------+
   |     1, 2, 5, 14, 15, 16, 17, 18    | RFC 6989, Section 2.1 |
   |             22, 23, 24             | RFC 6989, Section 2.2 |
   | 19, 20, 21, 25, 26, 27, 28, 29, 30 | RFC 6989, Section 2.3 |
   +------------------------------------+-----------------------+

groups 27-30 are defined in [RFC6954] 🧚

future documents that define new DH groups for IKEv2 are REQUIRED to provide this information for each new group, possibly by referring to the current document 💅. no skipping this step, bestie 🫶

6. Acknowledgements 💜

we'd like to thank Dan Harkins, who first raised this issue on the IPsec mailing list 🙌. thanks to Tero Kivinen and Rene Struik for their useful comments 🌸. much of the text in Section 3 is taken from [RFC2412], and we'd like to thank its author, Hilarie Orman 🦋

the document was originally prepared using the lyx2rfc tool, created by Nico Williams ✨

7. References 📚

7.1. Normative References 🔥

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

7.2. Informative References 🌈

[IANA-IKEv2-Registry] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters/>.

[Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie- Hellman, RSA, DSS, and Other Systems", December 1996, <http://www.cryptography.com/timingattack/paper.html>.

[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols", December 2008, <http://www.cacr.math.uwaterloo.ca/techreports/2008/ cacr2008-24.pdf>.

[NIST-800-56A] National Institute of Standards and Technology (NIST), "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST PUB 800-56A, March 2007.

[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.

[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.

[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.

[RFC6954] Merkle, J. and M. Lochter, "Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6954, July 2013.

Authors' Addresses 🫶

Yaron Sheffer
Porticor

EMail: yaronf.ietf@gmail.com


Scott Fluhrer
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

EMail: sfluhrer@cisco.com
📦 where this page comes from