idnits 2.17.1 draft-kukec-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 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 4, 2008) is 5797 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? '14' on line 307 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 6, 2008 S. Krishnan 5 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 June 4, 2008 10 SeND Hash Threat Analysis 11 draft-kukec-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 December 6, 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 . . . . . . . . . . . . . . . . . . . 10 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . . . 13 67 1. Introduction 69 The most common uses of hash functions are non-repudiable digital 70 signatures on messages and digital signatures on certificates. Both 71 are affected by recent collision attacks and both are used in SeND 72 [rfc4270]. SeND uses SHA-1 hash algorithm to produce contents of the 73 RSA Signature option in ND message (Digital Signature field and Key 74 Hash field). PKIX certificates are used for the router authorization 75 in Authorization Delegation Discovery (ADD) process. Hash functions 76 are also used in the statless autoconfiguration process that is based 77 on CGAs. 79 Theoretically, all mentioned uses of hash functions are affected by 80 recent collision attacks. According to our analysis in this 81 document, none of these attacks are currently doable. But we have to 82 take into account that future attacks will be improved and provide a 83 support for multiple hash algorithms. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [rfc2119]. 91 3. Impact of collision attacks on SeND 93 "Hash algorithms are used by cryptographers in a variety of security 94 protocols, for a variety of purposes, at all levels of the Internet 95 protocol stack. They are used because they have two security 96 properties: to be one way and collision free." "The recent attacks 97 have demonstrated that one of those security properties is not 98 true."[rfc4270] Following the approach recommended by [rfc4270] and 99 [new-hashes], we will analyze the impact of these attacks on SeND 100 case by case in this section. Through our analysis, whether we 101 should support hash agility on SeND is also discussed. 103 Up to date, all demonstrated attacks are attacks against a collision- 104 free property. Attacks against the one-way property are not yet 105 feasible [rfc4270]. 107 3.1. Attacks against CGAs in stateless autoconfiguration 109 Hash functions are used in the stateless autoconfiguration process 110 that is based on CGAs. Impacts of collision attacks on current uses 111 of CGAs are analyzed in the update of CGA specification [rfc4982], 112 which also enables CGAs to support hash agility. CGAs provide proof- 113 of-ownership of the private key corresponding to the public key used 114 to generate CGA, and they don't deal with the non-repudiation 115 feature, while collision attacks are mainly about affecting non- 116 repudiation feature. While SeND is CGA based protocol, we are sure 117 that the node that signes the message is the same as the node that 118 creates the message and associated hash. So, as [rfc4982] points out 119 CGA based protocols, including SeND, are not affected by the recent 120 collision attacks. 122 3.2. Attacks against PKIX certificates in ADD process 124 The second use of hash functions is for router auhtorization in ADD 125 process. Router sends to host a certification path, which is a path 126 between a router and hosts's trust anchor and consists of PKIX 127 certificates. Researchers demonstrated attack against PKIX 128 certificates with MD5 signature. They succeded to construct the 129 original and the false certificate that had the same identity data 130 and digital signature, but different public key [new-hashes]. The 131 problem for the attacker is that two certificates with the same 132 identity are not very useful in real-world scenarios, while 133 Certification Authority is not allowed to provide such two 134 certificates. Additionally, most certificate parts are not in danger 135 because human-readable certificate fields are not affected by the 136 collision attacks. However, implementations SHOULD use human- 137 readable certificate extensions only if SeND certificate profile 138 demands. We also have to take into account that attacker could 139 produce such false certificate only if he could predict context- 140 useful certificate data. So, although collision attacks against PKIX 141 certificates are theoretically possible, they can hardly be performed 142 in practice. 144 However, if attacker succeeds to perform attack, once in future when 145 attacks will be improved, the most dangerous will be attacks against 146 middle-certificates in the certification path, where for the cost of 147 one false certificate, attacker launches attack on multiple routers. 148 In such scenarios, We will be at least safe from attacks against 149 Trust Anchor's certificate because it is not exchanged in SeND 150 messages. If attacker, for example, will manage to produce a false 151 certificate with changed IP prefixes in IP subjectAltName extension 152 (which is currently just theoretically possible), IP prefixes range 153 will be broadened at maximum to the range from the Trust Anchor's 154 certificate. 156 3.3. Attacks against Digital Signature in RSA Signature option 158 Digital signature in RSA Signature option is produced as the SHA-1 159 hash of IPv6 addresses, ICMPv6 header and ND message and is signed 160 with the sender's private key, which corresponds to the public key 161 from the CGA parameters structure and is authorized usually through 162 CGAs. The possible attack on such explicit digital signature is 163 typical non-repudiation attack. Attacker could generate a false 164 message with the same hash and sign that false hashed message with 165 authorized private key. However, the problem for the attacker is 166 that they are very hard to predict the useful input data. It 167 minimizes the possibility for a real-world collision attack and the 168 fact that in order to perform a succesfull real-world attack he can 169 not change a human-readable data. But we also have to take into 170 account that a variant of SHA-1 was already affected by recent 171 collision attacks and we have to prepare for future improved attacks. 173 3.4. Attacks against Key Hash in RSA Signature option 175 Key Hash field in the RSA Signature option is a SHA-1 hash of the 176 public key from the CGA parameters structure in the CGA option of 177 SeND message. Key Hash field is a typical example of data 178 fingerprinting, which is potentially dangerous because input field is 179 a non human-readable data. But the problem for the attacker is that 180 a public key, which is input data is authorized through CGAs, and 181 sometimes additionally through a certification path if peer has 182 configured trust anchor. For the succesfull attack, attacker has to 183 break both SHA-1 hashed public key, as well as corresponding CGA and 184 possiblly a certification path. Otherwise, changed key pair will be 185 detected in the process of CGA verification. The same as in previous 186 cases, this attack is theoretically possible, but very hard to 187 perform in practice. 189 4. Support for the hash agility in SeND 191 While all of analyzed hash functions in SeND are theoretically 192 affected by recent collision attacks, these attacks indicate the 193 possibility of future real-world attacks. In order to increase the 194 future security of SeND, we suggest the support for the hash and 195 algorithm agility in SeND. 197 The most effective and secure would be to bind the hash function 198 option with something that can not be changed at all, like [rfc4982] 199 does for CGA - encoding the hash function information into addresses. 200 But, there is no possibilty to do that in SeND. We could decide to 201 use by default the same hash function in SeND as in CGA, but this 202 solution is architecturally strange and it does not really increase 203 the security since the difficulty for attackers remain to break one 204 single hash function. Furthermore, it may even reduce the security 205 level by providing more relevant information of the hash function. 206 On the other side, the use of two different hash algorithms makes 207 attacker's life harder. 209 Another solution is to incorporate the hash function option into SeND 210 message. By putting a new hash function option in SeND message 211 before RSA Signature option, attacker will have to break both the 212 signature and the hash input at the same time since the new option 213 will be input field for the Digital Signature in RSA Signature 214 option. However, we can not avoid a downgrade attack totally because 215 peer might be using just ND and not SeND. A completely safe solution 216 here does not exist. A new hash function option in SeND message is a 217 reasonable and the best solution for the hash algorithm agility 218 support in SeND. 220 4.1. Hash algorithm option 222 In order to provide hash algorithm agility, each SeND implemenation 223 MUST support the Hash algorithm option. The Hash algorithm option 224 defines: 226 o a hash algorithm that MUST be used for producing the RSA Signature 227 option (Key Hash field and Digital Signature field), 229 o a PKIX signature algorithm that the sender of the Hash algorithm 230 option is ready to accept and validate. In order to enhance 231 interoperability, implementations SHOULD also accept and validate 232 PKIX certificates with a signature algorithm that has the higher 233 encoding number than requested signature algorithm. 234 Implementations MUST NOT accept PKIX certificates with signature 235 algorithms marked with lower encoding. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | Reserved | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | HA | SA | Padding | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1 247 Type 249 13 251 Length 253 The length of the option (including the Type, Length, Reserved, 254 HA, SA, and Padding) in units of 8 octets. 256 Reserved 258 A 16-bit field reserved for future use. The value MUST be 259 initialized to zero by the sender, and MUST be ignored by the 260 received. 262 Hash Algorithm (HA) 264 Hash algorithm used for producing the Key Hash field and the 265 Digital Signature field in the RSA Signature option. E.g. 000 = 266 md5, ... 268 Signature Algorithm (SA) 270 Signature algorithm of the PKIX certificate used in ADD process, 271 in accordance with rfc3279. E.g. 0000 = md5 with RSA encryption, 272 0001 = sha with DSA encryption. 274 5. Security Considerations 276 This document analyzes the impact of hash attacks in SeND and offeres 277 a higher security level for SeND by providing solution for the hash 278 agility support. 280 6. References 282 6.1. Normative References 284 [new-hashes] 285 Bellovin, S. and E. Rescorla, "Deploying a New Hash 286 Algorithm", RFC 4270, November 2005. 288 [rfc3971] b, a. and K. S, "SEcure Neighbor Discovery (SEND)", 289 RFC 3971, March 2005. 291 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 292 Hashed in Internet Protocols", RFC 4270, November 2005. 294 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 295 Algorithms in Cryptographically Generated Addresses 296 (CGAs)", RFC 4982, July 2007. 298 6.2. Informative References 300 [rfc2119] Kent, S. and K. Seo, "Security Architecture for the 301 Internet Protocol", RFC 4301, December 2005. 303 [rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure 304 Certificate and Certificate Revocation List (CRL) 305 Profile", RFC 3280, April 2002. 307 [sha-1] K, S. and K. S, "Secure Hash Standard (see rfc3971 [14])", 308 RFC 4301, April 1995. 310 Authors' Addresses 312 Ana Kukec 313 University of Zagreb 314 Unska 3 315 Zagreb 316 Croatia 318 Email: ana.kukec@fer.hr 320 Suresh Krishnan 321 Ericsson 322 8400 Decarie Blvd. 323 Town of Mount Royal, QC 324 Canada 326 Email: suresh.krishnan@ericsson.com 328 Sheng Jiang 329 Huawei Technologies Co., Ltd 330 KuiKe Building, No.9 Xinxi Rd., 331 Shang-Di Information Industry Base, Hai-Dian District, Beijing 332 P.R. China 334 Email: shengjiang@huawei.com 336 Full Copyright Statement 338 Copyright (C) The IETF Trust (2008). 340 This document is subject to the rights, licenses and restrictions 341 contained in BCP 78, and except as set forth therein, the authors 342 retain all their rights. 344 This document and the information contained herein are provided on an 345 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 346 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 347 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 348 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 349 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 350 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 352 Intellectual Property 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be claimed to 356 pertain to the implementation or use of the technology described in 357 this document or the extent to which any license under such rights 358 might or might not be available; nor does it represent that it has 359 made any independent effort to identify any such rights. Information 360 on the procedures with respect to rights in RFC documents can be 361 found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the use of 366 such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR repository at 368 http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention any 371 copyrights, patents or patent applications, or other proprietary 372 rights that may cover technology that may be required to implement 373 this standard. Please address the information to the IETF at 374 ietf-ipr@ietf.org.