draft-ietf-ipsecme-dh-checks-00.txt   draft-ietf-ipsecme-dh-checks-01.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: August 2, 2013 January 29, 2013 Expires: October 4, 2013 April 2, 2013
Additional Diffie-Hellman Tests for IKEv2 Additional Diffie-Hellman Tests for IKEv2
draft-ietf-ipsecme-dh-checks-00 draft-ietf-ipsecme-dh-checks-01
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 August 2, 2013. This Internet-Draft will expire on October 4, 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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
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. Regular MODP Groups . . . . . . . . . . . . . . . . . . 3 2.1. Regular MODP Groups . . . . . . . . . . . . . . . . . . 3
2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3 2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3
2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4 2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4
2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . 5
3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5 3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5
3.2. Groups not covered by this RFC . . . . . . . . . . . . 5 3.2. Groups not covered by this RFC . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . 5 3.3. Behavior Upon Test Failure . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . 7
Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . 7 A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . 8
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 4, line 12 skipping to change at page 4, line 12
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. Sec. 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 as
expensive as what reusing DH private values saves). In addition, the expensive as what reusing DH private values saves). In addition, the
NIST standard [NIST-800-56A] requires that test (see section NIST standard [NIST-800-56A] requires that test (see section
5.6.2.4), hence anyone needing to conform to that standard will need 5.6.2.4), hence anyone needing to conform to that standard will need
to implement the test anyways. to 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). DH private values MAY then be
reused. This option is appropriate if conformance to reused. This option is appropriate if conformance to
[NIST-800-56A] is required. [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
skipping to change at page 5, line 8 skipping to change at page 5, line 8
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, if they do not include the tests described in the current document, if they do not
reuse DH keys with multiple peers. The tests can be considered as reuse DH keys with multiple peers. The tests can be considered as
sanity checks, and will prevent the code having to handle inputs that sanity checks, and will prevent the code having to handle inputs that
it may not have been designed to handle. 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
The recipient of a DH public key that fails one of the above tests
can assume that the sender either is truly malicious or else it has a
bug in its implementation. The recipient MAY respond with an
unauthenticated INVALID_SYNTAX notification, and MUST immediately
drop the IKE SA.
3. Security Considerations 3. 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.
3.1. DH Key Reuse and Multiple Peers 3.1. DH Key Reuse and Multiple Peers
This section describes the attack prevented by the tests defined This section describes the attack prevented by the tests defined
here. here.
skipping to change at page 5, line 41 skipping to change at page 6, line 5
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 "ECC CDH", where the shared
secret really is hxyG). Because the appropriate test depends on how secret really is hxyG). Because the appropriate test depends on how
the group is defined, we cannot document it in advance. the group is defined, we cannot document it in advance.
3.3. Behavior Upon Test Failure
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].
The sender is not required to send back an error notification, and
the recipient cannot depend on this notification because it is
unauthenticated. Thus, the notification is only useful to debug
implementation errors.
On the other hand, the error notification is secure, in the sense
that no secret information is leaked. All IKEv2 Diffie-Hellman
groups are publicly known, and none of the tests defined here depend
on any secret key. In fact the tests can all be performed by an
eavesdropper.
4. IANA Considerations 4. IANA Considerations
This document requests that IANA should add a column named "Recipient This document requests that IANA should add a column named "Recipient
Tests" to the IKEv2 DH Group Transform IDs Registry Tests" to the IKEv2 DH Group Transform IDs Registry
[IANA-DH-Registry]. [IANA-DH-Registry].
This column should initially be populated as per the following table. This column should initially be populated as per the following table.
+-----------------------------+---------------------+ +-----------------------------+---------------------+
| Number | Recipient Tests | | Number | Recipient Tests |
skipping to change at page 6, line 23 skipping to change at page 6, line 46
Note to RFC Editor: please replace [current] by the RFC number Note to RFC Editor: please replace [current] by the RFC number
assigned to this document. assigned to this document.
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.
5. Acknowledgements 5. 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 on
the ipsec mailing list. the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for
their useful comments.
The document was prepared using the lyx2rfc tool, created by Nico The document was prepared using the lyx2rfc tool, created by Nico
Williams. Williams.
6. References 6. References
6.1. Normative References 6.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.
skipping to change at page 7, line 12 skipping to change at page 7, line 36
[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.
[NIST-800-56A] [NIST-800-56A]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Recommendation for Pair-Wise Key Establishment Schemes "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography (Revised)", NIST PUB Using Discrete Logarithm Cryptography (Revised)", NIST PUB
800-56A, March 2007. 800-56A, March 2007.
[Menezes] Menezes, A. and B. Ostaoglu, "On Reusing Ephemeral Keys In [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008, <h Diffie-Hellman Key Agreement Protocols", December 2008, <h
ttp://www.cacr.math.uwaterloo.ca/techreports/2008/ ttp://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>. cacr2008-24.pdf>.
[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. -00 A.1. -01
o Corrected an author's name that was misspelled.
o Added recipient behavior if a test fails, and the related security
considerations.
A.2. -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. 13 change blocks. 
13 lines changed or deleted 46 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/