idnits 2.17.1 draft-ietf-csi-hash-threat-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 12, 2010) is 5186 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 127 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: August 16, 2010 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 February 12, 2010 10 SEND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-06 13 Abstract 15 This document analysis the use of hashes in SEND, possible threats 16 and the impact of recent attacks on hash functions used by SEND. 17 Current SEND specification [rfc3971] uses the SHA-1 [sha-1] hash 18 algorithm and X.509 certificates [rfc5280] and does not provide 19 support for the hash algorithm agility. The purpose of the document 20 is to provide analysis of possible hash threats and to decide how to 21 encode the hash agility support in SEND. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 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 August 16, 2010. 46 Copyright Notice 48 Copyright (c) 2010 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 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Impact of collision attacks on SEND . . . . . . . . . . . . . 6 78 3.1. Attacks against CGAs in stateless autoconfiguration . . . 6 79 3.2. Attacks against X.509 certificates in ADD process . . . . 7 80 3.3. Attacks against the Digital Signature in the RSA 81 Signature option . . . . . . . . . . . . . . . . . . . . . 8 82 3.4. Attacks against the Key Hash field in the RSA 83 Signature option . . . . . . . . . . . . . . . . . . . . . 8 84 4. Support for the hash agility in SEND . . . . . . . . . . . . . 9 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 SEND [rfc3971] uses the hash algorithm in different ways. It uses 94 the SHA-1 hash algorithm to generate Cryptographically Generated 95 Addresses (CGA) [rfc3972], the contents of the Key Hash field and the 96 Digital Signature field of the RSA Signature option. It also uses a 97 hash algorithm (SHA-1, MD5, etc.) within the digital signature in the 98 X.509 certificates [rfc5280] for the router authorization in the 99 Authorizaton Delegation Discovery (ADD) process. 101 There is a great variaty of hash function, but only MD5 and SHA-1 are 102 in the wide use. They both derive from MD4, which has been well 103 known for its weaknesses. First hash attacks affected the 104 compression function of MD5, while the latest hash attacks against 105 SHA-1 delivered colliding hash in significantlly smaller number of 106 rounds compared to the brute force attack number of rounds 107 [sha1-coll]. Attacks against X.509 certificates improved as well, 108 and researchers demonstrated colliding certificate with MD5 hash, 109 both for the same and different identities [x509-coll]. 111 Depending on the way of use of hash algorithm, Internet protocol can 112 be affected by the weakness of the underlaying hash function. This 113 document analyzes uses of hash algorithms in SEND, possible weakness 114 that hash attacks could introduce to SEND, and possible ways to make 115 SEND resistant to such attacks. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [rfc2119]. 123 3. Impact of collision attacks on SEND 125 Due to the hash attacks demonstrated on the aforesaid hash algorithms 126 a study was performed to assess the threat of these attacks on the 127 cryptographic hash usage in internet protocols [RFC4270]. This 128 document analyzes the hash usage in SEND following the recommended 129 approach [rfc4270] [new-hashes]. 131 Basic cryptographic properties of a hash function are that it is both 132 one-way and collision free. There are two attacks against the one- 133 way property, the first-preimage attack and the second-preimage 134 attack. In the first-preimage attack, given a knowledge of a 135 particular hash value h, an attacker finds an input message m such 136 that hash(m) = h. The second-preimage attack deals with fixed 137 messages. Given a knowledge of a fixed value m used as the input 138 message to the hash function, an attacker finds a different value m' 139 that yields hash(m)=hash(m'). Supposing that the hash function 140 produces an n-bit long output, since each output is equally likely, 141 an attack takes an order of 2^n operations to be successful. Due to 142 the birthday attack, if the hash function is supplied with a random 143 input, it returns one of the k equally-likely values, and the number 144 of operations can be reduced to the number of 1.2*2^(n/2) operations. 145 Attack against the collision-free property deals with two fixed 146 messages, both produced by an attacker. Attacker produces two 147 different messages, m and m', such that hash(m)=hash(m'). Up to 148 date, all demonstrated attacks are attacks against a collision-free 149 property. Attacks against the one-way property are not yet feasible 150 [rfc4270]. 152 The strength of Internet protocol does not have to be necessarily 153 affected by the weakness of the underlaying hash function. The 154 appropriate way of use of the hash algorithm will keep the protocol 155 immune, no matter of the hash algorithm weaknesses. Out of many 156 possible hash algorithm uses, such as non-repudiable digital 157 signatures, certificate digital signatures, message authentication 158 with shared secrets, fingerprints, only the first two can introduce 159 weaknesses to the Internet protocol [rfc4270]. The rest of the 160 section analyzes the impact of hash attacks, mainly collision 161 attacks, on SEND by the cases of use. Through our analysis, we also 162 discuss whether we should support the hash agility in SEND. 164 3.1. Attacks against CGAs in stateless autoconfiguration 166 Hash functions are used in the stateless autoconfiguration process 167 that is based on CGAs. Impacts of collision attacks on current uses 168 of CGAs and the CGA hash agility are analyzed in the update of the 169 CGA specification [rfc4982]. CGAs provide the proof-of-ownership of 170 the private key corresponding to the public key used to generate the 171 CGA. The collision attack against the CGA assume that attacker 172 generates two different sets of CGA Parameters that result in the 173 same hash value. Since CGAs do not deal with the non-repudiation 174 feature, and both sets are chosen by the attacker, this attack is not 175 useful in any real-world scenario. CGA-based protocols, including 176 SEND, are not affected by the recent collision attacks. If pre-image 177 attacks were feasible, an attacker would find colliding CGA 178 Parameters for the victim's CGA, and produce the Key Hash field and 179 the Digital Signature field afterwards using the new public key. 180 Since the strength of all hashes in SEND depends on the strength of 181 the CGA, the pre-image attack is potentially dangerous, but it is not 182 yet feasible. 184 3.2. Attacks against X.509 certificates in ADD process 186 Another use of hash functions is for the router authorization in the 187 ADD process. Router sends to a host a certification path, which is a 188 path between a router and the host's trust anchor, consisting of 189 X.509 certificates. Researchers demonstrated attacks against X.509 190 certificates with MD5 signature in 2005 [new-hashes] and in 2007 191 [x509-coll]. In 2005 researchers constructed colliding certificates 192 with the same distinguished name, different public keys, and 193 identical signatures, based on different public keys. The problem 194 for the attacker is that two certificates with the same identity are 195 not actually useful in real-world scenarios, because the 196 Certification Authority can take care of not allowing to provide such 197 two certificates. In addition, attacks against the human-readable 198 fields demand much more effort than the attacks against non human- 199 readable fields, such as a public key field. In case of the identity 200 field, an attacker is faced with the problem of the prediction and 201 the generation of the false but meaningful identity data, which at 202 the end might be revealed by the Certification Authority. Thus, in 203 practice, there is a very low probability that collision attacks 204 affect non human-readable parts of the certificate. In 2007 205 researchers demonstrated colliding certificates which differ in the 206 identity data and in the public key, but still result in the same 207 signature value. Even in this case, the real-world scenarios prevent 208 the hash algorithm weaknesses to introduce vulnerabilities of the 209 certificate or the protocol. Even if an attacker produced such two 210 colliding certificates in order to claim that he was someone else, he 211 still needs to predict the content of all fields appearing before the 212 public key, e.g. the serial number and validity periods. Although a 213 relying party cannot verify the content of these fields (each 214 certificate by itself is unsuspicious), the Certification Authority 215 keeps track of those fields and it can reveal the false certificate 216 during the fraud analysis. Even though the real-world scenarios make 217 SEND immune to recent hash attacks introduced through X.509 218 certificates, theoretically they are possible, but only in case of 219 the human-readable fields. Regarding X.509 certificates in SEND, 220 biggest concer are attacks against the RFC3779 IP address extension 221 which would enable the bogus router to advertize the changed IP 222 prefix range, if the IP prefix range used, although, not broader than 223 the prefix range of the parent certificate in the ADD chain. Adding 224 some form of randomness to human-readble data would prevent such 225 attacks, which can be considered once when the collision attack 226 improve. 228 3.3. Attacks against the Digital Signature in the RSA Signature option 230 The computation of the Digital Signature field is described 231 [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses, 232 the ICMPv6 header, the ND message and other fields, e.g. the Message 233 Type Tag and ND options, and signed with the sender's private key. 234 Private key corresponds to the public key in the CGA parameters 235 structure. It is usually authorized through CGAs. The Digital 236 Signature field is vulnerable to recent collision attacks. Possible 237 attack on such explicit digital signature is a typical non- 238 repudiation attack. An attacker produces two different messages, m 239 and m', where hash(m) = hash(m'). He underlays one of the messages 240 to be signed with the key authorized through CGAs, but uses another 241 message afterwards. However, the structure of at least one of two 242 messages in a collision attack is strictly predefined. The previous 243 requirement makes this collision attack to be much more then the 244 simple collision attack, and requires the attacker to know or predict 245 the communication context. Theoretically this attack could harm 246 SEND, but in real-world situation is extremely hard to achieve it. 248 3.4. Attacks against the Key Hash field in the RSA Signature option 250 The Key Hash field in the RSA Signature option is a SHA-1 hash of the 251 public key from the CGA Parameters structure in the CGA option. It 252 is a fingerprint that provides the integrity protection. 253 Fingerprints are generally not affected by the collision attacks 254 because they involve random data as one of the inputs, which prevents 255 recent collision attacks. In addition, context of the SEND message 256 and the protocol makes this attack unable to introduce new 257 vulnerabilities to SEND. An attacker has to produce both keys, k and 258 k', such that hash(k) = hash(k'). Since the key is authorized 259 through CGA, and possibily through the certification in the ADD 260 process, this attack is of no use for the attacker. The pre-image 261 attack against the Key Hash field, if it was possible, would affect 262 SEND since the Key Hash field contains a non human-readable data. 264 4. Support for the hash agility in SEND 266 Previous section analyzed that CGAs and fingerprints affected by the 267 collision attacks (Key Hash field of the Send message) do not 268 introduce new vulnerabilities to SEND. Digital signatures in the 269 Digital Signature field of the SEND message and X.509 certificate 270 theoretically are affected by the recent collision attacks, but the 271 SEND context prevents those attacks of almost any use in the real- 272 world scenarios. However, recent attacks indicate the possibility 273 for the future improved real-world attacks. Researchers advise to 274 migrate away from currently used hash algorithms. In order to 275 increase the future security of SEND, we suggest the support for the 276 hash and algorithm agility in SEND. 278 o The most effective and secure would be to bind the hash function 279 option with something that can not be changed at all, like 280 [rfc4982] does for CGA. It encodes the hash function information 281 into addresses. We could decide to use by default the same hash 282 function in SEND as in CGA. The security of all hashes in SEND 283 depends on CGA, i.e. if an attacker breaks CGA, all other hashes 284 are automatically broken. The use of the hash algorithm embedded 285 in CGA protects from the bidding down attacks. From the security 286 point of view, at the moment, this solution is more reasonable 287 then defining different hash algorithm for each hash. The 288 disadvantage of this solution is that it introduces the limitation 289 for SEND to be used exclusively with CGAs. 291 o Another solution is to incorporate the Hash algorithm option into 292 the SEND message. This solution is vulnerable to the bidding down 293 attack. 295 o The third possible solution is to encode the algorithm in the CGA. 296 This would reduce the strength of the CGA and make it vulnerable 297 to brute force attacks. 299 o Possible solution is also the hybrid solution which would require 300 the hash algorithm to be the same as CGA, if CGA option is 301 present, and to use the Hash agility option if the CGA option is 302 not present. In such way, SEND is not bound exclusively to CGA. 304 o None of the previous solutions supports the negotiation of the 305 hash function. One of possible solutions is the negotiation 306 approach for the SEND hash agility based on the Supported 307 Signature Algorithm option described in [sig-agility]. Based on 308 the processing rules described in [sig-agility] nodes find the 309 intersection between the sender's and the receiver's supported 310 signature algorithms set. 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-01 (work in progress), 352 May 2010. 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