idnits 2.17.1 draft-ietf-csi-hash-threat-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4270' on line 109 looks like a reference -- Missing reference section? 'X509-COLL' on line 165 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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: Informational S. Krishnan 5 Expires: September 10, 2009 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 March 9, 2009 10 SeND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-03 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 10, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document analysis the use of hashes in SeND, possible threats 60 and the impact of recent attacks on hash functions used by SeND. 61 Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash 62 algorithm and PKIX certificates [rfc5280] and does not provide 63 support for the hash algorithm agility. The purpose of the document 64 is to provide analysis of possible hash threats and to decide how to 65 encode the hash agility support in SeND. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Impact of collision attacks on SeND . . . . . . . . . . . . . 6 72 3.1. Attacks against CGAs in stateless autoconfiguration . . . 6 73 3.2. Attacks against PKIX certificates in ADD process . . . . . 7 74 3.3. Attacks against the Digital Signature in the SEND 75 Universal Signature option . . . . . . . . . . . . . . . . 8 76 3.4. Attacks against the Key Hash in the SEND Universal 77 Signature option . . . . . . . . . . . . . . . . . . . . . 8 78 4. Support for the hash agility in SeND . . . . . . . . . . . . . 9 79 4.1. The negotiation approach for the SEND hash agility . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents 89 of the Key Hash field and the Digital Signature field of the RSA 90 Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.) 91 in the PKIX certificates [rfc5280] used for the router authorization 92 in the ADD process. Recently there have been demonstrated attacks 93 against the collision free property of such hash functions 94 [sha1-coll], and attacks on the PKIX X.509 certificates that use the 95 MD5 hash algorithm [x509-coll] This document analyzes the effects of 96 those attacks and other possible hash attacks on the SEND protocol. 97 The document proposes changes to make it resistant to such attacks. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [rfc2119]. 105 3. Impact of collision attacks on SeND 107 Due to the hash attacks demonstrated on the aforesaid hash algorithms 108 a study was performed to assess the threat of these attacks on the 109 cryptographic hash usage in internet protocols [RFC4270]. This 110 document analyzes the hash usage in SEND following the approach 111 recommended by [rfc4270] and [new-hashes]. 113 The basic cryptographic properties of a hash function are that it is 114 both one-way and collision free. There are two attacks against the 115 one-way property, the first-preimage attack and the second-preimage 116 attack. In the first-preimage attack, given a knowledge of a 117 particular value hash(m), an attacker finds an input message m' such 118 that hash(m') yields hash(m). The second-preimage attack deals with 119 the fixed messages. Given a knowledge of a fixed value m used as the 120 input message to the hash function, an attacker finds a different 121 value m' that yields hash(m)=hash(m'). Supposing that the hash 122 function produces an n-bit long output, since each output is equally 123 likely, an attack takes an order of 2^n operations to be successful. 124 Due to the birthday attack, if the hash function is supplied with a 125 random input, it returns one of the k equally-likely values, and the 126 number of operations can be reduced to the number of 1.2*2^(n/2) 127 operations. However, attacks against the one-way property are not 128 yet feasible [rfc4270]. Up to date, all demonstrated attacks are 129 attacks against a collision-free property, in which an attacker 130 produces two different messages m and m' such that hash(m)=hash(m'). 132 We will analyze the impact of hash attacks on SeND case by case in 133 this section. Through our analysis, we also discuss whether we 134 should support the hash agility in SeND. 136 3.1. Attacks against CGAs in stateless autoconfiguration 138 Hash functions are used in the stateless autoconfiguration process 139 that is based on CGAs. Impacts of collision attacks on current uses 140 of CGAs are analyzed in the update of the CGA specification 141 [rfc4982], which also enables CGAs to support the hash agility. CGAs 142 provide the proof-of-ownership of the private key corresponding to 143 the public key used to generate the CGA. CGAs do not deal with the 144 non-repudiation feature, while collision attacks are mainly about 145 affecting the non-repudiation feature, i.e. in the collision attack 146 against the CGA both of the CGA Parameters sets are choosen by an 147 attacker, which is not useful in the real-world scenarios. 148 Therefore, as [rfc4982] points out CGA based protocols, including 149 SeND, are not affected by the recent collision attacks. Regarding 150 the pre-image attacks, if pre-image attacks were feasible, an 151 attacker would manage to find the new CGA Parameters based on the 152 associated, victim's CGA, and produce the Key Hash field and the 153 Digital Signature field afterwards using the new public key. Since 154 the strength of all hashes in SEND depends on the strength of the 155 CGA, the pre-image attack is potentially dangerous, but it is not yet 156 feasible. 158 3.2. Attacks against PKIX certificates in ADD process 160 The second use of hash functions is for the router authorization in 161 the ADD process. Router sends to a host a certification path, which 162 is a path between a router and the hosts's trust anchor, consisting 163 of PKIX certificates. Researchers demonstrated attacks against PKIX 164 certificates with MD5 signature, in 2005 [new-hashes] and in 2007 165 [X509-COLL]. In 2005 were constructed the original and the false 166 certificate that had the same identity data and the same digital 167 signature, but different public keys [new-hashes]. The problem for 168 the attacker is that two certificates with the same identity are not 169 actually useful in real-world scenarios, because the Certification 170 Authority is not allowed to provide such two certificates. In 171 addition, attacks against the human-readable fields demand much more 172 effort than the attacks against non human-readable fields, such as a 173 public key field. In case of the identity field, an attacker is 174 faced with the problem of the prediction and the generation of the 175 false but meaningful identity data, which at the end might be 176 revealed by the Certification Authority. Thus, in practice, 177 collision attacks do not affect non human-readable parts of the 178 certificate. In 2007 were demonstrated certificates which differ in 179 the identity data and in the public key, but still result in the same 180 signature value. In such attack, even if an attacker produced such 181 two certificates in order to claim that he was someone else, he still 182 needs to predict the content of all fields appearing before the 183 public key, e.g. the serial number and validity periods. Although a 184 relying party cannot verify the content of these fields (each 185 certificate by itself is unsuspicious), the Certification Authority 186 keeps track of those fields and it can reveal the false certificate 187 during the fraud analysis. Regarding certificates in SeND, 188 potentially dangerous are attacks against the X.509 certificate 189 extensions. For example, an attack against the IP address extension 190 would enable the router to advertize the changed IP prefix range, 191 although, not broader than the prefix range of the parent certificate 192 in the ADD chain. 194 The public-private key pair associated to the Router Authorization 195 Certificate in the ADD process is used both for the CGA generation 196 and for the message signing. Since in the future CGAs might be used 197 only with certificates, attacks against certificates are even more 198 dangerous. Generally, the most dangerous are attacks against middle- 199 certificates in the certification path, where for the cost of the one 200 false certificate, an attacker launches an attack on multiple 201 routers. Regarding the attacks against certificates in SEND, the 202 only attack that SEND is not suspectable to, is an attack against the 203 Trust Anchor's certificate because it is not exchanged in SeND 204 messages, i.e. it is not the part of the certification path in the 205 ADD process. 207 3.3. Attacks against the Digital Signature in the SEND Universal 208 Signature option 210 The SEND Universal Signature option is an updated version of the RSA 211 Signature option, defined in [sig-agility]. In combination with the 212 public key agility support described in [pk-agility], it allows the 213 node to use the public key signing algorithm different then the RSA- 214 based signing algorithm. No matter of the type of the SEND Universal 215 Signature option, the Digital Signature field is computed in the same 216 way as the Digital Signature field of the RSA Signature option 217 descibed in [rfc3971]. The digital signature in the RSA Signature 218 option is produced as the SHA-1 hash over the IPv6 addresses, the 219 ICMPv6 header, the ND message and other fields, e.g. the Message Type 220 Tag and ND options [rfc3971], that is signed with the sender's 221 private key. The sender's private key corresponds to the public key 222 in the CGA parameters structure. It is usually authorized through 223 CGAs. The possible attack on such explicit digital signature is a 224 typical non-repudiation attack, i.e. the Digital Signature field is 225 vulnerable to the collision attack. An attacker produces two 226 different messages, m and m', where hash(m) = hash(m'). He underlays 227 one of the messages to be signed with the key authorized through 228 CGAs, but uses another message afterwards. However, as denoted in 229 [rfc4270], the structure of at least one of two messages in a 230 collision attack is strictly predefined. The previous requirement 231 complicates the collision attack, but we have to take into account 232 that a variant of SHA-1 was already affected by recent collision 233 attacks and we have to prepare for future improved attacks. 235 3.4. Attacks against the Key Hash in the SEND Universal Signature 236 option 238 The Key Hash field in the SEND Universal signature option is a SHA-1 239 hash of the public key from the CGA Parameters structure in the CGA 240 option. The pre-image attack against the Key Hash field is 241 potentially dangerous, as in the case of all other hashes in SEND, 242 because the Key Hash field contains a non human-readable data. 243 However the Key Hash field is not suspectable to the collision 244 attack, since in the collision attack an attacker itself chooses both 245 keys, k and k', where hash(k) = hash(k'). The reason for the former 246 is that the associated public key is already authorized through the 247 use of CGAs, and possibly the certification path in the ADD process. 249 4. Support for the hash agility in SeND 251 While all of analyzed hash functions in SeND are theoretically 252 affected by hash attacks, these attacks indicate the possibility of 253 future real-world attacks. In order to increase the future security 254 of SeND, we suggest the support for the hash and algorithm agility in 255 SeND. 257 o The most effective and secure would be to bind the hash function 258 option with something that can not be changed at all, like 259 [rfc4982] does for CGA - encoding the hash function information 260 into addresses. But, there is no possibilty to do that in SeND. 261 We could decide to use by default the same hash function in SeND 262 as in CGA. The security of all hashes in SeND depends on CGA, ie. 263 if an attacker could break CGA, all other hashes are automatically 264 broken. From the security point of view, at the moment, this 265 solution is more reasonable then defining different hash algorithm 266 for each hash. Additionally, if using the hash algorithm from the 267 CGA, no bidding down attacks are possible. On the other hand, 268 this solution introduces the limition for SEND to be used 269 exclusively with CGAs. 271 o Another solution is to incorporate the Hash algorithm option into 272 the SeND message. However, if the algorithm is defined in the 273 Hash algorithm option in the SeND message, it is vulnerable to the 274 bidding down attack. 276 o The third possible solution is to encode the algorithm in the CGA. 277 However, this will reduce the strength of the CGAs and make them 278 vulnerable to brute force attacks. 280 o One of the possible solutions is also the hybrid solution, i.e. to 281 require the hash algorithm to be the same as CGA, if CGA option is 282 present, and to use the Hash agility option if the CGA option is 283 not present. 285 4.1. The negotiation approach for the SEND hash agility 287 None of the previous solutions supports the negotiation of the hash 288 function. Therefore we propose the negotiation approach for the SEND 289 hash agility based on the Supported Signature Algorithm option 290 described in [sig-agility]. Based on the processing rules described 291 in [sig-agility] nodes find the intersection between the sender's and 292 the receiver's supported signature algorithms set, as well as the 293 preferred signature algorithm. When producing and validating hashes 294 in SEND, nodes MUST observe the following rules: 296 o In the ADD process, if any of the certificates in the 297 certification path uses the signature algorithm which is not one 298 of the signature algorithms negotiated in the signature agility 299 process through the use of the Supported Signature Algorithms 300 option, nodes MUST reject the Router Authorization certificate. 302 o In order to produce the Digital Signature field, nodes MUST use 303 the signature algorithm negotiated in the signature agility 304 process through the use of the Supported Signature Algorithms 305 option. 307 o In order to produce the Key Hash field, nodes MUST use the hash 308 algorithm defined associated to the signature algorithm negotiated 309 in the signature agility process through the use of the Supported 310 Signature Algorithms option. 312 5. Security Considerations 314 This document analyzes the impact of hash attacks in SeND and offeres 315 a higher security level for SeND by providing solution for the hash 316 agility support. 318 The negotiation approach for the hash agility in SeND based on the 319 Supported Signature Algorithms option is vulnerable to bidding-down 320 attacks, which is usual in the case of any negotiation approach. 321 This issue can be mitigated with the appropriate local policies. 323 6. References 325 6.1. Normative References 327 [new-hashes] 328 Bellovin, S. and E. Rescorla, "Deploying a New Hash 329 Algorithm", November 2005. 331 [pk-agility] 332 Cheneau, T., Maknavicius, M., Sean, S., and M. Vanderveen, 333 "Support for Multiple Signature Algorithms in 334 Cryptographically generated Addresses (CGAs)", 335 draft-cheneau-cga-pk-agility-00 (work in progress), 336 February 2009. 338 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 339 Neighbor Discovery (SEND)", RFC 3971, March 2005. 341 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 342 Hashed in Internet Protocols", RFC 4270, November 2005. 344 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 345 Algorithms in Cryptographically Generated Addresses 346 (CGAs)", RFC 4982, July 2007. 348 [sig-agility] 349 Cheneau, T. and M. Maknavicius, "Signature Algorithm 350 Agility in the Secure Neighbor Discovery (SEND) Protocol", 351 draft-cheneau-send-sig-agility-00 (work in progress), 352 February 2009. 354 6.2. Informative References 356 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", RFC 2119, March 1997. 359 [rfc5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 360 Housley, R., and W. Polk, "Internet X.509 Public Key 361 Infrastructure Certificate and Certificate Revocation List 362 (CRL) Profile", RFC rfc5280, May 2008. 364 [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 366 [sha1-coll] 367 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 368 Full SHA-1. CRYPTO 2005: 17-36", 2005. 370 [x509-coll] 371 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 372 Collisions for MD5 and Colliding X.509 Certificates for 373 Different Identitites. EUROCRYPT 2007: 1-22", 2005. 375 Authors' Addresses 377 Ana Kukec 378 University of Zagreb 379 Unska 3 380 Zagreb 381 Croatia 383 Email: ana.kukec@fer.hr 385 Suresh Krishnan 386 Ericsson 387 8400 Decarie Blvd. 388 Town of Mount Royal, QC 389 Canada 391 Email: suresh.krishnan@ericsson.com 393 Sheng Jiang 394 Huawei Technologies Co., Ltd 395 KuiKe Building, No.9 Xinxi Rd., 396 Shang-Di Information Industry Base, Hai-Dian District, Beijing 397 P.R. China 399 Email: shengjiang@huawei.com