idnits 2.17.1 draft-kukec-csi-hash-threat-02.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 438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (July 1, 2008) is 5779 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 94 looks like a reference -- Missing reference section? 'X509-COLL' on line 127 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 Expires: January 2, 2009 S. Krishnan 5 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 July 1, 2008 10 SeND Hash Threat Analysis 11 draft-kukec-csi-hash-threat-02 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 January 2, 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. Based on previous analysis, 45 this document suggests multiple hash support that should be included 46 in the SeND update specification. 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 4.1. Hash algorithm option . . . . . . . . . . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . . . 15 68 1. Introduction 70 SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents 71 of the Key Hash and the Digital Signature fields of the RSA 72 signature. It also uses a hash algorithm (SHA-1,MD5 etc.) in the 73 PKIX certificates [rfc3280] used for router authorization. Recently 74 there have been demonstrated attacks against the collision free 75 property of such hash functions [sha1-coll]. There have also been 76 attacks on the PKIX X.509 certificates that use the MD5 hash 77 algorithm [x509-coll] that allow an attacker to generate two 78 different certificates with different distinguished names and 79 different public keys that contain identical signatures. This 80 document analyzes the effects of such attacks on the SEND protocol 81 and proposes changes to make it resistant to such attacks. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [rfc2119]. 89 3. Impact of collision attacks on SeND 91 Due to the collision attacks demonstrated on the aforesaid hash 92 algorithms a study was performed to assess the threat of these 93 attacks on the cryptographic hash usage in internet protocols 94 [RFC4270]. This document analyzes the hash usage in SEND following 95 the approach recommended by [rfc4270]. Following the approach 96 recommended by [rfc4270] and [new-hashes], we will analyze the impact 97 of these attacks on SeND case by case in this section. Through our 98 analysis, whether we should support hash agility on SeND is also 99 discussed. 101 Up to date, all demonstrated attacks are attacks against a collision- 102 free property. Attacks against the one-way property are not yet 103 feasible [rfc4270]. 105 3.1. Attacks against CGAs in stateless autoconfiguration 107 Hash functions are used in the stateless autoconfiguration process 108 that is based on CGAs. Impacts of collision attacks on current uses 109 of CGAs are analyzed in the update of CGA specification [rfc4982], 110 which also enables CGAs to support hash agility. CGAs provide proof- 111 of-ownership of the private key corresponding to the public key used 112 to generate CGA, and they don't deal with the non-repudiation 113 feature, while collision attacks are mainly about affecting non- 114 repudiation feature. While SeND is CGA based protocol, we are sure 115 that the node that signs the message is the same as the node that 116 creates the message and associated hash. So, as [rfc4982] points out 117 CGA based protocols, including SeND, are not affected by the recent 118 collision attacks. 120 3.2. Attacks against PKIX certificates in ADD process 122 The second use of hash functions is for router authorization in ADD 123 process. Router sends to host a certification path, which is a path 124 between a router and hosts's trust anchor and consists of PKIX 125 certificates. Researchers demonstrated attacks against PKIX 126 certificates with MD5 signature, in 2005 [new-hashes] and in 2007 127 [X509-COLL]. 129 In 2005 they succeeded to construct the original and the false 130 certificate that had the same identity data and digital signature, 131 but different public keys [new-hashes]. The problem for the attacker 132 is that two certificates with the same identity are not very useful 133 in real-world scenarios, while Certification Authority is not allowed 134 to provide such two certificates. Additionally, since identity field 135 is humane readable data, certificates are not affected by collision 136 attacks in practice. Implementations SHOULD use human-readable 137 certificate extensions only if SeND certificate profile demands. We 138 also have to take into account that attacker could produce such false 139 certificate only if he could predict context- useful certificate 140 data. So, although collision attacks against PKIX certificates are 141 theoretically possible, they can hardly be performed in practice. 143 In 2007 were demonstrated certificates with the same identity data 144 and signatures, which differed only in public keys. Such attacks are 145 potentially more dangerous, since attacker can decide about contents 146 of human readable fields, and produce for example certificates with 147 the same signatures, but different identities or validity periods. 148 However, in order to perform a real-world useful attack, attacker 149 still needs to predict the content of all fields appearing before the 150 public key, eg. serial number or validity periods. Although a 151 relying party cannot verify the content of these fields (each 152 certificate by itself is unsuspicious), the CA keeps track of those 153 fields and during the fraud analysis, the false certificate can be 154 revealed. 156 Generally, the most dangerous are attacks against middle-certificates 157 in the certification path, where for the cost of one false 158 certificate, attacker launches attack on multiple routers. In such 159 scenarios, we will be at least safe from attacks against Trust 160 Anchor's certificate because it is not exchanged in SeND messages. 161 Additionally, if attacker, for example, manages to produce a false 162 certificate with changed IP prefixes in IP subjectAltName extension 163 (which is currently just theoretically possible), IP prefixes range 164 will be broadened at maximum to the range from the Trust Anchor's 165 certificate. 167 3.3. Attacks against Digital Signature in RSA Signature option 169 Digital signature in RSA Signature option is produced as the SHA-1 170 hash of IPv6 addresses, ICMPv6 header, ND message and other fields 171 like Message Type Tag and ND options [rfc3971], and is signed with 172 the sender's private key, which corresponds to the public key from 173 the CGA parameters structure and is authorized usually through CGAs. 174 The possible attack on such explicit digital signature is typical 175 non-repudiation attack. Attacker could generate a false message with 176 the same hash and sign that false hashed message with authorized 177 private key. However, the problem for the attacker is that they are 178 very hard to predict the useful input data. It minimizes the 179 possibility for a real-world collision attack and the fact that in 180 order to perform a succesful real-world attack he can not change a 181 human-readable data. But we also have to take into account that a 182 variant of SHA-1 was already affected by recent collision attacks and 183 we have to prepare for future improved attacks. 185 3.4. Attacks against Key Hash in RSA Signature option 187 Key Hash field in the RSA Signature option is a SHA-1 hash of the 188 public key from the CGA parameters structure in the CGA option of 189 SeND message. Key Hash field is a typical example of data 190 fingerprinting, which is potentially dangerous because input field is 191 a non human-readable data. But the problem for the attacker is that 192 a public key, which is input data is authorized through CGAs, and 193 sometimes additionally through a certification path if peer has 194 configured trust anchor. For the succesful attack, attacker has to 195 break both SHA-1 hashed public key, as well as corresponding CGA and 196 possibly a certification path. Otherwise, changed key pair will be 197 detected in the process of CGA verification. The same as in previous 198 cases, this attack is theoretically possible, but very hard to 199 perform in practice. 201 4. Support for the hash agility in SeND 203 While all of analyzed hash functions in SeND are theoretically 204 affected by recent collision attacks, these attacks indicate the 205 possibility of future real-world attacks. In order to increase the 206 future security of SeND, we suggest the support for the hash and 207 algorithm agility in SeND. 209 The most effective and secure would be to bind the hash function 210 option with something that can not be changed at all, like [rfc4982] 211 does for CGA - encoding the hash function information into addresses. 212 But, there is no possibilty to do that in SeND. We could decide to 213 use by default the same hash function in SeND as in CGA, but this 214 solution is architecturally strange and it does not really increase 215 the security since the difficulty for attackers remain to break one 216 single hash function. Furthermore, it may even reduce the security 217 level by providing more relevant information of the hash function. 218 On the other side, the use of two different hash algorithms makes 219 attacker's life harder. 221 Another solution is to incorporate the hash function option into SeND 222 message. By putting a new hash function option in SeND message 223 before RSA Signature option, attacker will have to break both the 224 signature and the hash input at the same time since the new option 225 will be input field for the Digital Signature in RSA Signature 226 option. However, we can not avoid a downgrade attack totally because 227 peer might be using just ND and not SeND. A completely safe solution 228 here does not exist. A new hash function option in SeND message is a 229 reasonable and the best solution for the hash algorithm agility 230 support in SeND. 232 Each implementation SHOULD use different hash or signature algorithms 233 for each of the relevant fields (Key Hash field, Digital Signature, 234 PKIX signature algorithm). Since all algorithms are in different 235 procedures, making them the same does not make those procedures 236 simpler, but making them different complicates possible attacks. 238 4.1. Hash algorithm option 240 In order to provide hash algorithm agility, each SeND implemenation 241 MUST support the Hash algorithm option. The Hash algorithm option 242 defines: 244 o a hash algorithm that MUST be used for producing the RSA Signature 245 option (Key Hash field) - HA-KH, 247 o a hash algorithm that MUST be used for producing the RSA Signature 248 option (Digital Signature field) - HA-DS, 250 o a PKIX signature algorithm that the sender of the Hash algorithm 251 option is ready to accept and validate. In order to enhance 252 interoperability, implementations SHOULD also accept and validate 253 PKIX certificates with a signature algorithm that has the higher 254 encoding number than requested signature algorithm. 255 Implementations MUST NOT accept PKIX certificates with signature 256 algorithms marked with lower encoding. 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | HA-KH | HA-DS | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | SA | Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 1 268 Type 270 TBA1 272 Length 274 The length of the option (including the Type, Length, Reserved, 275 HA, SA, and Padding) in units of 8 octets. 277 Hash Algorithm for Key Hash field (HA-KH) 279 Hash algorithm used for producing the Key Hash field in the RSA 280 Signature option. SEND [rfc3971] uses SHA-a. In order to provide 281 hash algorithm agility, SHA-1 is assigned an initial value TBD1 in 282 this document. 284 Hash Algorithm for Digital Signature field (HA-DS) 286 Hash algorithm used for producing the Digital Signature field in 287 the RSA Signature option. SEND [rfc3971] uses SHA-1. In order to 288 provide hash algorithm agility, SHA-1 is assigned an initial value 289 TBD2 in this document. 291 Signature Algorithm (SA) 293 Signature algorithm of the PKIX certificate used in ADD process, 294 in accordance with rfc3279. SEND [rfc3971] uses RSASSA-PKCS1-v1_5 295 algorithm. In order to provide algorithm agility, RSASSA_PKCS1- 296 v1_5 is assigned an initial value TBD3 in this document. 298 Reserved 300 Field reserved for future uses. The value MUST be initialized to 301 zero by the sender, and MUST be ignored by the recepient. 303 5. Security Considerations 305 This document analyzes the impact of hash attacks in SeND and offeres 306 a higher security level for SeND by providing solution for the hash 307 agility support. 309 6. IANA Considerations 311 This document defines three new registries that have been created and 312 are maintained by IANA. 314 o Hash Algorithm for Key Hash field (HA-KH). The values in this 315 name space are 5-bit unsigned integers. 317 o Hash Algorithm for Digital Signature field (HA-DS). The values in 318 this name space are 5-bit unsigned integers. 320 o Signature Algorithm (SA). The values in this name space are 5-bit 321 unsigned integers. 323 Initial values for these registries are given below. Future 324 assignments are to be made through Standards Action [rfc2434]. 325 Assignments for each registry consist of a name, a value and a RFC 326 number where the registry is defined. 328 The following initial values are assigned for HA-KH in this document: 330 Name | Value | RFCs 331 -------------------+-------+------------ 332 SHA-1 | TBD1 | this document 334 The following initial values are assigned for HA-DS in this document: 336 Name | Value | RFCs 337 -------------------+-------+------------ 338 SHA-1 | TBD2 | this document 340 The following initial values are assigned for HA-KH in this document: 342 Name | Value | RFCs 343 -------------------+-------+------------ 344 RSASSA-PKCS1-v1_5 | TBD3 | this document 346 This document defines one new Neighbor Discovery Protocol [rfc4861] 347 options, which must be assigned Option Type values within the option 348 numbering space for Neighbor Discovery Protocol messages: 350 The Hash algorithm option (TBA1), described in Section 4.1. 352 7. References 354 7.1. Normative References 356 [new-hashes] 357 Bellovin, S. and E. Rescorla, "Deploying a New Hash 358 Algorithm", November 2005. 360 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 361 Neighbor Discovery (SEND)", RFC 3971, March 2005. 363 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 364 Hashed in Internet Protocols", RFC 4270, November 2005. 366 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 367 Algorithms in Cryptographically Generated Addresses 368 (CGAs)", RFC 4982, July 2007. 370 7.2. Informative References 372 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", RFC 2119, March 1997. 375 [rfc2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 376 IANA Considerations Section in RFCs", RFC 2434, 377 April 1998. 379 [rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure 380 Certificate and Certificate Revocation List (CRL) 381 Profile", RFC rfc3280, April 2002. 383 [rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Solliman, 384 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 385 April 1998. 387 [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 389 [sha1-coll] 390 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 391 Full SHA-1. CRYPTO 2005: 17-36", 2005. 393 [x509-coll] 394 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 395 Collisions for MD5 and Colliding X.509 Certificates for 396 Different Identitites. EUROCRYPT 2007: 1-22", 2005. 398 Authors' Addresses 400 Ana Kukec 401 University of Zagreb 402 Unska 3 403 Zagreb 404 Croatia 406 Email: ana.kukec@fer.hr 408 Suresh Krishnan 409 Ericsson 410 8400 Decarie Blvd. 411 Town of Mount Royal, QC 412 Canada 414 Email: suresh.krishnan@ericsson.com 416 Sheng Jiang 417 Huawei Technologies Co., Ltd 418 KuiKe Building, No.9 Xinxi Rd., 419 Shang-Di Information Industry Base, Hai-Dian District, Beijing 420 P.R. China 422 Email: shengjiang@huawei.com 424 Full Copyright Statement 426 Copyright (C) The IETF Trust (2008). 428 This document is subject to the rights, licenses and restrictions 429 contained in BCP 78, and except as set forth therein, the authors 430 retain all their rights. 432 This document and the information contained herein are provided on an 433 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 434 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 435 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 436 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 437 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 438 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Intellectual Property 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org.