idnits 2.17.1 draft-bagnulo-multiple-hash-cga-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 408. 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 RFC3972, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3972, updated by this document, for RFC5378 checks: 2003-06-16) -- 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 (March 2, 2007) is 6263 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 informational reference (is this intentional?): RFC 2434 (ref. '5') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '8') (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-arkko-mipshop-cga-cba-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Updates: 3972 (if approved) J. Arkko 5 Intended status: Standards Track Ericsson 6 Expires: September 3, 2007 March 2, 2007 8 Support for Multiple Hash Algorithms in Cryptographically Generated 9 Addresses (CGAs) 10 draft-bagnulo-multiple-hash-cga-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 3, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document analyzes the implications of recent attacks on commonly 44 used hash functions on Cryptographically Generated Addresses (CGAs) 45 and updates the CGA specification to support multiple hash 46 algorithms. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Impact of collision attacks in CGAs . . . . . . . . . . . . . 3 53 4. Options for Multiple Hash Algorithm Support in CGAs . . . . . 4 54 4.1. Where to encode the hash function? . . . . . . . . . . . . 5 55 5. CGA generation procedure . . . . . . . . . . . . . . . . . . . 7 56 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 57 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 58 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 63 Intellectual Property and Copyright Statements . . . . . . . . . . 10 65 1. Introduction 67 Recent attacks to currently used hash functions have motivated a 68 considerable amount of concern in the Internet community. The 69 recommended approach [6] [10] to deal with this issue is first to 70 analyze the impact of these attacks on the different Internet 71 protocols that use hash functions and second to make sure that the 72 different Internet protocols that use hash functions are capable of 73 migrating to an alternative (more secure) hash function without a 74 major disruption in the Internet operation. 76 This document performs such analysis for the Cryptographically 77 Generated Addresses (hereafter CGAs) defined in [2]. The first 78 conclusion of the analysis is that the security of the protocols 79 using CGAs is not affected by the recently available attacks against 80 hash functions. The second conclusion of the analysis is that the 81 hash function used is hard coded in the CGA specification. This 82 document updates the CGA specification [2] to enable the support of 83 alternative hash functions. In order to do so, this documents 84 creates a new registry managed by IANA to register the different hash 85 algorithms used in CGAs. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [1]. 93 3. Impact of collision attacks in CGAs 95 Recent advances in cryptography have resulted in simplified attacks 96 against the collision-free property of certain commonly used hash 97 functions [6] [10], including SHA-1 that is the hash function used by 98 CGAs [2]. The result is that it is possible to obtain two messages 99 M1 and M2 that have the same hash value with much less than 2^(L/2) 100 attempts. We will next analyze the impact of such attacks in the 101 currently proposed usages of CGAs. 103 As we understand it, the attacks against the collision-free property 104 of a hash function mostly challenge the application of such hash 105 function for the provision of non-repudiation capabilities. This is 106 so because an attacker would be capable to create two different 107 messages that result in the same hash value and it can then present 108 any of the messages interchangeably (for example after one of them 109 has been signed by the other party involved in the transaction). 110 However, it must be noted that both messages must be generated by the 111 same party. 113 As far as we understand, current usages of CGAs does not include the 114 provision of non-repudiation capabilities, so attacks against the 115 collision-free property of the hash function do not enable any useful 116 attack against CGA-based protocols. 118 Current usages of the CGAs are basically oriented to prove the 119 ownership of a CGA and then bind it to alternative addresses that can 120 be used to reach the original CGA. This type of application of the 121 CGA include: 122 o The application of CGAs to protect the shim6 protocol [7]. In 123 this case, CGAs are used as identifiers for the established 124 communications. CGA features are used to prove that the owner of 125 the identifier is the one that is providing the alternative 126 addresses that can be used to reach the initial identifier. This 127 is achieved by signing the list of alternative addresses available 128 in the multihomed host with the private key of the CGA. 129 o The application of CGAs to secure the IPv6 mobility support 130 protocol [8] as proposed in [9]. In this case, the CGAs are used 131 as Home Addresses and they are used to prove that the owner of the 132 Home Address is the one creating the binding with the new Care-off 133 Address. Similarly to the previous case, this is achieved by 134 signing the Binding Update message carrying the Care-off Address 135 with the private key of the CGA. 136 o The application of CGA to Secure Neighbour Discovery [4]. In this 137 case, the CGA features are used to prove the address ownership, so 138 that it is possible to verify that the owner of the IP address is 139 the one that is providing layer 2 address information. This is 140 achieved by signing the layer 2 address information with the 141 private key of the CGA. 143 Essentially, all the current applications of CGAs rely on CGAs to 144 protect a communication between two peers from third party attacks 145 and not to provide protection from the peer itself. Attacks against 146 the collision-free property of the hash functions suppose that one of 147 the parties is generating two messages with the same hash value in 148 order to launch an attack against its communicating peer. Since CGAs 149 are not currently used to provide this type of protection, it is then 150 natural that no additional attacks are enabled by a weaker collision 151 resistance of the hash function. 153 4. Options for Multiple Hash Algorithm Support in CGAs 155 CGAs as currently defined in [2] are intrinsically bound to the SHA-1 156 hash algorithm and no other hash function is supported. 158 Even though the attacks against the collision-free property of the 159 hash functions does not result in new vulnerabilities in the current 160 applications of CGAs, it seems wise to enable multiple hash function 161 support in CGAs. This is so mainly for two reasons: first, potential 162 future applications of the CGA technology may be susceptible to 163 attacks against the collision-free property of SHA-1. Supporting 164 alternative hash functions would allow applications which have 165 stricter requirements on the collision-free property to use CGAs. 166 Second, one lesson learned from the recent attacks against hash 167 functions is that it is possible that one day we need to move to 168 alternative hash functions because of successful attacks against 169 other properties of the commonly used hash functions. Because of 170 that, it seems wise to modify protocols in general and the CGAs in 171 particular to support this transition to alternative hash functions 172 as easy as possible. 174 4.1. Where to encode the hash function? 176 The next question we need to answer is where to encode the hash 177 function used. There are several options that can be considered: 179 One option would be to include the hash function used as an input to 180 the hash function. This basically means to create an extension to 181 the CGA Parameter Data Structure as defined in [3] that codifies the 182 hash function used. The problem is that this approach is vulnerable 183 to bidding down attacks or downgrading attacks as defined in [10]. 184 This means that even if a stronger hash function is used, an attacker 185 could find a CGA Parameter Data Structure which hash value using the 186 weaker function is the same than the original hash value (created 187 using the stronger hash function). 189 In other words, the downgrading attack would work as follows: suppose 190 that Alice generates a CGA CGA_A using the strong hash function 191 HashStrong using a CGA Parameter Data Structure CGA_PDS_A The 192 selected hash function HashStrong is encoded as an extension field in 193 the CGA_PDS_A. Suppose that an attacker X finds, using a brute force 194 attack, an alternative CGA Parameter Data Structure CGA_PDS_X which 195 hash value, using a weaker hash function, is CGA_A. At this point the 196 attacker can pretend to be the owner of CGA_A and the stronger hash 197 function has not provided additional protection. 199 The conclusion from the previous analysis is that the hash function 200 used in the CGA generation must be encoded in the address itself. 201 Since we want to support several hash functions, we are likely to 202 need at least at least 2 or 3 bits for this. 204 One option would be to use more bits from the hash bits of the 205 interface identifier. The problem with this approach is that the 206 resulting CGA is weaker because less hash information is encoded in 207 the address. In addition, since those bits are currently used as 208 hash bits, it is impossible to make this approach backward compatible 209 with existent implementations. Another option would be to use the 210 "u" and the "g" bits to encode this information, but this is probably 211 not such a good idea, since those bits have been honoured so far in 212 all interface identifier generation mechanisms which allow them to be 213 used for the original purpose (for instance we can still create a 214 global registry for unique interface identifiers). Finally another 215 option is to encode the hash value used in the Sec bits. The Sec 216 bits are used to artificially introduce additional difficulty in the 217 CGA generation process in order to provide additional protection 218 against brute force attacks. The Sec bits have been designed in a 219 way that the lifetime of CGAs are extended when it is feasible to 220 attack 59 bits long hash values. However, this is not the case 221 today, so in general CGA will have a Sec value of 000. The proposal 222 is to encode in the Sec bits, not only information about brute force 223 attack protection but also to encode the hash function used to 224 generate the hash. So for instance the Sec value 000 would mean that 225 the hash function used is SHA-1 and that 0 bits of hash2 (as defined 226 in RFC3972) must be 0. Sec value of 001 could be that the hash 227 function used is SHA-1 and that 16 bits of hash2 (as defined in 228 RFC3972) must be zero. However, the other values of Sec could mean 229 that an alternative hash function needs to be used and that a certain 230 amount of bits of hash2 must be zero. The proposal is not to define 231 any concrete hash function to be used for other Sec values since it 232 is not clear yet that we need to do so nor is it clear which hash 233 function should be selected. 235 It should be noted that since there are only 8 Sec values, it may be 236 needed to reuse Sec values when we run out of unused Sec values. The 237 scenario where such approach can make sense is where there are some 238 Sec values that are no longer being used because the resulting 239 security has become weak. In this case, where the usage of the Sec 240 value has long been abandoned, it would be possible to reassign the 241 Sec values. However, this must be a last resource option, since it 242 may affect interoperability. This is because two implementations 243 using different meaning of a given Sec value would not be able to 244 interoperate properly (i.e. if an old implementation receives a CGA 245 generated with the new meaning of the Sec value, it will fail and the 246 same for a new implementation receiving a CGA generated with the old 247 meaning of the Sec value). In case the approach of reassigning a Sec 248 value is followed, a long time is required between the deprecation of 249 the old value and the reassignment in order to prevent 250 misinterpretation of the value by old implementations. 252 Erroneous interpretation of a re-used Sec value, both on the CGA 253 owner's side and the CGA verifier's side, would have the following 254 results: CGA verification would fail in the worst case and both nodes 255 would have to revert to unprotected IPv6 addresses. This can happen 256 only with obsolete CGA parameter sets, which would be considered 257 insecure anyway. In any case, an implementation must not support two 258 different meanings of a Sec value simultaneously. 260 5. CGA generation procedure 262 The SEC registry defined in the IANA considerations section of this 263 document contains entries for the different Sec values. Each of this 264 entries points to a RFC that defines the CGA generation procedure 265 that MUST be used when generating CGAs with the associated Sec value. 267 It should be noted that the CGA generation procedure may be changed 268 by the new procedure not only in terms of the hash function used but 269 also in other aspects, e.g. longer Modifier values may be required if 270 the number of 0s required in Hash2 exceed the currently defined bound 271 of 112 bits. The new procedure (which potentially involves a longer 272 Modifier value) would be described in the RFC pointed to by the 273 corresponding Sec registry entry. 275 In addition, the RFC that defines the CGA generation procedure for a 276 Sec value MUST explicitly define the minimum key length acceptable 277 for CGAs with that Sec value. This is so to provide a coherent 278 protection both in the hash and the public key techniques. 280 6. IANA considerations 282 This document defines a new registry entitled "CGA SEC" for the Sec 283 field defined in RFC 3972 [2] that is to be created and maintained by 284 IANA. The values in this name space are 3-bit unsigned integers. 286 Initial values for the CGA Extension Type field are given below; 287 future assignments are to be made through Standards Action [5]. 288 Assignments consist of a name, the value and the RFC number where the 289 CGA generation procedure is defined. 291 The following initial assignments are done in this document: 293 Name | Value | RFC 294 -------------------+-------+------ 295 SHA-1_0hash2bits | 000 | 3972 296 SHA-1_16hash2bits | 001 | 3972 297 SHA-1_32hash2bits | 010 | 3972 299 7. Security considerations 301 All this note considers security issues and in particular protection 302 against potential attacks against hash functions. 304 8. Acknowledgements 306 Russ Housley, James Kempf, Christian Vogt, Pekka Nikander and Henrik 307 Levkowetz reviewed and provided comments about this document. 309 Marcelo Bagnulo worked on this document while visiting Ericsson 310 Research Laboratory Nomadiclab. 312 9. References 314 9.1. Normative References 316 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 317 Levels", BCP 14, RFC 2119, March 1997. 319 [2] Aura, T., "Cryptographically Generated Addresses (CGA)", 320 RFC 3972, March 2005. 322 [3] Bagnulo, M. and J. Arkko, "Cryptographically Generated 323 Addresses (CGA) Extension Field Format", RFC 4581, 324 October 2006. 326 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 327 Neighbor Discovery (SEND)", RFC 3971, March 2005. 329 9.2. Informative References 331 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 332 Considerations Section in RFCs", BCP 26, RFC 2434, 333 October 1998. 335 [6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes 336 in Internet Protocols", RFC 4270, November 2005. 338 [7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 339 draft-ietf-shim6-l3shim (work in progress), November 2006. 341 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 342 IPv6", RFC 3775, June 2004. 344 [9] Arkko, J., "Applying Cryptographically Generated Addresses and 345 Credit-Based Authorization to Mobile IPv6", 346 draft-arkko-mipshop-cga-cba-03 (work in progress), March 2006. 348 [10] Bellovin, S. and E. Rescorla, "Deploying a new hash algorithm", 349 2005 September. 351 Authors' Addresses 353 Marcelo Bagnulo 354 Universidad Carlos III de Madrid 355 Av. Universidad 30 356 Leganes, Madrid 28911 357 SPAIN 359 Phone: 34 91 6249500 360 Email: marcelo@it.uc3m.es 361 URI: http://www.it.uc3m.es 363 Jari Arkko 364 Ericsson 365 Jorvas 02420 366 Finland 368 Email: jari.arkko@ericsson.com 370 Full Copyright Statement 372 Copyright (C) The IETF Trust (2007). 374 This document is subject to the rights, licenses and restrictions 375 contained in BCP 78, and except as set forth therein, the authors 376 retain all their rights. 378 This document and the information contained herein are provided on an 379 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 380 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 381 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 382 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 383 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 384 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 386 Intellectual Property 388 The IETF takes no position regarding the validity or scope of any 389 Intellectual Property Rights or other rights that might be claimed to 390 pertain to the implementation or use of the technology described in 391 this document or the extent to which any license under such rights 392 might or might not be available; nor does it represent that it has 393 made any independent effort to identify any such rights. Information 394 on the procedures with respect to rights in RFC documents can be 395 found in BCP 78 and BCP 79. 397 Copies of IPR disclosures made to the IETF Secretariat and any 398 assurances of licenses to be made available, or the result of an 399 attempt made to obtain a general license or permission for the use of 400 such proprietary rights by implementers or users of this 401 specification can be obtained from the IETF on-line IPR repository at 402 http://www.ietf.org/ipr. 404 The IETF invites any interested party to bring to its attention any 405 copyrights, patents or patent applications, or other proprietary 406 rights that may cover technology that may be required to implement 407 this standard. Please address the information to the IETF at 408 ietf-ipr@ietf.org. 410 Acknowledgment 412 Funding for the RFC Editor function is provided by the IETF 413 Administrative Support Activity (IASA).