One document matched: draft-sheffer-ipsecme-dh-checks-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY rfc3526 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3526.xml">
<!ENTITY rfc5114 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5114.xml">
<!ENTITY Menezes SYSTEM "/home/yaronf/Desktop/dh-checks/reference.Menezes.xml">
]>
<rfc docName="draft-sheffer-ipsecme-dh-checks-00" ipr="trust200902" category="std" updates="5996">
  <front>
    <title abbrev="DH Tests">Additional Diffie-Hellman Tests for IKEv2</title>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization abbrev="Porticor">Porticor</organization>
      <address>
        <postal>
          <street>10 Yirmiyahu St.</street>
          <city>Ramat HaSharon</city>
          <code>47298</code>
          <country>Israel</country>
        </postal>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Fluhrer" fullname="Scott Fluhrer">
      <organization abbrev="Cisco">Cisco Systems</organization>
      <address>
        <postal>
          <street>1414 Massachusetts Ave.</street>
          <city>Boxborough</city>
          <region>MA</region>
          <code>01719</code>
          <country>USA</country>
        </postal>
        <email>sfluhrer@cisco.com</email>
      </address>
    </author>
    <date month="December" year="2012"/>
    <area>
Security Area
</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
This document adds a small number of mandatory tests required for the secure operation of 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 DSA groups. This document updates the IKEv2 protocol, RFC 5996.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="d1e304">
      <t>
IKEv2 <xref target="RFC5996"/> consists of the establishment of a shared secret using the Diffie-Hellman (DH) protocol, followed by authentication of the two peers. Existing implementations typically use modular exponential (MODP) DH groups, such as those defined in <xref target="RFC3526"/>.</t>
      <t>
Recently there is growing interest in using IKEv2 with groups based on elliptic curve cryptography. It turns out that using EC groups in some scenarios requires that IKE peers implement additional tests. This document defines these tests.</t>
      <section title="Conventions used in this document" anchor="d1e328">
        <t>
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 <xref target="RFC2119"/>.</t>
      </section>
    </section>
    <section title="Group Membership Tests" anchor="d1e344">
      <t>
This section describes the tests that need to be performed by IKE peers receiving a Key Exchange (KE) payload. The tests are RECOMMENDED for all implementations, but only REQUIRED for those that reuse DH secret keys (as defined in <xref target="RFC5996"/>, Sec. 2.12). The tests are listed here according to the DH group being used.</t>
      <section title="Regular MODP Groups: Group 1, 2, 5, 14-18" anchor="d1e359">
        <t>
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 any such MODP group. The only check needed is a verification that the peer's public value r is in the legal range (1 < r < p-1). According to <xref target="Menezes"/>, Sec 2.2, there is a possibility of leaking a single bit of the secret exponent during reuse; this amount of leakage is insignificant.</t>
      </section>
      <section title="MODP Groups with Small Subgroups: Group 22, 23, 24" anchor="d1e374">
        <t>
IKEv2 groups 22-24 <xref target="RFC5114"/> are modular exponential groups with small subgroups; these all have (p-1)/2 composite. Sec. 2.1 of <xref target="Menezes"/> describes some informational leakage from a small subgroup attack on these groups. An IKE peer 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).</t>
      </section>
      <section title="Elliptic Curve Groups: Group 19-21, 25,26" anchor="d1e395">
        <t>
IKEv2 groups 19-21, 25-26 are elliptic curve groups defined over a field GF(p). According to <xref target="Menezes"/>, Sec. 2.3, there is some informational leakage possible. A receiving peer MUST check that its peer's public value is valid; that is, it is not the point-at-infinity, and that the x and y parameters from the peer's public value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p (where for groups 19, 20, 21, a=-3, and all other values of a, b and p for the group are listed in the RFC).</t>
      </section>
      <section title="Transition" anchor="d1e410">
        <t>
Existing implementations of IKEv2 with ECDH groups MAY be modified to include the tests described in the current document, provided they do not reuse DH keys with multiple peers. The tests can be considered as sanity checks, and will prevent the code having to handle inputs that it may not have been designed to handle.</t>
        <t>
ECDH implementations that do reuse DH keys MUST be enhanced to include the above tests.</t>
      </section>
    </section>
    <section title="Security Considerations" anchor="d1e423">
      <t>
This entire document is concerned with the IKEv2 security protocol and the need to harden it in some cases.</t>
      <section title="DH Key Reuse and Multiple Peers" anchor="d1e432">
        <t>
This section describes the attack prevented by the tests defined here.</t>
        <t>
Suppose that IKE peer Alice maintains 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 will be able to send a malformed public key, which would allow her to efficiently determine Alice's secret key (as described in Sec. 2 of <xref target="Menezes"/>). Since the key is shared, Eve will be able to obtain Alice's shared IKE SA key with Bob.</t>
      </section>
    </section>
    <section title="IANA Considerations" anchor="d1e450">
      <t>
This document does not have any IANA actions.</t>
      <t>
All the Diffie-Hellman groups mentioned here are managed by IANA. Future documents that define new DH groups for use by IKEv2 MUST reference this document and describe which of the tests listed here are applicable, or whether other tests are required.</t>
    </section>
    <section title="Acknowledgements" anchor="d1e462">
      <t>
We would like to thank Dan Harkins who initially raised this issue on the ipsec mailing list.</t>
      <t>
The document was prepared using the lyx2rfc tool, created by Nico Williams.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References" anchor="sec_References">&rfc2119;
&rfc5996;
</references>
    <references title="Informative References" anchor="d1e500">&rfc3526;
&rfc5114;
&Menezes;
</references>
  </back>
</rfc>