idnits 2.17.1 draft-ietf-csi-hash-threat-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([SHA1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (March 7, 2011) is 4796 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: Informational S. Krishnan 5 Expires: September 2, 2011 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 March 7, 2011 10 SEND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-12 13 Abstract 15 This document analyzes the use of hashes in Secure Neighbor Discovery 16 (SEND), the possible threats to these hashes and the impact of recent 17 attacks on hash functions used by SEND. The SEND specification 18 currently uses the SHA-1 hash algorithm [SHA1] and PKIX certificates 19 and does not provide support for hash algorithm agility. This 20 document provides an analysis of possible threats to the hash 21 algorithms used in SEND. 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 2, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Impact of collision attacks on SEND . . . . . . . . . . . . . . 3 59 2.1. Attacks against CGAs used in SEND . . . . . . . . . . . . . 3 60 2.2. Attacks against PKIX certificates in Authorization 61 Delegation Discovery process . . . . . . . . . . . . . . . 3 62 2.3. Attacks against the Digital Signature in the SEND RSA 63 Signature option . . . . . . . . . . . . . . . . . . . . . 4 64 2.4. Attacks against the Key Hash field of the SEND RSA 65 Signature option . . . . . . . . . . . . . . . . . . . . . 4 66 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 SEND [RFC3971] uses the SHA-1 hash algorithm to generate the contents 78 of the Key Hash field and the Digital Signature field of the RSA 79 Signature option. It also indirectly uses a hash algorithm (SHA-1, 80 MD5, etc.) in the PKIX certificates [RFC5280] used for router 81 authorization in the Authorization Delegation Discovery(ADD) process. 82 Recently there have been demonstrated attacks against the collision 83 free property of such hash functions [SHA1-COLL], and attacks on the 84 PKIX X.509 certificates that use the MD5 hash algorithm [X509-COLL]. 85 The document analyzes the impacts of these attacks on SEND and it 86 recommends mechanisms to make SEND resistant to such attacks. 88 2. Impact of collision attacks on SEND 90 [RFC4270] performed a study to assess the threat of the 91 aforementioned attacks on the use of cryptographic hashes in Internet 92 protocols. This document analyzes the hash usage in SEND following 93 the approach recommended by [RFC4270] and [NEW-HASHES]. 95 The following sections discuss the various aspects of hash usage in 96 SEND and determine whether they are affected by the attacks on the 97 underlying hash functions. 99 2.1. Attacks against CGAs used in SEND 101 Cryptographically Generated Addresses (CGAs) are defined in [RFC3972] 102 and are used to securely associate a cryptographic public key with an 103 IPv6 address in the SEND protocol. Impacts of collision attacks on 104 current uses of CGAs are analyzed in [RFC4982]. The basic idea 105 behind collision attacks, as described in Section 4 of [RFC4270], is 106 on the non-repudiation feature of hash algorithms. However, CGAs do 107 not provide non-repudiation features. Therefore, as [RFC4982] points 108 out CGA based protocols, including SEND, are not affected by 109 collision attacks on hash functions. If pre-image attacks were to 110 become feasible, an attacker can find new CGA Parameters that can 111 generate the same CGA as the victim. This class of attacks could be 112 potentially dangerous since the security of SEND messages relies on 113 the strength of the CGA. 115 2.2. Attacks against PKIX certificates in Authorization Delegation 116 Discovery process 118 To protect Router Discovery, SEND requires that routers be authorized 119 to act as routers. Routers are authorized by provisioning them with 120 certificates from a trust anchor, and the hosts are configured with 121 the trust anchor(s) used to authorize routers. Researchers 122 demonstrated attacks against PKIX certificates with MD5 signatures in 123 2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007], and in 2009 124 [SSALMOdeW2009] [SLdeW2009]. An attacker can take advantage of these 125 vulnerabilities to obtain an certificate with a different identity 126 and use the certificate to impersonate a router. For this attack to 127 succeed the attacker needs to predict the content of all fields (some 128 of them are human-readable) appearing before the public key including 129 the serial number and validity periods. Even though a relying party 130 cannot verify the content of these fields, the CA can identify the 131 forged certificate, if necessary. 133 2.3. Attacks against the Digital Signature in the SEND RSA Signature 134 option 136 The digital signature in the RSA Signature option is produced by 137 signing, with the sender's private key, the SHA-1 hash over certain 138 fields in the Neighbor Discovery message as described in Section 5.2 139 of [RFC3971]. It is possible for an attacker to come up with two 140 different Neighbor Discovery messages m and m' that result in the 141 same value in the Digital Signature field. Since the structure of 142 the Neighbor Discovery messages is well defined, it is not practical 143 to use this vulnerability in real world attacks. 145 2.4. Attacks against the Key Hash field of the SEND RSA Signature 146 option 148 The SEND RSA signature option described in Section 5.2 of [RFC3971] 149 defines a Key Hash field. This field contains a SHA-1 hash of the 150 public key that was used to generate the CGA. To use a collision 151 attack on this field, the attacker needs to come up with another 152 public key (k') that produces the same hash as the real key (k). But 153 the real key (k) is already authorized through a parallel mechanism 154 (either CGAs or router certificates). Hence collision attacks are 155 not possible on the Key Hash field. Pre-image attacks on the Key 156 Hash field are not useful for the same reason (any other key that 157 hashes into the same Key Hash value will be detected due to a 158 mismatch with the CGA or the router certificate). 160 3. Conclusion 162 Current attacks on hash functions do not constitute any practical 163 threat to the digital signatures used in SEND (both in the RSA 164 signature option and in the X.509 certificates). Attacks on CGAs, as 165 described in [RFC4982], will compromise the security of SEND and they 166 need to be addressed by encoding the hash algorithm information into 167 the CGA as specified in [RFC4982]. 169 4. IANA Considerations 171 5. Security Considerations 173 This document analyzes the impact that the attacks against hash 174 functions hash attacks have on SEND. It concludes that the only 175 practical attack on SEND stems from a successful attack on an 176 underlying CGA. It does not add any new vulnerabilities to SEND. 178 6. Acknowledgements 180 The authors would like to thank Lars Eggert, Pete McCann, Julien 181 Laganier, Jari Arkko, Paul Hoffman, Pasi Eronen, Adrian Farrel, Dan 182 Romascanu, Tim Pol, Richard Woundy, Marcelo Bagnulo and Barry Leiba 183 for reviewing earlier versions of this document and providing 184 comments to make it better. 186 7. References 188 7.1. Normative References 190 [NEW-HASHES] 191 Bellovin, S. and E. Rescorla, "Deploying a New Hash 192 Algorithm", November 2005. 194 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 195 Hashes in Internet Protocols", RFC 4270, November 2005. 197 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 198 Algorithms in Cryptographically Generated Addresses 199 (CGAs)", RFC 4982, July 2007. 201 7.2. Informative References 203 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 204 Neighbor Discovery (SEND)", RFC 3971, March 2005. 206 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 207 RFC 3972, March 2005. 209 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 210 Housley, R., and W. Polk, "Internet X.509 Public Key 211 Infrastructure Certificate and Certificate Revocation List 212 (CRL) Profile", RFC 5280, May 2008. 214 [SHA1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 216 [SHA1-COLL] 217 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 218 Full SHA-1. CRYPTO 2005: 17-36", 2005. 220 [SLdeW2009] 221 Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix 222 Collisions for MD5 and Applications, Journal of 223 Cryptology, 2009.", 2009, . 226 [SSALMOdeW2009] 227 Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A., 228 Molnar, D., Osvik, D., and B. de Weger., "Short chosen- 229 prefix collisions for MD5 and the creation of a rogue CA 230 certificate, Crypto 2009", 2009. 232 [STEV2007] 233 Stevens, M., "On Collisions for MD5", . 237 [X509-COLL] 238 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 239 Collisions for MD5 and Colliding X.509 Certificates for 240 Different Identities. EUROCRYPT 2007: 1-22", 2007. 242 Authors' Addresses 244 Ana Kukec 245 University of Zagreb 246 Unska 3 247 Zagreb 248 Croatia 250 Email: ana.kukec@fer.hr 252 Suresh Krishnan 253 Ericsson 254 8400 Decarie Blvd. 255 Town of Mount Royal, QC 256 Canada 258 Email: suresh.krishnan@ericsson.com 259 Sheng Jiang 260 Huawei Technologies Co., Ltd 261 Huawei Building, No.3 Xinxi Rd., 262 Shang-Di Information Industry Base, Hai-Dian District, Beijing 263 P.R. China 265 Email: jiangsheng@huawei.com