rfc-6989

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

Y. Sheffer, S. Fluhrer
date2013-07 streamIETF areasec wgipsecme statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc6989 doi10.17487/RFC6989
This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2 (IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996.

updates

Extracted elements (23)

design-rationale §2.2

For MODP groups with small subgroups, the NIST SP 800-56A requirement to perform the subgroup test (r^q = 1 mod p) influenced the design: implementations needing NIST conformance must implement this test anyway, so the RFC offers it as a first option alongside the key-non-reuse option for implementations not subject to NIST requirements.

ipsec, crypto

design-rationale §2.1

For Sophie Germain Prime MODP groups, only a range check (1 < r < p-1) is needed because (p-1)/2 being prime means any value in this range is either in the full group or the size-2 subgroup {1, p-1}, and even with reuse this leaks at most one bit of the secret exponent—an amount deemed insignificant.

ipsec, crypto

design-rationale §2.5

The failure behavior in Section 2.5 is designed to balance DoS resistance (not requiring error responses, allowing silent drops) against implementation debuggability (allowing INVALID_SYNTAX notifications). The stricter behavior for CREATE_CHILD_SA failures is justified because those exchanges occur within an authenticated IKE SA, so error notifications can be trusted.

ipsec, security

design-rationale §2

The recipient tests are only REQUIRED for implementations that reuse DH private keys because reuse is what creates the small-subgroup leakage vulnerability; implementations that generate a fresh DH private value per exchange are not vulnerable even without these checks.

ipsec, crypto

interoperability-note §2.4

Existing IKEv2/ECDH implementations that do not reuse DH keys may optionally adopt the EC public key validity tests as sanity checks to prevent the implementation from having to handle inputs it was not designed for, without being required to do so.

ipsec, crypto

normative-requirement §2.4 MUST

ECDH implementations that reuse DH keys MUST be enhanced to include the public-key validity tests defined in this document. Existing non-reusing implementations MAY optionally add these tests as sanity checks.

ipsec, crypto, security

normative-requirement §2.3 MUST

For elliptic curve groups over GF(p) (groups 19, 20, 21, 25–30), a receiving peer MUST check that the peer's public value is valid — specifically that the x and y parameters satisfy the curve equation y^2 = x^3 + ax + b mod p.

ipsec, crypto, security

normative-requirement §2.2 MUST

For MODP groups with small subgroups (RFC 5114 groups 22, 23, 24), an IKE implementation MUST choose one of two options: either check that the peer's public value is in range (1 < r < p-1) AND that r^q = 1 mod p (permitting DH key reuse), or MUST NOT reuse DH private values and MUST check that the public value is in range.

ipsec, crypto, security

normative-requirement §2.1 MUST

For Sophie Germain Prime MODP groups (where (p-1)/2 is also prime), each recipient MUST verify that the peer's public value r is in the legal range (1 < r < p-1). This applies to groups 1, 2, 5, 14, 15, 16, 17, and 18.

ipsec, crypto, security

normative-requirement §5 REQUIRED

Future documents defining new DH groups for IKEv2 are REQUIRED to specify the recipient tests required for each new group, either directly or by reference to this document.

ipsec, registry, security

normative-requirement §2.5 MUST

If a DH public key validation test fails during the IKE_SA_INIT exchange, the recipient MUST drop the message containing the invalid KE payload and MUST NOT use that message when creating the IKE SA.

ipsec, security

normative-requirement §2.5 MUST

If an invalid KE payload is received during CREATE_CHILD_SA (or any post-IKE-SA exchange) in a request, the Responder MUST reply with an INVALID_SYNTAX error notification and drop the IKE SA.

ipsec, security

normative-requirement §2.5 MUST

If an invalid KE payload is received in a CREATE_CHILD_SA response, the Initiator MUST immediately delete the IKE SA by sending an IKE SA Delete notification as a new exchange.

ipsec, security

normative-requirement §2 RECOMMENDED

The group membership tests are RECOMMENDED for all IKEv2 implementations but only REQUIRED for those that reuse DH private keys, as defined in RFC 5996 Section 2.12.

ipsec, crypto, security

protocol-element §2.3

For elliptic curve groups, no check for the point at infinity is needed because IKEv2 (per RFC 5903 Section 7) does not allow encoding that value in a KE payload.

ipsec, crypto

protocol-element §2.2

For MODP groups with small subgroups, the subgroup membership test requires computing r^q mod p = 1, where q is the subgroup size listed in the group's defining RFC. This test is approximately as expensive as the savings from DH key reuse.

ipsec, crypto

protocol-element §2

IKEv2 DH groups are divided into three categories with distinct validation requirements: Sophie Germain Prime MODP groups (range check only), MODP groups with small subgroups (range check plus subgroup membership or no key reuse), and elliptic curve groups over GF(p) (curve equation validation).

ipsec, crypto

registry §5

IANA added a 'Recipient Tests' column to the Transform Type 4 – Diffie-Hellman Group Transform IDs registry for IKEv2. Initial values map groups 1/2/5/14–18 to Section 2.1, groups 22–24 to Section 2.2, and groups 19–21/25–30 to Section 2.3 of this RFC.

ipsec, registry

security-consideration §4.2

DH private key reuse spans multiple risk levels: (1) reuse across connections to different peers is most dangerous, (2) reuse only within a single peer is somewhat less so, and (3) reuse only on failed exchanges (e.g., after INVALID_KE_PAYLOAD) is the most limited. The small-subgroup and timing attacks apply to at least options 1 and 2.

ipsec, crypto, security

security-consideration §4.3

Even-characteristic elliptic curve groups (cofactor > 1) are not addressed by this RFC. Documents defining such groups MUST describe appropriate tests, which may include a subgroup membership test analogous to Section 2.2 or use of ECC CDH to avoid leakage.

ipsec, crypto, security

security-consideration §4.1

If a peer (e.g., Alice) reuses the same ECDH private key across multiple IKE SAs and does not validate received public keys, a malicious peer (Eve) can send a specially crafted invalid public key to efficiently recover Alice's private key via a small-subgroup attack, then derive Alice's shared key with any other peer (Bob).

ipsec, crypto, security

security-consideration §4.4

The INVALID_SYNTAX error notification sent on validation failure leaks no secret information, as all IKEv2 DH groups are publicly known and no test depends on a private key. However, in the IKE_SA_INIT context, the notification is unauthenticated and may have been injected by an attacker for DoS purposes, so the recipient cannot rely on it.

ipsec, security

security-consideration §3

When DH private values are reused, a timing side-channel attack (Kocher, 1996) can recover the exponent. A countermeasure is the blinding factor technique: choose a random group element r, compute r_inv = r^{-1} mod p, then compute A=r·g^y, B=A^x, C=B·r_inv^x = g^{xy}. Blinding is only necessary if the exponent is used more than 100 times.

ipsec, crypto, security