idnits 2.17.00 (12 Aug 2021) /tmp/idnits53319/draft-ietf-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 : ---------------------------------------------------------------------------- == 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 (January 29, 2013) is 3399 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: August 2, 2013 January 29, 2013 8 Additional Diffie-Hellman Tests for IKEv2 9 draft-ietf-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 August 2, 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 3. Security Considerations . . . . . . . . . . . . . . . . 5 61 3.1. DH Key Reuse and Multiple Peers . . . . . . . . . . . . 5 62 3.2. Groups not covered by this RFC . . . . . . . . . . . . 5 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 65 6. References . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Normative References . . . . . . . . . . . . . . . . . 6 67 6.2. Informative References . . . . . . . . . . . . . . . . 6 68 Appendix A. Appendix: Change Log . . . . . . . . . . . . . . . . . 7 69 A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 IKEv2 [RFC5996] consists of the establishment of a shared secret 75 using the Diffie-Hellman (DH) protocol, followed by authentication of 76 the two peers. Existing implementations typically use modular 77 exponential (MODP) DH groups, such as those defined in [RFC3526]. 79 IKEv2 does not require that any tests be performed by a peer 80 receiving a public Diffie-Hellman key from the other peer. This is 81 fine for the common case of MODP groups. For other DH groups, when 82 peers reuse DH values across multiple IKE sessions, the lack of tests 83 by the recipient results in a potential vulnerability (see 84 Section 3.1 for more details). In particular, this is true for 85 elliptic curve groups whose use is becoming ever more popular. This 86 document defines such tests for several types of DH groups. 88 1.1. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Group Membership Tests 96 This section describes the tests that need to be performed by IKE 97 peers receiving a Key Exchange (KE) payload. The tests are 98 RECOMMENDED for all implementations, but only REQUIRED for those that 99 reuse DH secret keys (as defined in [RFC5996], Sec. 2.12). The tests 100 are listed here according to the DH group being used. 102 2.1. Regular MODP Groups 104 These are currently the most commonly used groups; all these groups 105 have the property that (p-1)/2 is also prime; this section applies to 106 any such MODP group. Each recipient MUST verify that the peer's 107 public value r is in the legal range (1 < r < p-1). According to 108 [Menezes], Sec 2.2, even with this check there remains the 109 possibility of leaking a single bit of the secret exponent when DH 110 keys are reused; this amount of leakage is insignificant. 112 See Section 4 for the specific groups covered by this section. 114 2.2. MODP Groups with Small Subgroups 116 [RFC5114] defines modular exponential groups with small subgroups; 117 these are modular exponential groups with comparatively small 118 subgroups, and all have (p-1)/2 composite. Sec. 2.1 of [Menezes] 119 describes some informational leakage from a small subgroup attack on 120 these groups, if the DH private value is reused. 122 This leakage can be prevented if the recipient performs a test on the 123 peer's public value, however this test is expensive (approximately as 124 expensive as what reusing DH private values saves). In addition, the 125 NIST standard [NIST-800-56A] requires that test (see section 126 5.6.2.4), hence anyone needing to conform to that standard will need 127 to implement the test anyways. 129 Because of the above, the IKE implementation MUST choose between one 130 of the following two options: 132 o It MUST check both that the peer's public value is in range (1 < r 133 < p-1) and that r**q = 1 mod p (where q is the size of the 134 subgroup, as listed in the RFC). DH private values MAY then be 135 reused. This option is appropriate if conformance to 136 [NIST-800-56A] is required. 137 o It MUST NOT reuse DH private values (that is, the DH private value 138 for each DH exchange MUST be generated from a fresh output of a 139 cryptographically secure random number generator), and it MUST 140 check that the peer's public value is in range (1 < r < p-1). 141 This option is more appropriate if conformance to [NIST-800-56A] 142 is not required. 144 See Section 4 for the specific groups covered by this section. 146 2.3. Elliptic Curve Groups 148 IKEv2 can be used with elliptic curve groups defined over a field 149 GF(p) [RFC5903] [RFC5114]. According to [Menezes], Sec. 2.3, there 150 is some informational leakage possible. A receiving peer MUST check 151 that its peer's public value is valid; that is, it is not the point- 152 at-infinity, and that the x and y parameters from the peer's public 153 value satisfy the curve equation, that is, y**2 = x**3 + ax + b mod p 154 (where for groups 19, 20, 21, a=-3, and all other values of a, b and 155 p for the group are listed in the RFC). 157 See Section 4 for the specific groups covered by this section. 159 2.4. Transition 161 Existing implementations of IKEv2 with ECDH groups MAY be modified to 162 include the tests described in the current document, if they do not 163 reuse DH keys with multiple peers. The tests can be considered as 164 sanity checks, and will prevent the code having to handle inputs that 165 it may not have been designed to handle. 167 ECDH implementations that do reuse DH keys MUST be enhanced to 168 include the above tests. 170 3. Security Considerations 172 This entire document is concerned with the IKEv2 security protocol 173 and the need to harden it in some cases. 175 3.1. DH Key Reuse and Multiple Peers 177 This section describes the attack prevented by the tests defined 178 here. 180 Suppose that IKE peer Alice maintains IKE security associations with 181 peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 182 which is allowed with some restrictions. If Alice does not implement 183 these tests, Eve will be able to send a malformed public key, which 184 would allow her to efficiently determine Alice's secret key (as 185 described in Sec. 2 of [Menezes]). Since the key is shared, Eve will 186 be able to obtain Alice's shared IKE SA key with Bob. 188 3.2. Groups not covered by this RFC 190 There are a number of group types that are not specifically addressed 191 by this RFC. A document that defines such a group MUST describe the 192 tests required by that group. 194 One specific type of group would be an even-characteristic elliptic 195 curve group. Now, these curves have cofactors greater than 1; this 196 leads to a possibility of some information leakage. There are 197 several ways to address this information leakage, such as performing 198 a test analogous to the test in section 2.2, or adjusting the ECDH 199 operation to avoid this leakage (such as "ECC CDH", where the shared 200 secret really is hxyG). Because the appropriate test depends on how 201 the group is defined, we cannot document it in advance. 203 4. IANA Considerations 205 This document requests that IANA should add a column named "Recipient 206 Tests" to the IKEv2 DH Group Transform IDs Registry 207 [IANA-DH-Registry]. 209 This column should initially be populated as per the following table. 211 +-----------------------------+---------------------+ 212 | Number | Recipient Tests | 213 +-----------------------------+---------------------+ 214 | 1, 2, 5, 14, 15, 16, 17, 18 | [current], Sec. 2.1 | 215 | 22, 23, 24 | [current], Sec. 2.2 | 216 | 19, 20, 21, 25, 26 | [current], Sec. 2.3 | 217 +-----------------------------+---------------------+ 219 Note to RFC Editor: please replace [current] by the RFC number 220 assigned to this document. 222 Future documents that define new DH groups for IKEv2 are REQUIRED to 223 provide this information for each new group, possibly by referring to 224 the current document. 226 5. Acknowledgements 228 We would like to thank Dan Harkins who initially raised this issue on 229 the ipsec mailing list. 231 The document was prepared using the lyx2rfc tool, created by Nico 232 Williams. 234 6. References 236 6.1. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 242 "Internet Key Exchange Protocol Version 2 (IKEv2)", 243 RFC 5996, September 2010. 245 6.2. Informative References 247 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 248 Diffie-Hellman groups for Internet Key Exchange (IKE)", 249 RFC 3526, May 2003. 251 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 252 Groups for Use with IETF Standards", RFC 5114, 253 January 2008. 255 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 256 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 257 June 2010. 259 [NIST-800-56A] 260 National Institute of Standards and Technology (NIST), 261 "Recommendation for Pair-Wise Key Establishment Schemes 262 Using Discrete Logarithm Cryptography (Revised)", NIST PUB 263 800-56A, March 2007. 265 [Menezes] Menezes, A. and B. Ostaoglu, "On Reusing Ephemeral Keys In 266 Diffie-Hellman Key Agreement Protocols", December 2008, . 270 [IANA-DH-Registry] 271 IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters, 272 Transform Type 4 - Diffie-Hellman Group Transform IDs", 273 Jan. 2005, . 276 Appendix A. Appendix: Change Log 278 Note to RFC Editor: please remove this section before publication. 280 A.1. -00 282 o First WG document. 283 o Clarified IANA actions. 284 o Discussion of potential future groups not covered here. 285 o Clarification re: practicality of recipient tests for DSA groups. 287 Authors' Addresses 289 Yaron Sheffer 290 Porticor 291 10 Yirmiyahu St. 292 Ramat HaSharon 47298 293 Israel 295 Email: yaronf.ietf@gmail.com 296 Scott Fluhrer 297 Cisco Systems 298 1414 Massachusetts Ave. 299 Boxborough, MA 01719 300 USA 302 Email: sfluhrer@cisco.com