idnits 2.17.1 draft-ietf-csi-hash-threat-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (September 10, 2008) is 5707 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) -- Missing reference section? 'RFC4270' on line 90 looks like a reference -- Missing reference section? 'X509-COLL' on line 137 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kukec 3 Internet-Draft University of Zagreb 4 Intended status: Standards Track S. Krishnan 5 Expires: March 14, 2009 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 September 10, 2008 10 SeND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 14, 2009. 38 Abstract 40 This document analysis the use of hashes in SeND, possible threats 41 and the impact of recent attacks on hash functions used by SeND. 42 Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash 43 algorithm and PKIX certificates [rfc3280] and does not provide 44 support for the hash algorithm agility. The purpose of the document 45 is to provide analysis of possible hash threats and to decide how to 46 encode the hash agility support in SeND. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Impact of collision attacks on SeND . . . . . . . . . . . . . 5 53 3.1. Attacks against CGAs in stateless autoconfiguration . . . 5 54 3.2. Attacks against PKIX certificates in ADD process . . . . . 5 55 3.3. Attacks against Digital Signature in RSA Signature 56 option . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.4. Attacks against Key Hash in RSA Signature option . . . . . 7 58 4. Support for the hash agility in SeND . . . . . . . . . . . . . 8 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . . . 13 67 1. Introduction 69 SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents 70 of the Key Hash and the Digital Signature fields of the RSA 71 signature. It also uses a hash algorithm (SHA-1,MD5 etc.) in the 72 PKIX certificates [rfc3280] used for the router authorization in the 73 ADD process. Recently there have been demonstrated attacks against 74 the collision free property of such hash functions [sha1-coll]. 75 There have also been attacks on the PKIX X.509 certificates that use 76 the MD5 hash algorithm [x509-coll] This document analyzes the effects 77 of such attacks and other hash attacks on the SEND protocol and 78 proposes changes to make it resistant to such attacks. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [rfc2119]. 86 3. Impact of collision attacks on SeND 88 Due to the hash attacks demonstrated on the aforesaid hash algorithms 89 a study was performed to assess the threat of these attacks on the 90 cryptographic hash usage in internet protocols [RFC4270]. This 91 document analyzes the hash usage in SEND following the approach 92 recommended by [rfc4270]. Following the approach recommended by 93 [rfc4270] and [new-hashes], we will analyze the impact of these 94 attacks on SeND case by case in this section. Through our analysis, 95 whether we should support hash agility on SeND is also discussed. 97 Up to date, all demonstrated attacks are attacks against a collision- 98 free property. An attacker produces two messages which result in the 99 same hash. Attacks against the one-way property are not yet feasible 100 [rfc4270]. There are two attacks against one property. In the 101 first-preimage attack, based on the hash of the real message, an 102 attacker finds a false message which results in the same hash. In 103 the second-preimage attack an attacker based on the real message 104 itself, finds the false message which results in the same hash. 106 3.1. Attacks against CGAs in stateless autoconfiguration 108 Hash functions are used in the stateless autoconfiguration process 109 that is based on CGAs. Impacts of collision attacks on current uses 110 of CGAs are analyzed in the update of CGA specification [rfc4982], 111 which also enables CGAs to support hash agility. CGAs provide proof- 112 of-ownership of the private key corresponding to the public key used 113 to generate CGA, and they don't deal with the non-repudiation 114 feature, while collision attacks are mainly about affecting non- 115 repudiation feature. CGAs are not suspectable to the collision 116 attacks. In the collision attack, an attacker finds two keys (and 117 other CGA parameters) K and K', where CGA = hash(K, ..) = hash(K', 118 ..). Since both keys have to be choosen by an attacker, CGAs are not 119 vulnerable to the collision attack. So, as [rfc4982] points out CGA 120 based protocols, including SeND, are not affected by the recent 121 collision attacks. But, CGAs are vulnerable to the preimage attack 122 in which an attacker could manage to find the false key K' based on 123 node's CGA = hash(K, ..), use key K' to produce the Key Hash field 124 and to sign the SeND message afterwards. In that case, an attacker 125 just has to break the CGA, and all other hashes are automatically 126 broken, because an attacker can use the false key K' to produce all 127 other hashes. But up to date, the preimage attacks are not yet 128 feasible, but might be in the future. 130 3.2. Attacks against PKIX certificates in ADD process 132 The second use of hash functions is for the router authorization in 133 ADD process. Router sends to host a certification path, which is a 134 path between a router and hosts's trust anchor and consists of PKIX 135 certificates. Researchers demonstrated attacks against PKIX 136 certificates with MD5 signature, in 2005 [new-hashes] and in 2007 137 [X509-COLL]. 139 In 2005 they succeeded to construct the original and the false 140 certificate that had the same identity data and digital signature, 141 but different public keys [new-hashes]. The problem for the attacker 142 is that two certificates with the same identity are not very useful 143 in real-world scenarios, while Certification Authority is not allowed 144 to provide such two certificates. Additionally, since identity field 145 is humane readable data, certificates are not affected by collision 146 attacks in practice. Implementations SHOULD use human-readable 147 certificate extensions only if SeND certificate profile demands. We 148 also have to take into account that attacker could produce such false 149 certificate only if he could predict context- useful certificate 150 data. So, although collision attacks against PKIX certificates are 151 theoretically possible, they can hardly be performed in practice. 153 In 2007 were demonstrated certificates with the same identity data 154 and signatures, which differed only in public keys. Such attacks are 155 potentially more dangerous, since attacker can decide about contents 156 of human readable fields, and produce for example certificates with 157 the same signatures, but different identities or validity periods. 158 However, in order to perform a real-world useful attack, attacker 159 still needs to predict the content of all fields appearing before the 160 public key, eg. serial number or validity periods. Although a 161 relying party cannot verify the content of these fields (each 162 certificate by itself is unsuspicious), the CA keeps track of those 163 fields and during the fraud analysis, the false certificate can be 164 revealed. 166 The certificate key in SeND is used both for the CGA generation and 167 for message signing. In the future, CGA might not be used at all in 168 SeND, just certificates. Thus, attacks against certificates are 169 potentially very dangerous. Generally, the most dangerous are 170 attacks against middle-certificates in the certification path, where 171 for the cost of one false certificate, attacker launches attack on 172 multiple routers. In such scenarios, we will be at least safe from 173 attacks against Trust Anchor's certificate because it is not 174 exchanged in SeND messages. 176 3.3. Attacks against Digital Signature in RSA Signature option 178 The digital signature in RSA Signature option is produced as the 179 SHA-1 hash of IPv6 addresses, ICMPv6 header, ND message and other 180 fields like Message Type Tag and ND options [rfc3971], and is signed 181 with the sender's private key, which corresponds to the public key 182 from the CGA parameters structure and is authorized usually through 183 CGAs. The possible attack on such explicit digital signature is 184 typical non-repudiation attack. The Digital Signature field is 185 vulnerable to the collision attack. In such collision attack an 186 attacker produces two messages M and M', where hash(M) = hash(M'), 187 underlays one of the messages to be signed with authorized keys 188 (through CGAs), but uses another message afterwards. However, the 189 prediction and production of the useful content of messages M and M' 190 is just theoretically possible, since SeND message contains mostly 191 human readable data. Additionally, the structure of at least one of 192 two messages (M and M') is predefined [rfc4270]. But we have to take 193 into account that a variant of SHA-1 was already affected by recent 194 collision attacks and we have to prepare for future improved attacks. 196 3.4. Attacks against Key Hash in RSA Signature option 198 Key Hash field in the RSA Signature option is a SHA-1 hash of the 199 public key from the CGA parameters structure in the CGA option of 200 SeND message. Key Hash field is potentially dangerous because it 201 contains a non human-readable data. Since in the collision attack an 202 attacker itself chooses both keys, K and K', where hash(K) = 203 hash(K'), the Key Hash field is not suspectable to the collision 204 attack. The preimage attack in which an attacker derives the key K' 205 based on hash(K) could be theoretically more useful. But even in 206 that case, if an attacker signes the SeND message with the key K', he 207 has to break also the CGA, since the Digital Signature is verified 208 against the CGA and possibly against a certification path. 210 4. Support for the hash agility in SeND 212 While all of analyzed hash functions in SeND are theoretically 213 affected by recent hash attacks, these attacks indicate the 214 possibility of future real-world attacks. In order to increase the 215 future security of SeND, we suggest the support for the hash and 216 algorithm agility in SeND. 218 The most effective and secure would be to bind the hash function 219 option with something that can not be changed at all, like [rfc4982] 220 does for CGA - encoding the hash function information into addresses. 221 But, there is no possibilty to do that in SeND. We could decide to 222 use by default the same hash function in SeND as in CGA. The 223 security of all hashes in SeND depends on CGA, ie. if an attacker 224 could break CGA, all other hashes are automatically broken. From the 225 security point of view, at the moment, this solution is more 226 reasonable then defining different hash algorithm for each hash. 227 Additionally, if using the hash algorithm from the CGA, no bidding 228 down attacks are possible. 230 Another solution is to incorporate the Hash algorithm option into 231 SeND message, and use different hash algorithms for different hashes, 232 or the same algorithm for all hashes. As already mentioned, from the 233 security point of view, it is reasonable to define just one 234 algorithm, because additional algorithms does not increase the 235 security. If that algorithm is defined in the Hash algorithm option 236 in SeND message, it is vulnerable to the bidding down attack. On the 237 other hand, different algorithms provides additional flexibility, and 238 in the future SeND might be used completely without CGAs. 240 5. Security Considerations 242 This document analyzes the impact of hash attacks in SeND and offeres 243 a higher security level for SeND by providing solution for the hash 244 agility support. 246 6. IANA Considerations 248 This document defines three new registries that have been created and 249 are maintained by IANA. 251 o Hash Algorithm for Key Hash field (HA-KH). The values in this 252 name space are 5-bit unsigned integers. 254 o Hash Algorithm for Digital Signature field (HA-DS). The values in 255 this name space are 5-bit unsigned integers. 257 o Signature Algorithm (SA). The values in this name space are 5-bit 258 unsigned integers. 260 Initial values for these registries are given below. Future 261 assignments are to be made through Standards Action [rfc2434]. 262 Assignments for each registry consist of a name, a value and a RFC 263 number where the registry is defined. 265 The following initial values are assigned for HA-KH in this document: 267 Name | Value | RFCs 268 -------------------+-------+------------ 269 SHA-1 | TBD1 | this document 271 The following initial values are assigned for HA-DS in this document: 273 Name | Value | RFCs 274 -------------------+-------+------------ 275 SHA-1 | TBD2 | this document 277 The following initial values are assigned for HA-KH in this document: 279 Name | Value | RFCs 280 -------------------+-------+------------ 281 RSASSA-PKCS1-v1_5 | TBD3 | this document 283 This document defines one new Neighbor Discovery Protocol [rfc4861] 284 options, which must be assigned Option Type values within the option 285 numbering space for Neighbor Discovery Protocol messages: 287 The Hash algorithm option (TBA1), described in Section 4.1. 289 7. References 291 7.1. Normative References 293 [new-hashes] 294 Bellovin, S. and E. Rescorla, "Deploying a New Hash 295 Algorithm", November 2005. 297 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 298 Neighbor Discovery (SEND)", RFC 3971, March 2005. 300 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 301 Hashed in Internet Protocols", RFC 4270, November 2005. 303 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 304 Algorithms in Cryptographically Generated Addresses 305 (CGAs)", RFC 4982, July 2007. 307 7.2. Informative References 309 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", RFC 2119, March 1997. 312 [rfc2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 313 IANA Considerations Section in RFCs", RFC 2434, 314 April 1998. 316 [rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure 317 Certificate and Certificate Revocation List (CRL) 318 Profile", RFC rfc3280, April 2002. 320 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Solliman, 321 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 322 April 1998. 324 [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 326 [sha1-coll] 327 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 328 Full SHA-1. CRYPTO 2005: 17-36", 2005. 330 [x509-coll] 331 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 332 Collisions for MD5 and Colliding X.509 Certificates for 333 Different Identitites. EUROCRYPT 2007: 1-22", 2005. 335 Authors' Addresses 337 Ana Kukec 338 University of Zagreb 339 Unska 3 340 Zagreb 341 Croatia 343 Email: ana.kukec@fer.hr 345 Suresh Krishnan 346 Ericsson 347 8400 Decarie Blvd. 348 Town of Mount Royal, QC 349 Canada 351 Email: suresh.krishnan@ericsson.com 353 Sheng Jiang 354 Huawei Technologies Co., Ltd 355 KuiKe Building, No.9 Xinxi Rd., 356 Shang-Di Information Industry Base, Hai-Dian District, Beijing 357 P.R. China 359 Email: shengjiang@huawei.com 361 Full Copyright Statement 363 Copyright (C) The IETF Trust (2008). 365 This document is subject to the rights, licenses and restrictions 366 contained in BCP 78, and except as set forth therein, the authors 367 retain all their rights. 369 This document and the information contained herein are provided on an 370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 372 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 373 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 374 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 377 Intellectual Property 379 The IETF takes no position regarding the validity or scope of any 380 Intellectual Property Rights or other rights that might be claimed to 381 pertain to the implementation or use of the technology described in 382 this document or the extent to which any license under such rights 383 might or might not be available; nor does it represent that it has 384 made any independent effort to identify any such rights. Information 385 on the procedures with respect to rights in RFC documents can be 386 found in BCP 78 and BCP 79. 388 Copies of IPR disclosures made to the IETF Secretariat and any 389 assurances of licenses to be made available, or the result of an 390 attempt made to obtain a general license or permission for the use of 391 such proprietary rights by implementers or users of this 392 specification can be obtained from the IETF on-line IPR repository at 393 http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org.