idnits 2.17.1 draft-ietf-csi-hash-threat-11.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 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 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 (November 26, 2010) is 4893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SHA1' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'SLdeW2009' is defined on line 226, but no explicit reference was found in the text == Unused Reference: 'SSALMOdeW2009' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'STEV2007' is defined on line 238, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 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: Informational S. Krishnan 5 Expires: May 30, 2011 Ericsson 6 S. Jiang 7 Huawei Technologies Co., Ltd 8 November 26, 2010 10 SEND Hash Threat Analysis 11 draft-ietf-csi-hash-threat-11 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 and PKIX certificates and 19 does not provide support for hash algorithm agility. This document 20 provides an analysis of possible threats to the hash algorithms used 21 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 May 30, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Impact of collision attacks on SEND . . . . . . . . . . . . . . 3 60 3.1. Attacks against CGAs used in SEND . . . . . . . . . . . . . 3 61 3.2. Attacks against PKIX certificates in Authorization 62 Delegation Discovery process . . . . . . . . . . . . . . . 4 63 3.3. Attacks against the Digital Signature in the SEND RSA 64 Signature option . . . . . . . . . . . . . . . . . . . . . 4 65 3.4. Attacks against the Key Hash field of the SEND RSA 66 Signature option . . . . . . . . . . . . . . . . . . . . . 4 67 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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. Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 3. Impact of collision attacks on SEND 96 [RFC4270] performed a study to assess the threat of theaforementioned 97 attacks on the use of cryptographic hashes in Internet protocols . 98 This document analyzes the hash usage in SEND following the approach 99 recommended by [RFC4270] and [NEW-HASHES]. 101 The following sections discuss the various aspects of hash usage in 102 SEND and determine whether they are affected by the attacks on the 103 underlying hash functions. 105 3.1. Attacks against CGAs used in SEND 107 Cryptographically Generated Addresses (CGAs) are defined in [RFC3972] 108 and are used to securely associate a cryptographic public key with an 109 IPv6 address in the SEND protocol. Impacts of collision attacks on 110 current uses of CGAs are analyzed in [RFC4982]. The basic idea 111 behind collision attacks, as described in Section 4 of [RFC4270], is 112 on the non-repudiation feature of hash algorithms. Since CGAs do not 113 provide non-repudiation features anyway. Therefore, as [RFC4982] 114 points out CGA based protocols, including SEND, are not affected by 115 collision attacks on hash functions. If pre-image attacks were to 116 become feasible, an attacker can find new CGA Parameters that can 117 generate the same CGA as the victim. This class of attacks could be 118 potentially dangerous since the security of SEND messages relies on 119 the strength of the CGA. 121 3.2. Attacks against PKIX certificates in Authorization Delegation 122 Discovery process 124 To protect Router Discovery, SEND requires that routers be authorized 125 to act as routers. Routers are authorized by provisioning them with 126 certificates from a trust anchor, and the hosts are configured with 127 the trust anchor(s) used to authorize routers. Researchers 128 demonstrated attacks against PKIX certificates with MD5 signatures in 129 2005 [NEW-HASHES] and in 2007 [X509-COLL]. An attacker can take 130 advantage of these vulnerabilities to obtain an certificate with a 131 different identity and use the certificate to impersonate a router. 132 For this attack to succeed the attacker needs to predict the content 133 of all fields (some of them are human-readable) appearing before the 134 public key including the serial number and validity periods. Even 135 though a relying party cannot verify the content of these fields, the 136 CA can identify the forged certificate, if necessary. 138 3.3. Attacks against the Digital Signature in the SEND RSA Signature 139 option 141 The digital signature in the RSA Signature option is produced by 142 signing, with the sender's private key, the SHA-1 hash over certain 143 fields in the Neighbor Discovery message as described in Section 5.2 144 of [RFC3971]. It is possible for an attacker to come up with two 145 different Neighbor Discovery messages m and m' that result in the 146 same value in the Digital Signature field. Since the structure of 147 the Neighbor Discovery messages is well defined, it is not practical 148 to use this vulnerability in real world attacks. 150 3.4. Attacks against the Key Hash field of the SEND RSA Signature 151 option 153 The SEND RSA signature option described in Section 5.2 of [RFC3971] 154 defines a Key Hash field. This field contains a SHA-1 hash of the 155 public key that was used to generate the CGA. To use a collision 156 attack on this field, the attacker needs to come up with another 157 public key (k') that produces the same hash as the real key (k). But 158 the real key (k) is already authorized through a parallel mechanism 159 (either CGAs or router certificates). Hence collision attacks are 160 not possible on the Key Hash field. Pre-image attacks on the Key 161 Hash field are not useful for the same reason (any other key that 162 hashes into the same Key Hash value will be detected due to a 163 mismatch with the CGA or the router certificate). 165 4. Conclusion 167 Current attacks on hash functions do not constitute any practical 168 threat to the digital signatures used in SEND (both in the RSA 169 signature option and in the X.509 certificates). Attacks on CGAs, as 170 described in [RFC4982], will compromise the security of SEND and they 171 need to be addressed by encoding the hash algorithm information into 172 the CGA as specified in [RFC4982]. 174 5. Security Considerations 176 This document analyzes the impact that the attacks against hash 177 functions hash attacks have on SEND. It concludes that the only 178 practical attack on SEND stems from a successful attack on an 179 underlying CGA. It does not add any new vulnerabilities to SEND. 181 6. Acknowledgements 183 The authors would like to thank Lars Eggert, Pete McCann, Julien 184 Laganier, Jari Arkko, Paul Hoffman, Pasi Eronen, Adrian Farrel, Dan 185 Romascanu, Tim Pol, Richard Woundy, Marcelo Bagnulo and Barry Leiba 186 for reviewing earlier versions of this document and providing 187 comments to make it better. 189 7. References 191 7.1. Normative References 193 [NEW-HASHES] 194 Bellovin, S. and E. Rescorla, "Deploying a New Hash 195 Algorithm", November 2005. 197 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 198 Hashes in Internet Protocols", RFC 4270, November 2005. 200 [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash 201 Algorithms in Cryptographically Generated Addresses 202 (CGAs)", RFC 4982, July 2007. 204 7.2. Informative References 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, March 1997. 209 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 210 Neighbor Discovery (SEND)", RFC 3971, March 2005. 212 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 213 RFC 3972, March 2005. 215 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 216 Housley, R., and W. Polk, "Internet X.509 Public Key 217 Infrastructure Certificate and Certificate Revocation List 218 (CRL) Profile", RFC 5280, May 2008. 220 [SHA1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. 222 [SHA1-COLL] 223 Wang, X., Yin, L., and H. Yu, "Finding Collisions in the 224 Full SHA-1. CRYPTO 2005: 17-36", 2005. 226 [SLdeW2009] 227 Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix 228 Collisions for MD5 and Applications, Journal of 229 Cryptology, 2009.", 2009, . 232 [SSALMOdeW2009] 233 Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A., 234 Molnar, D., Osvik, D., and B. de Weger., "Short chosen- 235 prefix collisions for MD5 and the creation of a rogue CA 236 certificate, Crypto 2009", 2009. 238 [STEV2007] 239 Stevens, M., "On Collisions for MD5", . 243 [X509-COLL] 244 Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix 245 Collisions for MD5 and Colliding X.509 Certificates for 246 Different Identitites. EUROCRYPT 2007: 1-22", 2007. 248 Authors' Addresses 250 Ana Kukec 251 University of Zagreb 252 Unska 3 253 Zagreb 254 Croatia 256 Email: ana.kukec@fer.hr 257 Suresh Krishnan 258 Ericsson 259 8400 Decarie Blvd. 260 Town of Mount Royal, QC 261 Canada 263 Email: suresh.krishnan@ericsson.com 265 Sheng Jiang 266 Huawei Technologies Co., Ltd 267 KuiKe Building, No.9 Xinxi Rd., 268 Shang-Di Information Industry Base, Hai-Dian District, Beijing 269 P.R. China 271 Email: shengjiang@huawei.com