idnits 2.17.1 draft-sheffer-ipsecme-dh-checks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5996, but the abstract doesn't seem to directly say this. It does mention RFC5996 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5996, updated by this document, for RFC5378 checks: 2008-08-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 7, 2012) is 4157 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Porticor 4 Updates: 5996 (if approved) S. Fluhrer 5 Intended status: Standards Track Cisco 6 Expires: June 10, 2013 December 7, 2012 8 Additional Diffie-Hellman Tests for IKEv2 9 draft-sheffer-ipsecme-dh-checks-00 11 Abstract 13 This document adds a small number of mandatory tests required for the 14 secure operation of IKEv2 with elliptic curve groups. No change is 15 required to IKE implementations that use modular exponential groups, 16 other than a few rarely used so-called DSA groups. This document 17 updates the IKEv2 protocol, RFC 5996. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 IKEv2 [RFC5996] consists of the establishment of a shared secret 54 using the Diffie-Hellman (DH) protocol, followed by authentication of 55 the two peers. Existing implementations typically use modular 56 exponential (MODP) DH groups, such as those defined in [RFC3526]. 58 Recently there is growing interest in using IKEv2 with groups based 59 on elliptic curve cryptography. It turns out that using EC groups in 60 some scenarios requires that IKE peers implement additional tests. 61 This document defines these tests. 63 1.1. Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 2. Group Membership Tests 71 This section describes the tests that need to be performed by IKE 72 peers receiving a Key Exchange (KE) payload. The tests are 73 RECOMMENDED for all implementations, but only REQUIRED for those that 74 reuse DH secret keys (as defined in [RFC5996], Sec. 2.12). The tests 75 are listed here according to the DH group being used. 77 2.1. Regular MODP Groups: Group 1, 2, 5, 14-18 79 These are currently the most commonly used groups; all these groups 80 have the property that (p-1)/2 is also prime; this section applies to 81 any such MODP group. The only check needed is a verification that 82 the peer's public value r is in the legal range (1 < r < p-1). 83 According to [Menezes], Sec 2.2, there is a possibility of leaking a 84 single bit of the secret exponent during reuse; this amount of 85 leakage is insignificant. 87 2.2. MODP Groups with Small Subgroups: Group 22, 23, 24 89 IKEv2 groups 22-24 [RFC5114] are modular exponential groups with 90 small subgroups; these all have (p-1)/2 composite. Sec. 2.1 of 91 [Menezes] describes some informational leakage from a small subgroup 92 attack on these groups. An IKE peer MUST check both that the peer's 93 public value is in range (1 < r < p-1) and that r**q = 1 mod p (where 94 q is the size of the subgroup, as listed in the RFC). 96 2.3. Elliptic Curve Groups: Group 19-21, 25,26 98 IKEv2 groups 19-21, 25-26 are elliptic curve groups defined over a 99 field GF(p). According to [Menezes], Sec. 2.3, there is some 100 informational leakage possible. A receiving peer MUST check that its 101 peer's public value is valid; that is, it is not the point-at- 102 infinity, and that the x and y parameters from the peer's public 103 value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p 104 (where for groups 19, 20, 21, a=-3, and all other values of a, b and 105 p for the group are listed in the RFC). 107 2.4. Transition 109 Existing implementations of IKEv2 with ECDH groups MAY be modified to 110 include the tests described in the current document, provided they do 111 not reuse DH keys with multiple peers. The tests can be considered 112 as sanity checks, and will prevent the code having to handle inputs 113 that it may not have been designed to handle. 115 ECDH implementations that do reuse DH keys MUST be enhanced to 116 include the above tests. 118 3. Security Considerations 120 This entire document is concerned with the IKEv2 security protocol 121 and the need to harden it in some cases. 123 3.1. DH Key Reuse and Multiple Peers 125 This section describes the attack prevented by the tests defined 126 here. 128 Suppose that IKE peer Alice maintains IKE security associations with 129 peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 130 which is allowed with some restrictions. If Alice does not implement 131 these tests, Eve will be able to send a malformed public key, which 132 would allow her to efficiently determine Alice's secret key (as 133 described in Sec. 2 of [Menezes]). Since the key is shared, Eve will 134 be able to obtain Alice's shared IKE SA key with Bob. 136 4. IANA Considerations 138 This document does not have any IANA actions. 140 All the Diffie-Hellman groups mentioned here are managed by IANA. 141 Future documents that define new DH groups for use by IKEv2 MUST 142 reference this document and describe which of the tests listed here 143 are applicable, or whether other tests are required. 145 5. Acknowledgements 147 We would like to thank Dan Harkins who initially raised this issue on 148 the ipsec mailing list. 150 The document was prepared using the lyx2rfc tool, created by Nico 151 Williams. 153 6. References 155 6.1. Normative References 157 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 158 Requirement Levels", BCP 14, RFC 2119, March 1997. 160 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 161 "Internet Key Exchange Protocol Version 2 (IKEv2)", 162 RFC 5996, September 2010. 164 6.2. Informative References 166 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 167 Diffie-Hellman groups for Internet Key Exchange (IKE)", 168 RFC 3526, May 2003. 170 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 171 Groups for Use with IETF Standards", RFC 5114, 172 January 2008. 174 [Menezes] Menezes, A. and B. Ostaoglu, "On Reusing Ephemeral Keys In 175 Diffie-Hellman Key Agreement Protocols", December 2008, < 176 http://www.cacr.math.uwaterloo.ca/techreports/2008/ 177 cacr2008-24.pdf>. 179 Authors' Addresses 181 Yaron Sheffer 182 Porticor 183 10 Yirmiyahu St. 184 Ramat HaSharon 47298 185 Israel 187 Email: yaronf.ietf@gmail.com 189 Scott Fluhrer 190 Cisco Systems 191 1414 Massachusetts Ave. 192 Boxborough, MA 01719 193 USA 195 Email: sfluhrer@cisco.com