idnits 2.17.1 draft-kukec-csi-hash-threat-01.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 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. 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 (June 26, 2008) is 5775 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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: December 28, 2008 S. Krishnan 5 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 June 26, 2008 10 SeND Hash Threat Analysis 11 draft-kukec-csi-hash-threat-01 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 December 28, 2008. 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 . . . . . 6 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 The most common uses of hash functions are non-repudiable digital 71 signatures on messages and digital signatures on certificates. Both 72 are affected by recent collision attacks and both are used in SeND 73 [rfc4270]. SeND uses SHA-1 hash algorithm to produce contents of the 74 RSA Signature option in ND message (Digital Signature field and Key 75 Hash field). PKIX certificates are used for the router authorization 76 in Authorization Delegation Discovery (ADD) process. Hash functions 77 are also used in the statless autoconfiguration process that is based 78 on CGAs. 80 Theoretically, all mentioned uses of hash functions are affected by 81 recent collision attacks. According to our analysis in this 82 document, none of these attacks are currently doable. But we have to 83 take into account that future attacks will be improved and provide a 84 support for multiple hash algorithms. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [rfc2119]. 92 3. Impact of collision attacks on SeND 94 "Hash algorithms are used by cryptographers in a variety of security 95 protocols, for a variety of purposes, at all levels of the Internet 96 protocol stack. They are used because they have two security 97 properties: to be one way and collision free." "The recent attacks 98 have demonstrated that one of those security properties is not 99 true."[rfc4270] Following the approach recommended by [rfc4270] and 100 [new-hashes], we will analyze the impact of these attacks on SeND 101 case by case in this section. Through our analysis, whether we 102 should support hash agility on SeND is also discussed. 104 Up to date, all demonstrated attacks are attacks against a collision- 105 free property. Attacks against the one-way property are not yet 106 feasible [rfc4270]. 108 3.1. Attacks against CGAs in stateless autoconfiguration 110 Hash functions are used in the stateless autoconfiguration process 111 that is based on CGAs. Impacts of collision attacks on current uses 112 of CGAs are analyzed in the update of CGA specification [rfc4982], 113 which also enables CGAs to support hash agility. CGAs provide proof- 114 of-ownership of the private key corresponding to the public key used 115 to generate CGA, and they don't deal with the non-repudiation 116 feature, while collision attacks are mainly about affecting non- 117 repudiation feature. While SeND is CGA based protocol, we are sure 118 that the node that signes the message is the same as the node that 119 creates the message and associated hash. So, as [rfc4982] points out 120 CGA based protocols, including SeND, are not affected by the recent 121 collision attacks. 123 3.2. Attacks against PKIX certificates in ADD process 125 The second use of hash functions is for router auhtorization in ADD 126 process. Router sends to host a certification path, which is a path 127 between a router and hosts's trust anchor and consists of PKIX 128 certificates. Researchers demonstrated attack against PKIX 129 certificates with MD5 signature. They succeded to construct the 130 original and the false certificate that had the same identity data 131 and digital signature, but different public key [new-hashes]. The 132 problem for the attacker is that two certificates with the same 133 identity are not very useful in real-world scenarios, while 134 Certification Authority is not allowed to provide such two 135 certificates. Additionally, most certificate parts are not in danger 136 because human-readable certificate fields are not affected by the 137 collision attacks. However, implementations SHOULD use human- 138 readable certificate extensions only if SeND certificate profile 139 demands. We also have to take into account that attacker could 140 produce such false certificate only if he could predict context- 141 useful certificate data. So, although collision attacks against PKIX 142 certificates are theoretically possible, they can hardly be performed 143 in practice. 145 However, if attacker succeeds to perform attack, once in future when 146 attacks will be improved, the most dangerous will be attacks against 147 middle-certificates in the certification path, where for the cost of 148 one false certificate, attacker launches attack on multiple routers. 149 In such scenarios, We will be at least safe from attacks against 150 Trust Anchor's certificate because it is not exchanged in SeND 151 messages. If attacker, for example, will manage to produce a false 152 certificate with changed IP prefixes in IP subjectAltName extension 153 (which is currently just theoretically possible), IP prefixes range 154 will be broadened at maximum to the range from the Trust Anchor's 155 certificate. 157 3.3. Attacks against Digital Signature in RSA Signature option 159 Digital signature in RSA Signature option is produced as the SHA-1 160 hash of IPv6 addresses, ICMPv6 header and ND message and is signed 161 with the sender's private key, which corresponds to the public key 162 from the CGA parameters structure and is authorized usually through 163 CGAs. The possible attack on such explicit digital signature is 164 typical non-repudiation attack. Attacker could generate a false 165 message with the same hash and sign that false hashed message with 166 authorized private key. However, the problem for the attacker is 167 that they are very hard to predict the useful input data. It 168 minimizes the possibility for a real-world collision attack and the 169 fact that in order to perform a succesfull real-world attack he can 170 not change a human-readable data. But we also have to take into 171 account that a variant of SHA-1 was already affected by recent 172 collision attacks and we have to prepare for future improved attacks. 174 3.4. Attacks against Key Hash in RSA Signature option 176 Key Hash field in the RSA Signature option is a SHA-1 hash of the 177 public key from the CGA parameters structure in the CGA option of 178 SeND message. Key Hash field is a typical example of data 179 fingerprinting, which is potentially dangerous because input field is 180 a non human-readable data. But the problem for the attacker is that 181 a public key, which is input data is authorized through CGAs, and 182 sometimes additionally through a certification path if peer has 183 configured trust anchor. For the succesfull attack, attacker has to 184 break both SHA-1 hashed public key, as well as corresponding CGA and 185 possiblly a certification path. Otherwise, changed key pair will be 186 detected in the process of CGA verification. The same as in previous 187 cases, this attack is theoretically possible, but very hard to 188 perform in practice. 190 4. Support for the hash agility in SeND 192 While all of analyzed hash functions in SeND are theoretically 193 affected by recent collision attacks, these attacks indicate the 194 possibility of future real-world attacks. In order to increase the 195 future security of SeND, we suggest the support for the hash and 196 algorithm agility in SeND. 198 The most effective and secure would be to bind the hash function 199 option with something that can not be changed at all, like [rfc4982] 200 does for CGA - encoding the hash function information into addresses. 201 But, there is no possibilty to do that in SeND. We could decide to 202 use by default the same hash function in SeND as in CGA, but this 203 solution is architecturally strange and it does not really increase 204 the security since the difficulty for attackers remain to break one 205 single hash function. Furthermore, it may even reduce the security 206 level by providing more relevant information of the hash function. 207 On the other side, the use of two different hash algorithms makes 208 attacker's life harder. 210 Another solution is to incorporate the hash function option into SeND 211 message. By putting a new hash function option in SeND message 212 before RSA Signature option, attacker will have to break both the 213 signature and the hash input at the same time since the new option 214 will be input field for the Digital Signature in RSA Signature 215 option. However, we can not avoid a downgrade attack totally because 216 peer might be using just ND and not SeND. A completely safe solution 217 here does not exist. A new hash function option in SeND message is a 218 reasonable and the best solution for the hash algorithm agility 219 support in SeND. 221 Each implementation SHOULD use different hash or signature algorithms 222 for each of the relevant fields (Key Hash field, Digital Signature, 223 PKIX signature algorithm). Since all algorithms are in different 224 procedures, making them the same does not make those procedures 225 simpler, but making them different complicates possible attacks. 227 4.1. Hash algorithm option 229 In order to provide hash algorithm agility, each SeND implemenation 230 MUST support the Hash algorithm option. The Hash algorithm option 231 defines: 233 o a hash algorithm that MUST be used for producing the RSA Signature 234 option (Key Hash field) - HA-KH, 236 o a hash algorithm that MUST be used for producing the RSA Signature 237 option (Digital Signature field) - HA-DS, 239 o a PKIX signature algorithm that the sender of the Hash algorithm 240 option is ready to accept and validate. In order to enhance 241 interoperability, implementations SHOULD also accept and validate 242 PKIX certificates with a signature algorithm that has the higher 243 encoding number than requested signature algorithm. 244 Implementations MUST NOT accept PKIX certificates with signature 245 algorithms marked with lower encoding. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type | Length | Reserved | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | HA-KH | HA-DS | SA | Padding | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 1 257 Type 259 31 261 Length 263 The length of the option (including the Type, Length, Reserved, 264 HA, SA, and Padding) in units of 8 octets. 266 Reserved 268 A 16-bit field reserved for future use. The value MUST be 269 initialized to zero by the sender, and MUST be ignored by the 270 received. 272 Hash Algorithm for Key Hash field (HA-KH) 274 Hash algorithm used for producing the Key Hash field in the RSA 275 Signature option. SEND [rfc3971] uses SHA-a. In order to provide 276 hash algorithm agility, SHA-1 is assigned an initial value 00000 277 in this document. 279 Hash Algorithm for Digital Signature field (HA-DS) 281 Hash algorithm used for producing the Digital Signature field in 282 the RSA Signature option. SEND [rfc3971] uses SHA-1. In order to 283 provide hash algorithm agility, SHA-1 is assigned an initial value 284 00000 in this document. 286 Signature Algorithm (SA) 288 Signature algorithm of the PKIX certificate used in ADD process, 289 in accordance with rfc3279. SEND [rfc3971] uses RSASSA-PKCS1-v1_5 290 algorithm. In order to provide algorithm agility, RSASSA_PKCS1- 291 v1_5 is assigned an initial value 00000 in this document. 293 5. Security Considerations 295 This document analyzes the impact of hash attacks in SeND and offeres 296 a higher security level for SeND by providing solution for the hash 297 agility support. 299 6. IANA Considerations 301 This document defines three new registries that have been created and 302 are maintained by IANA. 304 o Hash Algorithm for Key Hash field (HA-KH). The values in this 305 name space are 5-bit unsigned integers. 307 o Hash Algorithm for Digital Signature field (HA-DS). The values in 308 this name space are 5-bit unsigned integers. 310 o Signature Algorithm (SA). The values in this name space are 5-bit 311 unsigned integers. 313 Initial values for these registries are given below. Future 314 assignments are to be made through Standards Action [rfc2434]. 315 Assignments for each registry consist of a name, a value and a RFC 316 number where the registry is defined. 318 The following initial values are assigned for HA-KH in this document: 320 Name | Value | RFCs 321 -------------------+-------+------------ 322 SHA-1 | 00000 | this document 324 The following initial values are assigned for HA-DS in this document: 326 Name | Value | RFCs 327 -------------------+-------+------------ 328 SHA-1 | 00000 | this document 330 The following initial values are assigned for HA-KH in this document: 332 Name | Value | RFCs 333 -------------------+-------+------------ 334 RSASSA-PKCS1-v1_5 | 00000 | this document 336 This document defines one new Neighbor Discovery Protocol [rfc2461] 337 options, which must be assigned Option Type values within the option 338 numbering space for Neighbor Discovery Protocol messages: 340 The Hash algorithm option (31), described in Section 4.1. 342 7. References 344 7.1. Normative References 346 [new-hashes] 347 Bellovin, S. and E. Rescorla, "Deploying a New Hash 348 Algorithm", November 2005. 350 [rfc3971] A, J., K, J., Z, B., and P. N, "SEcure Neighbor Discovery 351 (SEND)", RFC 3971, March 2005. 353 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 354 Hashed in Internet Protocols", RFC 4270, November 2005. 356 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 357 Algorithms in Cryptographically Generated Addresses 358 (CGAs)", RFC 4982, July 2007. 360 7.2. Informative References 362 [rfc2119] Kent, S. and K. Seo, "Security Architecture for the 363 Internet Protocol", RFC 2119, December 2005. 365 [rfc2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 366 IANA Considerations Section in RFCs", RFC 2434, 367 April 1998. 369 [rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 370 Discovery for IP Version 6 (IPv6)", RFC 2461, April 1998. 372 [rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure 373 Certificate and Certificate Revocation List (CRL) 374 Profile", RFC rfc3280, April 2002. 376 [sha-1] K, S. and K. S, "Secure Hash Standard, FIBS PUB 180-1", 377 RFC 4301, April 1995. 379 Authors' Addresses 381 Ana Kukec 382 University of Zagreb 383 Unska 3 384 Zagreb 385 Croatia 387 Email: ana.kukec@fer.hr 389 Suresh Krishnan 390 Ericsson 391 8400 Decarie Blvd. 392 Town of Mount Royal, QC 393 Canada 395 Email: suresh.krishnan@ericsson.com 397 Sheng Jiang 398 Huawei Technologies Co., Ltd 399 KuiKe Building, No.9 Xinxi Rd., 400 Shang-Di Information Industry Base, Hai-Dian District, Beijing 401 P.R. China 403 Email: shengjiang@huawei.com 405 Full Copyright Statement 407 Copyright (C) The IETF Trust (2008). 409 This document is subject to the rights, licenses and restrictions 410 contained in BCP 78, and except as set forth therein, the authors 411 retain all their rights. 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 416 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 417 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 418 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Intellectual Property 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at 443 ietf-ipr@ietf.org.