draft-ietf-ipsecme-dh-checks-04.txt   draft-ietf-ipsecme-dh-checks-05.txt 
ipsecme Y. Sheffer ipsecme Y. Sheffer
Internet-Draft Porticor Internet-Draft Porticor
Updates: 5996 (if approved) S. Fluhrer Updates: 5996 (if approved) S. Fluhrer
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: November 5, 2013 May 4, 2013 Expires: December 6, 2013 June 4, 2013
Additional Diffie-Hellman Tests for IKEv2 Additional Diffie-Hellman Tests for IKEv2
draft-ietf-ipsecme-dh-checks-04 draft-ietf-ipsecme-dh-checks-05
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 IKEv2 with elliptic curve groups. No change is
required to IKE implementations that use modular exponential groups, required to IKE implementations that use modular exponential groups,
other than a few rarely used so-called DSA groups. This document other than a few rarely used so-called DSA groups. This document
updates the IKEv2 protocol, RFC 5996. updates the IKEv2 protocol, RFC 5996.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 5, 2013. This Internet-Draft will expire on December 6, 2013.
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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . 4
2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4 2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4
2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5 2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5
3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6 3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . 6
4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 6 4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . 7 4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . 9
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 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10
A.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 10 A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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 secret keys (as defined in [RFC5996], Sec. 2.12). The tests reuse DH private keys (as defined in [RFC5996], Sec. 2.12). The
apply to the recipient of a KE payload, and describe how it should tests apply to the recipient of a KE payload, and describe how it
check the received payload. They are listed here according to the DH should check the received payload. They are listed here according to
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], Sec 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.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
RFC). RFC).
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 (in Sec. 7 of
[RFC5903]) does not allow for encoding this value. [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 ECDH groups may be modified to
include the tests described in the current document, even if they do include the tests described in the current document, even if they do
not reuse DH keys. The tests can be considered as sanity checks, and not reuse DH keys. The tests can be considered as sanity checks, and
will prevent the code having to handle inputs that it may not have will prevent the code having to handle inputs that it may not have
been designed to handle. 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
can assume that the sender is either truly malicious or else it has a must assume that the sender is either truly malicious or else it has
bug in its implementation. a bug in its implementation. The behavior defined below attempts to
balance resistance to attackers that are trying to disrupt the IKE
exchange, against the need to help a badly implemented peer by
providing useful 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 SA.
If the implementation implements the DoS-resistant behavior proposed If the implementation implements the DoS-resistant behavior proposed
in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request in Sec. 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.
skipping to change at page 7, line 7 skipping to change at page 7, line 14
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 secret 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 Sec. 2 of [Menezes]). Since the key is shared, Eve will
be able to obtain Alice's shared IKE SA key with Bob. 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 15
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, Sec. 2.21.1 of [RFC5996].
The sender is not required to send back an error notification, and The sender is not required to send back an error notification, and
the recipient cannot depend on this notification because it is the recipient cannot depend on this notification because it is
unauthenticated, and may in fact have been sent by an attacker trying unauthenticated, and may in fact have been sent by an attacker trying
to DoS the connection. Thus, the notification is only useful to to DoS the connection. Thus, the notification is only useful to
debug implementation errors. debug implementation errors.
On the other hand, the error notification is secure, in the sense On the other hand, the error notification is secure in the sense that
that no secret information is leaked. All IKEv2 Diffie-Hellman no secret information is leaked. All IKEv2 Diffie-Hellman groups are
groups are publicly known, and none of the tests defined here depend publicly known, and none of the tests defined here depend on any
on any secret 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 Sec. 2.21.3 of [RFC5996] for more details on error handling in this
case. case.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 10, line 18 skipping to change at page 10, line 26
[IANA-DH-Registry] [IANA-DH-Registry]
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters, IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters,
Transform Type 4 - Diffie-Hellman Group Transform IDs", Transform Type 4 - Diffie-Hellman Group Transform IDs",
Jan. 2005, <http://www.iana.org/assignments/ Jan. 2005, <http://www.iana.org/assignments/
ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-8>. ikev2-parameters/ikev2-parameters.xml#ikev2-parameters-8>.
Appendix A. Appendix: Change Log Appendix A. Appendix: Change Log
Note to RFC Editor: please remove this section before publication. Note to RFC Editor: please remove this section before publication.
A.1. -04 A.1. -05
o Resolved IESG members' comments.
A.2. -04
o Implemented Sean's AD review, and removed the inapplicable o Implemented Sean's AD review, and removed the inapplicable
requirement on the point at infinity. requirement on the point at infinity.
A.2. -03 A.3. -03
o Added the Brainpool curves to the IANA registration table. o Added the Brainpool curves to the IANA registration table.
A.3. -02 A.4. -02
o Based on Tero's review: Improved the protocol behavior, and o Based on Tero's review: Improved the protocol behavior, and
mentioned that these checks apply to Create Child SA. Added a mentioned that these checks apply to Create Child SA. Added a
discussion of DH timing attacks, stolen from RFC 2412. discussion of DH timing attacks, stolen from RFC 2412.
A.4. -01 A.5. -01
o Corrected an author's name that was misspelled. o Corrected an author's name that was misspelled.
o Added recipient behavior if a test fails, and the related security o Added recipient behavior if a test fails, and the related security
considerations. considerations.
A.5. -00 A.6. -00
o First WG document. o First WG document.
o Clarified IANA actions. o Clarified IANA actions.
o Discussion of potential future groups not covered here. o Discussion of potential future groups not covered here.
o Clarification re: practicality of recipient tests for DSA groups. o Clarification re: practicality of recipient tests for DSA groups.
Authors' Addresses Authors' Addresses
Yaron Sheffer Yaron Sheffer
Porticor Porticor
 End of changes. 17 change blocks. 
29 lines changed or deleted 37 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/