idnits 2.17.1 draft-ietf-ipsecme-dh-checks-05.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 (June 4, 2013) is 3978 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: December 6, 2013 June 4, 2013 8 Additional Diffie-Hellman Tests for IKEv2 9 draft-ietf-ipsecme-dh-checks-05 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 December 6, 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. Sophie Germain Prime MODP Groups . . . . . . . . . . . 3 57 2.2. MODP Groups with Small Subgroups . . . . . . . . . . . 4 58 2.3. Elliptic Curve Groups . . . . . . . . . . . . . . . . 4 59 2.4. Transition . . . . . . . . . . . . . . . . . . . . . . 5 60 2.5. Protocol Behavior . . . . . . . . . . . . . . . . . . 5 61 3. Side-Channel Attacks . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . 6 63 4.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . 7 64 4.2. DH Key Reuse: Variants . . . . . . . . . . . . . . . . 7 65 4.3. Groups not covered by this RFC . . . . . . . . . . . . 7 66 4.4. Behavior Upon Test Failure . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Normative References . . . . . . . . . . . . . . . . . 9 71 7.2. Informative References . . . . . . . . . . . . . . . . 9 72 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 10 73 A.1. -05 . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 A.2. -04 . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 A.3. -03 . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 A.4. -02 . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 A.5. -01 . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 A.6. -00 . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 IKEv2 [RFC5996] consists of the establishment of a shared secret 84 using the Diffie-Hellman (DH) protocol, followed by authentication of 85 the two peers. Existing implementations typically use modular 86 exponential (MODP) DH groups, such as those defined in [RFC3526]. 88 IKEv2 does not require that any tests be performed by a peer 89 receiving a public Diffie-Hellman key from the other peer. This is 90 fine for the common case of MODP groups. For other DH groups, when 91 peers reuse DH values across multiple IKE sessions, the lack of tests 92 by the recipient results in a potential vulnerability (see 93 Section 4.1 for more details). In particular, this is true for 94 Elliptic Curve (EC) groups whose use is becoming ever more popular. 95 This document defines such tests for several types of DH groups. 97 In addition, this document describes another potential attack related 98 to reuse of DH keys: a timing attack. This additional material is 99 taken from [RFC2412]. 101 This document updates [RFC5996] by adding security requirements that 102 apply to many of the protocol's implementations. 104 1.1. Conventions used in this document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Group Membership Tests 112 This section describes the tests that need to be performed by IKE 113 peers receiving a Key Exchange (KE) payload. The tests are 114 RECOMMENDED for all implementations, but only REQUIRED for those that 115 reuse DH private keys (as defined in [RFC5996], Sec. 2.12). The 116 tests apply to the recipient of a KE payload, and describe how it 117 should check the received payload. They are listed here according to 118 the DH group being used. 120 2.1. Sophie Germain Prime MODP Groups 122 These are currently the most commonly used groups; all these groups 123 have the property that (p-1)/2 is also prime; this section applies to 124 any such MODP group. Each recipient MUST verify that the peer's 125 public value r is in the legal range (1 < r < p-1). According to 126 [Menezes], Sec 2.2, even with this check there remains the 127 possibility of leaking a single bit of the secret exponent when DH 128 keys are reused; this amount of leakage is insignificant. 130 See Section 5 for the specific groups covered by this section. 132 2.2. MODP Groups with Small Subgroups 134 [RFC5114] defines modular exponential groups with small subgroups; 135 these are modular exponential groups with comparatively small 136 subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes] 137 describes some informational leakage from a small subgroup attack on 138 these groups, if the DH private value is reused. 140 This leakage can be prevented if the recipient performs a test on the 141 peer's public value, however this test is expensive (approximately as 142 expensive as what reusing DH private values saves). In addition, the 143 NIST standard [NIST-800-56A] requires that test (see section 144 5.6.2.4), hence anyone needing to conform to that standard will need 145 to implement the test anyway. 147 Because of the above, the IKE implementation MUST choose between one 148 of the following two options: 150 o It MUST check both that the peer's public value is in range (1 < r 151 < p-1) and that r^q = 1 mod p (where q is the size of the 152 subgroup, as listed in the RFC). DH private values MAY then be 153 reused. This option is appropriate if conformance to 154 [NIST-800-56A] is required. 155 o It MUST NOT reuse DH private values (that is, the DH private value 156 for each DH exchange MUST be generated from a fresh output of a 157 cryptographically secure random number generator), and it MUST 158 check that the peer's public value is in range (1 < r < p-1). 159 This option is more appropriate if conformance to [NIST-800-56A] 160 is not required. 162 See Section 5 for the specific groups covered by this section. 164 2.3. Elliptic Curve Groups 166 IKEv2 can be used with elliptic curve groups defined over a field 167 GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there 168 is some informational leakage possible. A receiving peer MUST check 169 that its peer's public value is valid; that is, the x and y 170 parameters from the peer's public value satisfy the curve equation, 171 y^2 = x^3 + ax + b mod p (where for groups 19, 20, 21, a=-3 (mod p), 172 and all other values of a, b and p for the group are listed in the 173 RFC). 175 We note that an additional check to ensure that the public value is 176 not the point at infinity is not needed, because IKE (in Sec. 7 of 177 [RFC5903]) does not allow for encoding this value. 179 See Section 5 for the specific groups covered by this section. 181 2.4. Transition 183 Existing implementations of IKEv2 with ECDH groups may be modified to 184 include the tests described in the current document, even if they do 185 not reuse DH keys. The tests can be considered as sanity checks, and 186 will prevent the code having to handle inputs that it may not have 187 been designed to handle. 189 ECDH implementations that do reuse DH keys MUST be enhanced to 190 include the above tests. 192 2.5. Protocol Behavior 194 The recipient of a DH public key that fails one of the above tests 195 must assume that the sender is either truly malicious or else it has 196 a bug in its implementation. The behavior defined below attempts to 197 balance resistance to attackers that are trying to disrupt the IKE 198 exchange, against the need to help a badly implemented peer by 199 providing useful error indications. 201 If this error happens during the IKE_SA_INIT exchange, then the 202 recipient MUST drop the message that contains an invalid KE payload, 203 and MUST NOT use that message when creating the IKE SA. 205 If the implementation implements the DoS-resistant behavior proposed 206 in Sec. 2.4 of [RFC5996], it may simply ignore the erroneous request 207 or response message, and continue waiting for a later message 208 containing a legitimate KE payload. 210 If DoS-resistant behavior is not implemented, and the invalid KE 211 payload was in the IKE_SA_INIT request, the implementation MAY send 212 an INVALID_SYNTAX error notification back, and remove the in-progress 213 IKE SA; if the invalid KE payload was in the IKE_SA_INIT response, 214 then the implementation MAY simply delete the half created IKE SA, 215 and re-initiate the exchange. 217 If the invalid KE payload is received during the CREATE_CHILD_SA 218 exchange (or any other exchange after the IKE SA has been 219 established) and the invalid KE payload is in the request message, 220 the Responder MUST reply with an INVALID_SYNTAX error notification 221 and drop the IKE SA. If the invalid KE payload is in a response, the 222 Initiator getting this reply MUST immediately delete the IKE SA by 223 sending an IKE SA Delete notification as a new exchange. In this 224 case the sender evidently has an implementation bug, and dropping the 225 IKE SA makes it easier to detect. 227 3. Side-Channel Attacks 229 In addition to the small-subgroup attack, there is also a potential 230 timing attack on IKE peers when they are reusing Diffie-Hellman 231 secret values. This is a side-channel attack, which means that it 232 may or may not be a vulnerability in certain cases, depending on 233 implementation details and the threat model. 235 The remainder of this section is quoted from [RFC2412], Sec. 5, with 236 a few minor clarifications. This attack still applies to IKEv2 237 implementations, and both to MODP groups and ECDH groups. We also 238 note that more efficient countermeasures are available for EC groups 239 represented in projective form, but these are outside the scope of 240 the current document. 242 Timing attacks that are capable of recovering the exponent value used 243 in Diffie-Hellman calculations have been described by Paul Kocher 244 [Kocher]. In order to nullify the attack, implementors must take 245 pains to obscure the sequence of operations involved in carrying out 246 modular exponentiations. 248 One potential method to foil these timing attacks is to use a 249 "blinding factor". In this method, a group element, r, is chosen at 250 random, and its multiplicative inverse modulo p is computed, which 251 we'll call r_inv. r_inv can be computed by the Extended Euclidean 252 Method, using r and p as inputs. When an exponent x is chosen, the 253 value r_inv^x is also calculated. Then, when calculating (g^y)^x, 254 the implementation will calculate this sequence: 256 A = r*g^y 257 B = A^x = (r*g^y)^x = (r^x)(g^(xy)) 258 C = B*r_inv^x = (r^x)(r^(-1*x))(g^(xy)) = g^(xy) 260 The blinding factor is only necessary if the exponent x is used more 261 than 100 times (estimate by Richard Schroeppel). 263 4. Security Considerations 265 This entire document is concerned with the IKEv2 security protocol 266 and the need to harden it in some cases. 268 4.1. DH Key Reuse and Multiple Peers 270 This section describes one variant of the attack prevented by the 271 tests defined above. 273 Suppose that IKE peer Alice maintains IKE security associations with 274 peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 275 which is allowed with some restrictions. If Alice does not implement 276 these tests, Eve will be able to send a malformed public key, which 277 would allow her to efficiently determine Alice's private key (as 278 described in Sec. 2 of [Menezes]). Since the key is shared, Eve will 279 be able to obtain Alice's shared IKE SA key with Bob. 281 4.2. DH Key Reuse: Variants 283 Private DH keys can be reused in different ways, with subtly 284 different security implications. For example: 286 1. DH keys are reused for multiple connections (IKE SAs) to the same 287 peer, and for connections to different peers. 288 2. DH keys are reused for multiple connections to the same peer 289 (e.g. when the peer is identified by its IP address) but not for 290 different peers. 291 3. DH keys are reused only when they had not been used to complete 292 an exchange, e.g. when the peer replies with an 293 INVALID_KE_PAYLOAD notification. 295 Both the small subgroup attack and the timing attack described in 296 this document apply at least to options #1 and #2. 298 4.3. Groups not covered by this RFC 300 There are a number of group types that are not specifically addressed 301 by this RFC. A document that defines such a group MUST describe the 302 tests required by that group. 304 One specific type of group would be an even-characteristic elliptic 305 curve group. Now, these curves have cofactors greater than 1; this 306 leads to a possibility of some information leakage. There are 307 several ways to address this information leakage, such as performing 308 a test analogous to the test in section 2.2, or adjusting the ECDH 309 operation to avoid this leakage (such as "ECC CDH", where the shared 310 secret really is hxyG). Because the appropriate test depends on how 311 the group is defined, we cannot document it in advance. 313 4.4. Behavior Upon Test Failure 315 The behavior recommended in Section 2.5 is in line with generic error 316 treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996]. 317 The sender is not required to send back an error notification, and 318 the recipient cannot depend on this notification because it is 319 unauthenticated, and may in fact have been sent by an attacker trying 320 to DoS the connection. Thus, the notification is only useful to 321 debug implementation errors. 323 On the other hand, the error notification is secure in the sense that 324 no secret information is leaked. All IKEv2 Diffie-Hellman groups are 325 publicly known, and none of the tests defined here depend on any 326 private key. In fact the tests can all be performed by an 327 eavesdropper. 329 The situation when the failure occurs in the Create Child SA exchange 330 is different, since everything is protected by an IKE SA. The peers 331 are authenticated, and error notifications can be relied on. See 332 Sec. 2.21.3 of [RFC5996] for more details on error handling in this 333 case. 335 5. IANA Considerations 337 This document requests that IANA should add a column named "Recipient 338 Tests" to the IKEv2 DH Group Transform IDs Registry 339 [IANA-DH-Registry]. 341 This column should initially be populated as per the following table. 343 +------------------------------------+---------------------+ 344 | Number | Recipient Tests | 345 +------------------------------------+---------------------+ 346 | 1, 2, 5, 14, 15, 16, 17, 18 | [current], Sec. 2.1 | 347 | 22, 23, 24 | [current], Sec. 2.2 | 348 | 19, 20, 21, 25, 26, 27, 28, 29, 30 | [current], Sec. 2.3 | 349 +------------------------------------+---------------------+ 351 Note to RFC Editor: please replace [current] by the RFC number 352 assigned to this document. 354 Groups 27-30 have been recently defined in 355 [I-D.merkle-ikev2-ke-brainpool]. 357 Future documents that define new DH groups for IKEv2 are REQUIRED to 358 provide this information for each new group, possibly by referring to 359 the current document. 361 6. Acknowledgements 363 We would like to thank Dan Harkins who initially raised this issue on 364 the ipsec mailing list. Thanks to Tero Kivinen and Rene Struik for 365 their useful comments. Much of the text in Section 3 is taken from 366 [RFC2412] and we would like to thank its author, Hilarie Orman. 368 The document was prepared using the lyx2rfc tool, created by Nico 369 Williams. 371 7. References 373 7.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 379 "Internet Key Exchange Protocol Version 2 (IKEv2)", 380 RFC 5996, September 2010. 382 7.2. Informative References 384 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", 385 RFC 2412, November 1998. 387 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 388 Diffie-Hellman groups for Internet Key Exchange (IKE)", 389 RFC 3526, May 2003. 391 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 392 Groups for Use with IETF Standards", RFC 5114, 393 January 2008. 395 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 396 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 397 June 2010. 399 [I-D.merkle-ikev2-ke-brainpool] 400 Merkle, J. and M. Lochter, "Using the ECC Brainpool Curves 401 for IKEv2 Key Exchange", 402 draft-merkle-ikev2-ke-brainpool-06 (work in progress), 403 April 2013. 405 [NIST-800-56A] 406 National Institute of Standards and Technology (NIST), 407 "Recommendation for Pair-Wise Key Establishment Schemes 408 Using Discrete Logarithm Cryptography (Revised)", NIST PUB 409 800-56A, March 2007. 411 [Kocher] Kocher, P., "Timing Attacks on Implementations of Diffie- 412 Hellman, RSA, DSS, and Other Systems", December 1996, 413 . 415 [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 416 Diffie-Hellman Key Agreement Protocols", December 2008, . 420 [IANA-DH-Registry] 421 IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters, 422 Transform Type 4 - Diffie-Hellman Group Transform IDs", 423 Jan. 2005, . 426 Appendix A. Appendix: Change Log 428 Note to RFC Editor: please remove this section before publication. 430 A.1. -05 432 o Resolved IESG members' comments. 434 A.2. -04 436 o Implemented Sean's AD review, and removed the inapplicable 437 requirement on the point at infinity. 439 A.3. -03 441 o Added the Brainpool curves to the IANA registration table. 443 A.4. -02 445 o Based on Tero's review: Improved the protocol behavior, and 446 mentioned that these checks apply to Create Child SA. Added a 447 discussion of DH timing attacks, stolen from RFC 2412. 449 A.5. -01 451 o Corrected an author's name that was misspelled. 452 o Added recipient behavior if a test fails, and the related security 453 considerations. 455 A.6. -00 457 o First WG document. 458 o Clarified IANA actions. 459 o Discussion of potential future groups not covered here. 460 o Clarification re: practicality of recipient tests for DSA groups. 462 Authors' Addresses 464 Yaron Sheffer 465 Porticor 466 10 Yirmiyahu St. 467 Ramat HaSharon 47298 468 Israel 470 Email: yaronf.ietf@gmail.com 472 Scott Fluhrer 473 Cisco Systems 474 1414 Massachusetts Ave. 475 Boxborough, MA 01719 476 USA 478 Email: sfluhrer@cisco.com