idnits 2.17.1 draft-ietf-csi-hash-threat-08.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 (March 6, 2010) is 5164 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: September 7, 2010 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 March 6, 2010 10 SEND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-08 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 September 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Impact of collision attacks on SEND . . . . . . . . . . . . . 5 78 3.1. Attacks against CGAs in stateless autoconfiguration . . . 5 79 3.2. Attacks against X.509 certificates in ADD process . . . . 6 80 3.3. Attacks against the Digital Signature in the RSA 81 Signature option . . . . . . . . . . . . . . . . . . . . . 7 82 3.4. Attacks against the Key Hash field in the RSA 83 Signature option . . . . . . . . . . . . . . . . . . . . . 7 84 4. Support for the hash agility in SEND . . . . . . . . . . . . . 8 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 89 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 SEND [rfc3971] uses the SHA-1 hash algorithm to generate 95 Cryptographically Generated Addresses (CGA) [rfc3972], the contents 96 of the Key Hash field and the Digital Signature field of the RSA 97 Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.) 98 within the digital signature in X.509 certificates [rfc5280] for the 99 router authorization in the Authorizaton Delegation Discovery (ADD) 100 process. 102 There is a great variaty of hash functions, but only MD5 and SHA-1 103 are in the wide use, which is also the case for SEND. They both 104 derive from MD4, which has been well known for its weaknesses. First 105 hash attacks affected the compression function of MD5, while the 106 latest hash attacks against SHA variants delivered colliding hashes 107 in significantlly smaller number of rounds compared to the brute 108 force attack number of rounds [sha1-coll]. Apart from the 109 aforementioned hash attacks, researchers also demonstrated attacks 110 against X.509 certificates. They demonstrated colliding X.509 111 certificates with MD5 hash, both with the same and different 112 distinguished names [new-hashes] [x509-coll]. 114 Depending on the way how the Internet protocol uses the hash 115 algorithm, Internet protocol can be affected by the weakness of the 116 underlaying hash function. This document analyzes uses of hash 117 algorithms in SEND, possible vulnerabilities that hash attacks could 118 introduce to SEND, and offers suggestions on how to make SEND 119 resistant to such attacks. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [rfc2119]. 127 3. Impact of collision attacks on SEND 129 Due to the hash attacks demonstrated on the aforesaid hash algorithms 130 a study was performed to assess the threat of these attacks on the 131 cryptographic hash usage in Internet protocols. This document 132 analyzes the hash usage in SEND following the recommended approach 133 [rfc4270] [new-hashes]. 135 Basic cryptographic properties of a hash function are that it is both 136 one-way and collision free. There are two attacks against the one- 137 way property, the first-preimage attack and the second-preimage 138 attack. In the first-preimage attack, given a knowledge of a 139 particular hash value h, an attacker finds an input message m such 140 that hash(m) = h. The second-preimage attack deals with fixed 141 messages. Given a knowledge of a fixed value m used as the input 142 message to the hash function, an attacker finds a different value m' 143 that yields hash(m)=hash(m'). Supposing that the hash function 144 produces an n-bit long output, since each output is equally likely, 145 an attack takes an order of 2^n operations to be successful. Due to 146 the birthday attack, if the hash function is supplied with a random 147 input, it returns one of the k equally-likely values, and the number 148 of operations can be reduced to the number of 1.2*2^(n/2) operations. 149 Attack against the collision-free property deals with two fixed 150 messages, both produced by an attacker. What happens is that the 151 attacker produces two different messages, m and m', such that 152 hash(m)=hash(m'). Up to date, all demonstrated attacks are attacks 153 against a collision-free property. Attacks against the one-way 154 property are not yet feasible [rfc4270]. 156 The strength of Internet protocol does not have to be necessarily 157 affected by the weakness of the underlaying hash function. The 158 appropriate way of use of the hash algorithm will keep the protocol 159 immune, no matter of the hash algorithm weaknesses. Out of many 160 possible hash algorithm uses, such as non-repudiable digital 161 signatures, certificate digital signatures, message authentication 162 with shared secrets, fingerprints, only the first two can introduce 163 weaknesses to the Internet protocol [rfc4270]. The rest of the 164 section analyzes the impact of hash attacks, mainly collision 165 attacks, on SEND by the cases of use. Through our analysis, we also 166 discuss whether we should support the hash agility in SEND. 168 3.1. Attacks against CGAs in stateless autoconfiguration 170 Hash functions are used in the stateless autoconfiguration process 171 which is based on CGAs. Impacts of collision attacks on current uses 172 of CGAs and the CGA hash agility are analyzed in the update of the 173 CGA specification [rfc4982]. CGAs provide the proof-of-ownership of 174 the sender's private key corresponding to the public key used to 175 generate the CGA. Simply stated, their main purpose is to assure 176 that the sender of the message is the same as the sender of the 177 previous message. As such, CGAs do not deal with the non-repudiation 178 feature. The collision attack against the CGA assumes that the 179 attacker generates two different, colliding sets of CGA Parameters 180 that result in the same hash value. Since CGAs do not deal with the 181 non-repudiation feature, and both CGA Parameters sets are chosen by 182 the attacker itself, this attack does not introduce any 183 vulnerabilities to SEND. If pre-image attacks were feasible, an 184 attacker would find colliding CGA Parameters for the victim's CGA, 185 and produce the Key Hash field and the Digital Signature field 186 afterwards using the new public key. Since the strength of all 187 hashes in SEND depends on the strength of the CGA, the pre-image 188 attack is potentially dangerous, but it is not yet feasible. 190 3.2. Attacks against X.509 certificates in ADD process 192 Another use of hash functions is for the router authorization in the 193 ADD process. Router sends to a host a certification path, which is a 194 path between a router and the host's trust anchor, consisting of 195 X.509 certificates. Researchers demonstrated attacks against X.509 196 certificates with MD5 signature in 2005 [new-hashes] and in 2007 197 [x509-coll]. In 2005 researchers constructed colliding certificates 198 with the same distinguished name, different public keys, and 199 identical signatures. Potential problem for the attacker here is 200 that two certificates with the same identity can be easily revealed 201 by the appropriately configured Certification Authority that does not 202 allowe to provide two certificates with the same identities. Human- 203 readable fields significantly complicate the attack. In case of the 204 identity field an attacker is faced with the problem of the 205 prediction and the generation of the two different, false but 206 meaningful identities, which at the end might be revealed by the 207 Certification Authority. Thus, although theoretically possible, 208 real-world circumstances such as the context of the human-readable 209 fields, make these attacks with colliding certificates with the same 210 identities impossible. In 2007 researchers demonstrated colliding 211 certificates which differ in the identity data and in the public key, 212 but still result in the same signature value. Even in this case, the 213 real-world scenarios prevent the hash algorithm weaknesses to 214 introduce vulnerabilities to X.509 certificates or to SEND. Even if 215 an attacker produced such two colliding certificates in order to 216 claim that he was someone else, he still needs to predict the content 217 of all fields (some of them are human-readable fields) appearing 218 before the public key, e.g. the serial number and validity periods. 219 Although a relying party cannot verify the content of these fields 220 (each certificate by itself is unsuspicious), the Certification 221 Authority keeps track of those fields and it can reveal the false 222 certificate during the fraud analysis. Even though real-world 223 scenarios make SEND immune to recent hash attacks introduced through 224 X.509 certificates, theoretically they are possible. Regarding X.509 225 certificates in SEND, biggest concer are potential attacks against 226 the RFC3779 IP address extension which would enable the bogus router 227 to advertize the changed IP prefix range (if the IP prefix range 228 used), although, not broader than the prefix range of the parent 229 certificate in the ADD chain. Adding some form of randomness to the 230 such human-readble data such would prevent attacks, which can be 231 considered once when the collision attack improve. 233 3.3. Attacks against the Digital Signature in the RSA Signature option 235 The computation of the Digital Signature field is described 236 [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses, 237 the ICMPv6 header, the ND message and other fields, e.g. the Message 238 Type Tag and ND options, and signed with the sender's private key. 239 Private key corresponds to the public key in the CGA parameters 240 structure. It is usually authorized through CGAs. The Digital 241 Signature field the example of the non-repudiation digital singature, 242 and it is vulnerable to recent collision attacks. Possible attacks 243 on such explicit digital signature is a typical non-repudiation 244 attack in which the attacker produces two different messages, m and 245 m', where hash(m) = hash(m'). He underlays one of the messages to be 246 signed with the key authorized through CGAs, but uses another message 247 afterwards. However, the structure of at least one of two messages 248 in a collision attack is strictly predefined. The previous 249 requirement makes this collision attack to be much more then the 250 simple collision attack. It requires the attacker to know or predict 251 the communication context. Theoretically this attack could harm 252 SEND, but in real-world situation is to achieve it. 254 3.4. Attacks against the Key Hash field in the RSA Signature option 256 The Key Hash field in the RSA Signature option is a SHA-1 hash of the 257 public key from the CGA Parameters structure in the CGA option. It 258 is a fingerprint that provides the integrity protection. 259 Fingerprints are generally not affected by the collision attacks 260 because they involve random data as one of the inputs, which prevents 261 recent collision attacks. In addition, context of the SEND message 262 and the protocol makes this attack unable to introduce new 263 vulnerabilities to SEND. An attacker has to produce both keys, k and 264 k', such that hash(k) = hash(k'). Since the key is authorized 265 through CGA, and possibily through the certification in the ADD 266 process, this attack is of no use for the attacker. The pre-image 267 attack against the Key Hash field, if it was possible, would affect 268 SEND since the Key Hash field contains a non human-readable data. 270 4. Support for the hash agility in SEND 272 Previous section showed that recent hash attacks against CGAs and 273 fingerprints (Key Hash field of the Send message) do not introduce 274 new vulnerabilities to SEND. Digital signatures in the Digital 275 Signature field of the SEND message and in the X.509 certificate 276 theoretically could introduce new vulnerabilities to SEND, but only 277 in limited circumstances. SEND context prevents those attacks of 278 almost any use in the real-world scenarios. 280 However, recent attacks indicate the possibility for the future 281 improved real-world attacks. Researchers advise to migrate away from 282 currently used hash algorithms. In November 2007, NIST announced an 283 opened competition for a new SHA-3 function. The selection of a 284 winning function will be in 2012. In order to increase the future 285 security of SEND, we suggest the support for the hash and algorithm 286 agility in SEND. 288 o The most effective and secure would be to bind the hash function 289 option with something that can not be changed at all, like 290 [rfc4982] does for CGA. It encodes the hash function information 291 into addresses. We could decide to use by default the same hash 292 function in SEND as in CGA. The security of all hashes in SEND 293 depends on CGA, i.e. if an attacker breaks CGA, all other hashes 294 are automatically broken. The use of the hash algorithm embedded 295 in CGA protects from the bidding down attacks. From the security 296 point of view, at the moment, this solution is more reasonable 297 then defining different hash algorithm for each hash. The 298 disadvantage of this solution is that it introduces the limitation 299 for SEND to be used exclusively with CGAs. 301 o Another solution is to incorporate the Hash algorithm option into 302 the SEND message. This solution is vulnerable to the bidding down 303 attack. 305 o The third possible solution is to encode the algorithm in the CGA. 306 This would reduce the strength of the CGA and make it vulnerable 307 to brute force attacks. 309 o Possible solution is also the hybrid solution which would require 310 the hash algorithm to be the same as CGA, if CGA option is 311 present, and to use the Hash agility option if the CGA option is 312 not present. In such way, SEND is not bound exclusively to CGA. 314 o None of the previous solutions supports the negotiation of the 315 hash function. One of possible solutions is the negotiation 316 approach for the SEND hash agility based on the Supported 317 Signature Algorithm option described in [sig-agility]. Based on 318 the processing rules described in [sig-agility] nodes find the 319 intersection between the sender's and the receiver's supported 320 signature algorithms set. 322 5. Security Considerations 324 This document analyzes the impact of hash attacks in SEND and offeres 325 a higher security level for SEND by providing solution for the hash 326 agility support. 328 The negotiation approach for the hash agility in SEND based on the 329 Supported Signature Algorithms option is vulnerable to bidding-down 330 attacks, which is usual in the case of any negotiation approach. 331 This issue can be mitigated with the appropriate local policies. 333 6. Security Considerations 335 There are no IANA actions resulting from this document. 337 7. References 339 7.1. Normative References 341 [new-hashes] 342 Bellovin, S. and E. Rescorla, "Deploying a New Hash 343 Algorithm", November 2005. 345 [pk-agility] 346 Cheneau, T., Maknavicius, M., Sean, S., and M. Vanderveen, 347 "Support for Multiple Signature Algorithms in 348 Cryptographically generated Addresses (CGAs)", 349 draft-cheneau-cga-pk-agility-00 (work in progress), 350 February 2009. 352 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 353 Neighbor Discovery (SEND)", RFC 3971, March 2005. 355 [rfc3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 356 RFC 3972, March 2005. 358 [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 359 Hashed in Internet Protocols", RFC 4270, November 2005. 361 [rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash 362 Algorithms in Cryptographically Generated Addresses 363 (CGAs)", RFC 4982, July 2007. 365 [sig-agility] 366 Cheneau, T. and M. Maknavicius, "Signature Algorithm 367 Agility in the Secure Neighbor Discovery (SEND) Protocol", 368 draft-cheneau-send-sig-agility-01 (work in progress), 369 May 2010. 371 7.2. Informative References 373 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", RFC 2119, March 1997. 376 [rfc5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 377 Housley, R., and W. Polk, "Internet X.509 Public Key 378 Infrastructure Certificate and Certificate Revocation List 379 (CRL) Profile", RFC rfc5280, May 2008. 381 [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 383 [sha1-coll] 384 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 385 Full SHA-1. CRYPTO 2005: 17-36", 2005. 387 [x509-coll] 388 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 389 Collisions for MD5 and Colliding X.509 Certificates for 390 Different Identitites. EUROCRYPT 2007: 1-22", 2005. 392 Authors' Addresses 394 Ana Kukec 395 University of Zagreb 396 Unska 3 397 Zagreb 398 Croatia 400 Email: ana.kukec@fer.hr 402 Suresh Krishnan 403 Ericsson 404 8400 Decarie Blvd. 405 Town of Mount Royal, QC 406 Canada 408 Email: suresh.krishnan@ericsson.com 410 Sheng Jiang 411 Huawei Technologies Co., Ltd 412 KuiKe Building, No.9 Xinxi Rd., 413 Shang-Di Information Industry Base, Hai-Dian District, Beijing 414 P.R. China 416 Email: shengjiang@huawei.com