idnits 2.17.1 draft-ietf-ipsecme-dh-checks-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- 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 (April 2, 2013) is 4041 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme Y. Sheffer 3 Internet-Draft Porticor 4 Updates: 5996 (if approved) S. Fluhrer 5 Intended status: Standards Track Cisco 6 Expires: October 4, 2013 April 2, 2013 8 Additional Diffie-Hellman Tests for IKEv2 9 draft-ietf-ipsecme-dh-checks-01 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 October 4, 2013. 36 Copyright Notice 38 Copyright (c) 2013 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 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . 3 55 2. Group Membership Tests . . . . . . . . . . . . . . . . 3 56 2.1. Regular MODP Groups . . . . . . . . . . . . . . . . . . 3 57 2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 3 58 2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . . 4 59 2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 4 60 2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . . 5 61 3. Security Considerations . . . . . . . . . . . . . . . . 5 62 3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5 63 3.2. Groups not covered by this RFC . . . . . . . . . . . . 5 64 3.3. Behavior Upon Test Failure . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . 7 70 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7 71 A.1. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 A.2. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 IKEv2 [RFC5996] consists of the establishment of a shared secret 78 using the Diffie-Hellman (DH) protocol, followed by authentication of 79 the two peers. Existing implementations typically use modular 80 exponential (MODP) DH groups, such as those defined in [RFC3526]. 82 IKEv2 does not require that any tests be performed by a peer 83 receiving a public Diffie-Hellman key from the other peer. This is 84 fine for the common case of MODP groups. For other DH groups, when 85 peers reuse DH values across multiple IKE sessions, the lack of tests 86 by the recipient results in a potential vulnerability (see 87 Section 3.1 for more details). In particular, this is true for 88 elliptic curve groups whose use is becoming ever more popular. This 89 document defines such tests for several types of DH groups. 91 1.1. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Group Membership Tests 99 This section describes the tests that need to be performed by IKE 100 peers receiving a Key Exchange (KE) payload. The tests are 101 RECOMMENDED for all implementations, but only REQUIRED for those that 102 reuse DH secret keys (as defined in [RFC5996], Sec. 2.12). The tests 103 are listed here according to the DH group being used. 105 2.1. Regular MODP Groups 107 These are currently the most commonly used groups; all these groups 108 have the property that (p-1)/2 is also prime; this section applies to 109 any such MODP group. Each recipient MUST verify that the peer's 110 public value r is in the legal range (1 < r < p-1). According to 111 [Menezes], Sec 2.2, even with this check there remains the 112 possibility of leaking a single bit of the secret exponent when DH 113 keys are reused; this amount of leakage is insignificant. 115 See Section 4 for the specific groups covered by this section. 117 2.2. MODP Groups with Small Subgroups 119 [RFC5114] defines modular exponential groups with small subgroups; 120 these are modular exponential groups with comparatively small 121 subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes] 122 describes some informational leakage from a small subgroup attack on 123 these groups, if the DH private value is reused. 125 This leakage can be prevented if the recipient performs a test on the 126 peer's public value, however this test is expensive (approximately as 127 expensive as what reusing DH private values saves). In addition, the 128 NIST standard [NIST-800-56A] requires that test (see section 129 5.6.2.4), hence anyone needing to conform to that standard will need 130 to implement the test anyway. 132 Because of the above, the IKE implementation MUST choose between one 133 of the following two options: 135 o It MUST check both that the peer's public value is in range (1 < r 136 < p-1) and that r**q = 1 mod p (where q is the size of the 137 subgroup, as listed in the RFC). DH private values MAY then be 138 reused. This option is appropriate if conformance to 139 [NIST-800-56A] is required. 140 o It MUST NOT reuse DH private values (that is, the DH private value 141 for each DH exchange MUST be generated from a fresh output of a 142 cryptographically secure random number generator), and it MUST 143 check that the peer's public value is in range (1 < r < p-1). 144 This option is more appropriate if conformance to [NIST-800-56A] 145 is not required. 147 See Section 4 for the specific groups covered by this section. 149 2.3. Elliptic Curve Groups 151 IKEv2 can be used with elliptic curve groups defined over a field 152 GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there 153 is some informational leakage possible. A receiving peer MUST check 154 that its peer's public value is valid; that is, it is not the point- 155 at-infinity, and that the x and y parameters from the peer's public 156 value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p 157 (where for groups 19, 20, 21, a=-3, and all other values of a, b and 158 p for the group are listed in the RFC). 160 See Section 4 for the specific groups covered by this section. 162 2.4. Transition 164 Existing implementations of IKEv2 with ECDH groups MAY be modified to 165 include the tests described in the current document, if they do not 166 reuse DH keys with multiple peers. The tests can be considered as 167 sanity checks, and will prevent the code having to handle inputs that 168 it may not have been designed to handle. 170 ECDH implementations that do reuse DH keys MUST be enhanced to 171 include the above tests. 173 2.5. Protocol Behavior 175 The recipient of a DH public key that fails one of the above tests 176 can assume that the sender either is truly malicious or else it has a 177 bug in its implementation. The recipient MAY respond with an 178 unauthenticated INVALID_SYNTAX notification, and MUST immediately 179 drop the IKE SA. 181 3. Security Considerations 183 This entire document is concerned with the IKEv2 security protocol 184 and the need to harden it in some cases. 186 3.1. DH Key Reuse and Multiple Peers 188 This section describes the attack prevented by the tests defined 189 here. 191 Suppose that IKE peer Alice maintains IKE security associations with 192 peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 193 which is allowed with some restrictions. If Alice does not implement 194 these tests, Eve will be able to send a malformed public key, which 195 would allow her to efficiently determine Alice's secret key (as 196 described in Sec. 2 of [Menezes]). Since the key is shared, Eve will 197 be able to obtain Alice's shared IKE SA key with Bob. 199 3.2. Groups not covered by this RFC 201 There are a number of group types that are not specifically addressed 202 by this RFC. A document that defines such a group MUST describe the 203 tests required by that group. 205 One specific type of group would be an even-characteristic elliptic 206 curve group. Now, these curves have cofactors greater than 1; this 207 leads to a possibility of some information leakage. There are 208 several ways to address this information leakage, such as performing 209 a test analogous to the test in section 2.2, or adjusting the ECDH 210 operation to avoid this leakage (such as "ECC CDH", where the shared 211 secret really is hxyG). Because the appropriate test depends on how 212 the group is defined, we cannot document it in advance. 214 3.3. Behavior Upon Test Failure 216 The behavior recommended in Section 2.5 is in line with generic error 217 treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. 218 The sender is not required to send back an error notification, and 219 the recipient cannot depend on this notification because it is 220 unauthenticated. Thus, the notification is only useful to debug 221 implementation errors. 223 On the other hand, the error notification is secure, in the sense 224 that no secret information is leaked. All IKEv2 Diffie-Hellman 225 groups are publicly known, and none of the tests defined here depend 226 on any secret key. In fact the tests can all be performed by an 227 eavesdropper. 229 4. IANA Considerations 231 This document requests that IANA should add a column named "Recipient 232 Tests" to the IKEv2 DH Group Transform IDs Registry 233 [IANA-DH-Registry]. 235 This column should initially be populated as per the following table. 237 +-----------------------------+---------------------+ 238 | Number | Recipient Tests | 239 +-----------------------------+---------------------+ 240 | 1, 2, 5, 14, 15, 16, 17, 18 | [current], Sec. 2.1 | 241 | 22, 23, 24 | [current], Sec. 2.2 | 242 | 19, 20, 21, 25, 26 | [current], Sec. 2.3 | 243 +-----------------------------+---------------------+ 245 Note to RFC Editor: please replace [current] by the RFC number 246 assigned to this document. 248 Future documents that define new DH groups for IKEv2 are REQUIRED to 249 provide this information for each new group, possibly by referring to 250 the current document. 252 5. Acknowledgements 254 We would like to thank Dan Harkins who initially raised this issue on 255 the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for 256 their useful comments. 258 The document was prepared using the lyx2rfc tool, created by Nico 259 Williams. 261 6. References 263 6.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 269 "Internet Key Exchange Protocol Version 2 (IKEv2)", 270 RFC 5996, September 2010. 272 6.2. Informative References 274 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 275 Diffie-Hellman groups for Internet Key Exchange (IKE)", 276 RFC 3526, May 2003. 278 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 279 Groups for Use with IETF Standards", RFC 5114, 280 January 2008. 282 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 283 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 284 June 2010. 286 [NIST-800-56A] 287 National Institute of Standards and Technology (NIST), 288 "Recommendation for Pair-Wise Key Establishment Schemes 289 Using Discrete Logarithm Cryptography (Revised)", NIST PUB 290 800-56A, March 2007. 292 [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 293 Diffie-Hellman Key Agreement Protocols", December 2008, . 297 [IANA-DH-Registry] 298 IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters, 299 Transform Type 4 - Diffie-Hellman Group Transform IDs", 300 Jan. 2005, . 303 Appendix A. Appendix: Change Log 305 Note to RFC Editor: please remove this section before publication. 307 A.1. -01 309 o Corrected an author's name that was misspelled. 310 o Added recipient behavior if a test fails, and the related security 311 considerations. 313 A.2. -00 315 o First WG document. 316 o Clarified IANA actions. 317 o Discussion of potential future groups not covered here. 318 o Clarification re: practicality of recipient tests for DSA groups. 320 Authors' Addresses 322 Yaron Sheffer 323 Porticor 324 10 Yirmiyahu St. 325 Ramat HaSharon 47298 326 Israel 328 Email: yaronf.ietf@gmail.com 330 Scott Fluhrer 331 Cisco Systems 332 1414 Massachusetts Ave. 333 Boxborough, MA 01719 334 USA 336 Email: sfluhrer@cisco.com