draft-ietf-ipsecme-dh-checks-05.txt   rfc6989.txt 
ipsecme Y. Sheffer Internet Engineering Task Force (IETF) Y. Sheffer
Internet-Draft Porticor Request for Comments: 6989 Porticor
Updates: 5996 (if approved) S. Fluhrer Updates: 5996 S. Fluhrer
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: December 6, 2013 June 4, 2013 ISSN: 2070-1721 July 2013
Additional Diffie-Hellman Tests for IKEv2 Additional Diffie-Hellman Tests
draft-ietf-ipsecme-dh-checks-05 for the Internet Key Exchange Protocol Version 2 (IKEv2)
Abstract Abstract
This document adds a small number of mandatory tests required for the This document adds a small number of mandatory tests required for the
secure operation of IKEv2 with elliptic curve groups. No change is secure operation of the Internet Key Exchange Protocol version 2
required to IKE implementations that use modular exponential groups, (IKEv2) with elliptic curve groups. No change is required to IKE
other than a few rarely used so-called DSA groups. This document implementations that use modular exponential groups, other than a few
updates the IKEv2 protocol, RFC 5996. rarely used so-called Digital Signature Algorithm (DSA) groups. This
document updates the IKEv2 protocol, RFC 5996.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 6, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6989.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Conventions used in this document . . . . . . . . . . 3 1.1. Conventions Used in This Document ..........................3
2. Group Membership Tests . . . . . . . . . . . . . . . . 3 2. Group Membership Tests ..........................................3
2.1. Sophie Germain Prime MODP Groups . . . . . . . . . . . 3 2.1. Sophie Germain Prime MODP Groups ...........................3
2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 4 2.2. MODP Groups with Small Subgroups ...........................3
2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4 2.3. Elliptic Curve Groups ......................................4
2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Transition .................................................4
2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5 2.5. Protocol Behavior ..........................................5
3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6 3. Side-Channel Attacks ............................................5
4. Security Considerations . . . . . . . . . . . . . . . 6 4. Security Considerations .........................................6
4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 7 4.1. DH Key Reuse and Multiple Peers ............................6
4.2. DH Key Reuse: Variants . . . . . . . . . . . . . . . . 7 4.2. DH Key Reuse: Variants .....................................7
4.3. Groups not covered by this RFC . . . . . . . . . . . . 7 4.3. Groups Not Covered by This RFC .............................7
4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 8 4.4. Behavior upon Test Failure .................................7
5. IANA Considerations . . . . . . . . . . . . . . . . . 8 5. IANA Considerations .............................................8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements ................................................8
7. References . . . . . . . . . . . . . . . . . . . . . . 9 7. References ......................................................9
7.1. Normative References . . . . . . . . . . . . . . . . . 9 7.1. Normative References .......................................9
7.2. Informative References . . . . . . . . . . . . . . . . 9 7.2. Informative References .....................................9
Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10
A.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IKEv2 [RFC5996] consists of the establishment of a shared secret IKEv2 [RFC5996] consists of the establishment of a shared secret
using the Diffie-Hellman (DH) protocol, followed by authentication of using the Diffie-Hellman (DH) protocol, followed by authentication of
the two peers. Existing implementations typically use modular the two peers. Existing implementations typically use modular
exponential (MODP) DH groups, such as those defined in [RFC3526]. exponential (MODP) DH groups, such as those defined in [RFC3526].
IKEv2 does not require that any tests be performed by a peer IKEv2 does not require that any tests be performed by a peer
receiving a public Diffie-Hellman key from the other peer. This is receiving a public Diffie-Hellman key from the other peer. This is
fine for the common case of MODP groups. For other DH groups, when fine for the common case of MODP groups. For other DH groups, when
peers reuse DH values across multiple IKE sessions, the lack of tests peers reuse DH values across multiple IKE sessions, the lack of tests
by the recipient results in a potential vulnerability (see by the recipient results in a potential vulnerability (see
Section 4.1 for more details). In particular, this is true for Section 4.1 for more details). In particular, this is true for
Elliptic Curve (EC) groups whose use is becoming ever more popular. Elliptic Curve (EC) groups, whose use is becoming ever more popular.
This document defines such tests for several types of DH groups. This document defines such tests for several types of DH groups.
In addition, this document describes another potential attack related In addition, this document describes another potential attack related
to reuse of DH keys: a timing attack. This additional material is to the reuse of DH keys: a timing attack. This additional material
taken from [RFC2412]. is taken from [RFC2412].
This document updates [RFC5996] by adding security requirements that This document updates [RFC5996] by adding security requirements that
apply to many of the protocol's implementations. apply to many of the protocol's implementations.
1.1. Conventions used in this document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Group Membership Tests 2. Group Membership Tests
This section describes the tests that need to be performed by IKE This section describes the tests that need to be performed by IKE
peers receiving a Key Exchange (KE) payload. The tests are peers receiving a Key Exchange (KE) payload. The tests are
RECOMMENDED for all implementations, but only REQUIRED for those that RECOMMENDED for all implementations but only REQUIRED for those that
reuse DH private keys (as defined in [RFC5996], Sec. 2.12). The reuse DH private keys (as defined in [RFC5996], Section 2.12). The
tests apply to the recipient of a KE payload, and describe how it tests apply to the recipient of a KE payload and describe how it
should check the received payload. They are listed here according to should check the received payload. They are listed here according to
the DH group being used. the DH group being used.
2.1. Sophie Germain Prime MODP Groups 2.1. Sophie Germain Prime MODP Groups
These are currently the most commonly used groups; all these groups These are currently the most commonly used groups; all these groups
have the property that (p-1)/2 is also prime; this section applies to have the property that (p-1)/2 is also prime; this section applies to
any such MODP group. Each recipient MUST verify that the peer's any such MODP group. Each recipient MUST verify that the peer's
public value r is in the legal range (1 < r < p-1). According to public value r is in the legal range (1 < r < p-1). According to
[Menezes], Sec 2.2, even with this check there remains the [Menezes], Section 2.2, even with this check there remains the
possibility of leaking a single bit of the secret exponent when DH possibility of leaking a single bit of the secret exponent when DH
keys are reused; this amount of leakage is insignificant. keys are reused; this amount of leakage is insignificant.
See Section 5 for the specific groups covered by this section. See Section 5 for the specific groups covered by this section.
2.2. MODP Groups with Small Subgroups 2.2. MODP Groups with Small Subgroups
[RFC5114] defines modular exponential groups with small subgroups; [RFC5114] defines modular exponential groups with small subgroups;
these are modular exponential groups with comparatively small these are modular exponential groups with comparatively small
subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes] subgroups, and all have (p-1)/2 composite. Section 2.1 of [Menezes]
describes some informational leakage from a small subgroup attack on describes some informational leakage from a small-subgroup attack on
these groups, if the DH private value is reused. these groups if the DH private value is reused.
This leakage can be prevented if the recipient performs a test on the This leakage can be prevented if the recipient performs a test on the
peer's public value, however this test is expensive (approximately as peer's public value; however, this test is expensive (approximately
expensive as what reusing DH private values saves). In addition, the as expensive as what reusing DH private values saves). In addition,
NIST standard [NIST-800-56A] requires that test (see section the NIST standard ([NIST-800-56A], Section 5.6.2.4) requires that
5.6.2.4), hence anyone needing to conform to that standard will need test; hence, anyone needing to conform to that standard will need to
to implement the test anyway. implement the test anyway.
Because of the above, the IKE implementation MUST choose between one Because of the above, the IKE implementation MUST choose between one
of the following two options: of the following two options:
o It MUST check both that the peer's public value is in range (1 < r o 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 < p-1) and that r^q = 1 mod p (where q is the size of the
subgroup, as listed in the RFC). DH private values MAY then be subgroup, as listed in the RFC defining the group). DH private
reused. This option is appropriate if conformance to values MAY then be reused. This option is appropriate if
[NIST-800-56A] is required. conformance to [NIST-800-56A] is required.
o It MUST NOT reuse DH private values (that is, the DH private value o 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 for each DH exchange MUST be generated from a fresh output of a
cryptographically secure random number generator), and it MUST cryptographically secure random number generator), and it MUST
check that the peer's public value is in range (1 < r < p-1). 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] This option is more appropriate if conformance to [NIST-800-56A]
is not required. is not required.
See Section 5 for the specific groups covered by this section. See Section 5 for the specific groups covered by this section.
2.3. Elliptic Curve Groups 2.3. Elliptic Curve Groups
IKEv2 can be used with elliptic curve groups defined over a field IKEv2 can be used with elliptic curve groups defined over a field
GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there GF(p) [RFC5903] [RFC5114]. According to [Menezes], Section 2.3,
is some informational leakage possible. A receiving peer MUST check there is some informational leakage possible. A receiving peer MUST
that its peer's public value is valid; that is, the x and y check that its peer's public value is valid; that is, the x and y
parameters from the peer's public value satisfy the curve equation, parameters from the peer's public value satisfy the curve equation,
y^2 = x^3 + ax + b mod p (where for groups 19, 20, 21, a=-3 (mod p), y^2 = x^3 + ax + b mod p (where for groups 19, 20, and 21, a=-3 (mod
and all other values of a, b and p for the group are listed in the p), and all other values of a, b, and p for the group are listed in
RFC). the RFC defining the group).
We note that an additional check to ensure that the public value is We note that an additional check to ensure that the public value is
not the point at infinity is not needed, because IKE (in Sec. 7 of not the point at infinity is not needed, because IKE (see Section 7
[RFC5903]) does not allow for encoding this value. of [RFC5903]) does not allow for encoding this value.
See Section 5 for the specific groups covered by this section. See Section 5 for the specific groups covered by this section.
2.4. Transition 2.4. Transition
Existing implementations of IKEv2 with ECDH groups may be modified to Existing implementations of IKEv2 with Elliptic Curve Diffie-Hellman
include the tests described in the current document, even if they do (ECDH) groups may be modified to include the tests described in the
not reuse DH keys. The tests can be considered as sanity checks, and current document, even if they do not reuse DH keys. The tests can
will prevent the code having to handle inputs that it may not have be considered as sanity checks and will prevent the code having to
been designed to handle. handle inputs that it may not have been designed to handle.
ECDH implementations that do reuse DH keys MUST be enhanced to ECDH implementations that do reuse DH keys MUST be enhanced to
include the above tests. include the above tests.
2.5. Protocol Behavior 2.5. Protocol Behavior
The recipient of a DH public key that fails one of the above tests The recipient of a DH public key that fails one of the above tests
must assume that the sender is either truly malicious or else it has must assume that the sender is either truly malicious or has a bug in
a bug in its implementation. The behavior defined below attempts to its implementation. The behavior defined below attempts to balance
balance resistance to attackers that are trying to disrupt the IKE resistance to attackers that are trying to disrupt the IKE exchange,
exchange, against the need to help a badly implemented peer by against the need to help a badly implemented peer by providing useful
providing useful error indications. error indications.
If this error happens during the IKE_SA_INIT exchange, then the If this error happens during the IKE_SA_INIT exchange, then the
recipient MUST drop the message that contains an invalid KE payload, recipient MUST drop the message that contains an invalid KE payload
and MUST NOT use that message when creating the IKE SA. and MUST NOT use that message when creating the IKE security
association (SA).
If the implementation implements the DoS-resistant behavior proposed If the implementation employs the DoS-resistant behavior proposed in
in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request Section 2.4 of [RFC5996], it may simply ignore the erroneous request
or response message, and continue waiting for a later message or response message, and continue waiting for a later message
containing a legitimate KE payload. containing a legitimate KE payload.
If DoS-resistant behavior is not implemented, and the invalid KE If DoS-resistant behavior is not implemented and the invalid KE
payload was in the IKE_SA_INIT request, the implementation MAY send payload was in the IKE_SA_INIT request, the implementation MAY send
an INVALID_SYNTAX error notification back, and remove the in-progress 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, 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, then the implementation MAY simply delete the half-created IKE SA and
and re-initiate the exchange. re-initiate the exchange.
If the invalid KE payload is received during the CREATE_CHILD_SA If the invalid KE payload is received during the CREATE_CHILD_SA
exchange (or any other exchange after the IKE SA has been exchange (or any other exchange after the IKE SA has been
established) and the invalid KE payload is in the request message, established) and the invalid KE payload is in the request message,
the Responder MUST reply with an INVALID_SYNTAX error notification 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 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 Initiator getting this reply MUST immediately delete the IKE SA by
sending an IKE SA Delete notification as a new exchange. In this sending an IKE SA Delete notification as a new exchange. In this
case the sender evidently has an implementation bug, and dropping the case, the sender evidently has an implementation bug, and dropping
IKE SA makes it easier to detect. the IKE SA makes it easier to detect.
3. Side-Channel Attacks 3. Side-Channel Attacks
In addition to the small-subgroup attack, there is also a potential In addition to the small-subgroup attack, there is also a potential
timing attack on IKE peers when they are reusing Diffie-Hellman timing attack on IKE peers when they are reusing Diffie-Hellman
secret values. This is a side-channel attack, which means that it secret values. This is a side-channel attack, which means that it
may or may not be a vulnerability in certain cases, depending on may or may not be a vulnerability in certain cases, depending on
implementation details and the threat model. implementation details and the threat model.
The remainder of this section is quoted from [RFC2412], Sec. 5, with The remainder of this section is quoted from [RFC2412], Section 5,
a few minor clarifications. This attack still applies to IKEv2 with a few minor clarifications. This attack still applies to IKEv2
implementations, and both to MODP groups and ECDH groups. We also implementations, and both to MODP groups and ECDH groups. We also
note that more efficient countermeasures are available for EC groups note that more efficient countermeasures are available for EC groups
represented in projective form, but these are outside the scope of represented in projective form, but these are outside the scope of
the current document. the current document.
Timing attacks that are capable of recovering the exponent value used Timing attacks that are capable of recovering the exponent value used
in Diffie-Hellman calculations have been described by Paul Kocher in Diffie-Hellman calculations have been described by Paul Kocher
[Kocher]. In order to nullify the attack, implementors must take [Kocher]. In order to nullify the attack, implementors must take
pains to obscure the sequence of operations involved in carrying out pains to obscure the sequence of operations involved in carrying out
modular exponentiations. modular exponentiations.
One potential method to foil these timing attacks is to use a One potential method to foil these timing attacks is to use a
"blinding factor". In this method, a group element, r, is chosen at "blinding factor". In this method, a group element, r, is chosen at
random, and its multiplicative inverse modulo p is computed, which random, and its multiplicative inverse modulo p is computed, which
we'll call r_inv. r_inv can be computed by the Extended Euclidean we'll call r_inv. r_inv can be computed by the Extended Euclidean
Method, using r and p as inputs. When an exponent x is chosen, the 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, value r_inv^x is also calculated. Then, when calculating (g^y)^x,
the implementation will calculate this sequence: the implementation will calculate this sequence:
A = r*g^y A = r*g^y
B = A^x = (r*g^y)^x = (r^x)(g^(xy)) 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) 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 The blinding factor is only necessary if the exponent x is used more
than 100 times (estimate by Richard Schroeppel). than 100 times.
4. Security Considerations 4. Security Considerations
This entire document is concerned with the IKEv2 security protocol This entire document is concerned with the IKEv2 security protocol
and the need to harden it in some cases. and the need to harden it in some cases.
4.1. DH Key Reuse and Multiple Peers 4.1. DH Key Reuse and Multiple Peers
This section describes one variant of the attack prevented by the This section describes one variant of the attack prevented by the
tests defined above. tests defined above.
Suppose that IKE peer Alice maintains IKE security associations with Suppose that IKE peer Alice maintains IKE security associations with
peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 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 which is allowed with some restrictions. If Alice does not implement
these tests, Eve will be able to send a malformed public key, which these tests, Eve will be able to send a malformed public key, which
would allow her to efficiently determine Alice's private key (as would allow her to efficiently determine Alice's private key (as
described in Sec. 2 of [Menezes]). Since the key is shared, Eve will described in Section 2 of [Menezes]). Since the key is shared, Eve
be able to obtain Alice's shared IKE SA key with Bob. will be able to obtain Alice's shared IKE SA key with Bob.
4.2. DH Key Reuse: Variants 4.2. DH Key Reuse: Variants
Private DH keys can be reused in different ways, with subtly Private DH keys can be reused in different ways, with subtly
different security implications. For example: different security implications. For example:
1. DH keys are reused for multiple connections (IKE SAs) to the same 1. DH keys are reused for multiple connections (IKE SAs) to the same
peer, and for connections to different peers. peer and for connections to different peers.
2. DH keys are reused for multiple connections to the same peer 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 (e.g., when the peer is identified by its IP address) but not for
different peers. different peers.
3. DH keys are reused only when they had not been used to complete 3. DH keys are reused only when they had not been used to complete
an exchange, e.g. when the peer replies with an an exchange, e.g., when the peer replies with an
INVALID_KE_PAYLOAD notification. INVALID_KE_PAYLOAD notification.
Both the small subgroup attack and the timing attack described in Both the small-subgroup attack and the timing attack described in
this document apply at least to options #1 and #2. this document apply at least to options #1 and #2.
4.3. Groups not covered by this RFC 4.3. Groups Not Covered by This RFC
There are a number of group types that are not specifically addressed There are a number of group types that are not specifically addressed
by this RFC. A document that defines such a group MUST describe the by this RFC. A document that defines such a group MUST describe the
tests required by that group. tests required by that group.
One specific type of group would be an even-characteristic elliptic One specific type of group would be an even-characteristic elliptic
curve group. Now, these curves have cofactors greater than 1; this curve group. Now, these curves have cofactors greater than 1; this
leads to a possibility of some information leakage. There are leads to a possibility of some information leakage. There are
several ways to address this information leakage, such as performing several ways to address this information leakage, such as performing
a test analogous to the test in section 2.2, or adjusting the ECDH a test analogous to the test in Section 2.2 or adjusting the ECDH
operation to avoid this leakage (such as "ECC CDH", where the shared operation to avoid this leakage (such as Elliptic Curve Cryptography
secret really is hxyG). Because the appropriate test depends on how Cofactor Diffie-Hellman (ECC CDH), where the shared secret really is
the group is defined, we cannot document it in advance. hxyG). Because the appropriate test depends on how the group is
defined, we cannot document it in advance.
4.4. Behavior Upon Test Failure 4.4. Behavior upon Test Failure
The behavior recommended in Section 2.5 is in line with generic error The behavior recommended in Section 2.5 is in line with generic error
treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. treatment during the IKE_SA_INIT exchange, per Section 2.21.1 of
The sender is not required to send back an error notification, and [RFC5996]. The sender is not required to send back an error
the recipient cannot depend on this notification because it is notification, and the recipient cannot depend on this notification
unauthenticated, and may in fact have been sent by an attacker trying because it is unauthenticated and may in fact have been sent by an
to DoS the connection. Thus, the notification is only useful to attacker trying to launch a DoS attack on the connection. Thus, the
debug implementation errors. notification is only useful to debug implementation errors.
On the other hand, the error notification is secure in the sense that On the other hand, the error notification is secure in the sense that
no secret information is leaked. All IKEv2 Diffie-Hellman groups are no secret information is leaked. All IKEv2 Diffie-Hellman groups are
publicly known, and none of the tests defined here depend on any publicly known, and none of the tests defined here depend on any
private key. In fact the tests can all be performed by an private key. In fact, the tests can all be performed by an
eavesdropper. eavesdropper.
The situation when the failure occurs in the Create Child SA exchange The situation when the failure occurs in the CREATE_CHILD_SA exchange
is different, since everything is protected by an IKE SA. The peers is different, since everything is protected by an IKE SA. The peers
are authenticated, and error notifications can be relied on. See are authenticated, and error notifications can be relied on. See
Sec. 2.21.3 of [RFC5996] for more details on error handling in this Section 2.21.3 of [RFC5996] for more details on error handling in
case. this case.
5. IANA Considerations 5. IANA Considerations
This document requests that IANA should add a column named "Recipient IANA has added a column named "Recipient Tests" to the Transform
Tests" to the IKEv2 DH Group Transform IDs Registry Type 4 - Diffie-Hellman Group Transform IDs registry for IKEv2
[IANA-DH-Registry]. [IANA-IKEv2-Registry].
This column should initially be populated as per the following table.
+------------------------------------+---------------------+ This column has been initially populated as follows.
| Number | Recipient Tests |
+------------------------------------+---------------------+
| 1, 2, 5, 14, 15, 16, 17, 18 | [current], Sec. 2.1 |
| 22, 23, 24 | [current], Sec. 2.2 |
| 19, 20, 21, 25, 26, 27, 28, 29, 30 | [current], Sec. 2.3 |
+------------------------------------+---------------------+
Note to RFC Editor: please replace [current] by the RFC number +------------------------------------+-----------------------+
assigned to this document. | 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 have been recently defined in Groups 27-30 are defined in [RFC6954].
[I-D.merkle-ikev2-ke-brainpool].
Future documents that define new DH groups for IKEv2 are REQUIRED to Future documents that define new DH groups for IKEv2 are REQUIRED to
provide this information for each new group, possibly by referring to provide this information for each new group, possibly by referring to
the current document. the current document.
6. Acknowledgements 6. Acknowledgements
We would like to thank Dan Harkins who initially raised this issue on We would like to thank Dan Harkins, who initially raised this issue
the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for on the IPsec mailing list. Thanks to Tero Kivinen and Rene Struik
their useful comments. Much of the text in Section 3 is taken from for their useful comments. Much of the text in Section 3 is taken
[RFC2412] and we would like to thank its author, Hilarie Orman. from [RFC2412], and we would like to thank its author, Hilarie Orman.
The document was prepared using the lyx2rfc tool, created by Nico The document was originally prepared using the lyx2rfc tool, created
Williams. by Nico Williams.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
7.2. Informative References 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", [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114, Groups for Use with IETF Standards", RFC 5114,
January 2008. January 2008.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
June 2010. June 2010.
[I-D.merkle-ikev2-ke-brainpool] [RFC6954] Merkle, J. and M. Lochter, "Using the Elliptic Curve
Merkle, J. and M. Lochter, "Using the ECC Brainpool Curves Cryptography (ECC) Brainpool Curves for the Internet Key
for IKEv2 Key Exchange", Exchange Protocol Version 2 (IKEv2)", RFC 6954, July 2013.
draft-merkle-ikev2-ke-brainpool-06 (work in progress),
April 2013.
[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.
[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, <h
ttp://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>.
[IANA-DH-Registry]
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Type 4 - Diffie-Hellman Group Transform IDs",
Jan. 2005, <http://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-8>.
Appendix A. Appendix: Change Log
Note to RFC Editor: please remove this section before publication.
A.1. -05
o Resolved IESG members' comments.
A.2. -04
o Implemented Sean's AD review, and removed the inapplicable
requirement on the point at infinity.
A.3. -03
o Added the Brainpool curves to the IANA registration table.
A.4. -02
o Based on Tero's review: Improved the protocol behavior, and
mentioned that these checks apply to Create Child SA. Added a
discussion of DH timing attacks, stolen from RFC 2412.
A.5. -01
o Corrected an author's name that was misspelled.
o Added recipient behavior if a test fails, and the related security
considerations.
A.6. -00
o First WG document.
o Clarified IANA actions.
o Discussion of potential future groups not covered here.
o Clarification re: practicality of recipient tests for DSA groups.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Porticor Porticor
10 Yirmiyahu St.
Ramat HaSharon 47298
Israel
Email: yaronf.ietf@gmail.com EMail: yaronf.ietf@gmail.com
Scott Fluhrer Scott Fluhrer
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: sfluhrer@cisco.com EMail: sfluhrer@cisco.com
 End of changes. 55 change blocks. 
213 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/