From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6273.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6273.txt (limited to 'doc/rfc/rfc6273.txt') diff --git a/doc/rfc/rfc6273.txt b/doc/rfc/rfc6273.txt new file mode 100644 index 0000000..599410c --- /dev/null +++ b/doc/rfc/rfc6273.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Kukec +Request for Comments: 6273 University of Zagreb +Category: Informational S. Krishnan +ISSN: 2070-1721 Ericsson + S. Jiang + Huawei Technologies Co., Ltd + June 2011 + + + The Secure Neighbor Discovery (SEND) Hash Threat Analysis + +Abstract + + This document analyzes the use of hashes in Secure Neighbor Discovery + (SEND), the possible threats to these hashes and the impact of recent + attacks on hash functions used by SEND. The SEND specification + currently uses the SHA-1 hash algorithm and PKIX certificates + and does not provide support for hash algorithm agility. This + document provides an analysis of possible threats to the hash + algorithms used in SEND. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any + errata, and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6273. + + + + + + + + + + + + + + + +Kukec, et al. Informational [Page 1] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Impact of Collision Attacks on SEND . . . . . . . . . . . . . . 3 + 2.1. Attacks against CGAs Used in SEND . . . . . . . . . . . . . 3 + 2.2. Attacks against PKIX Certificates in Authorization + Delegation Discovery Process . . . . . . . . . . . . . . . 3 + 2.3. Attacks against the Digital Signature in the SEND RSA + Signature Option . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. Attacks against the Key Hash Field of the SEND RSA + Signature Option . . . . . . . . . . . . . . . . . . . . . 4 + 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 + +1. Introduction + + SEND [RFC3971] uses the SHA-1 hash algorithm [SHA1] to generate the + contents of the Key Hash field and the Digital Signature field of the + RSA Signature option. It also indirectly uses a hash algorithm + (SHA-1, MD5, etc.) in the PKIX certificates [RFC5280] used for router + authorization in the Authorization Delegation Discovery (ADD) + process. Recently there have been demonstrated attacks against the + collision free property of such hash functions [SHA1-COLL] and + attacks on the PKIX X.509 certificates that use the MD5 hash + algorithm [X509-COLL]. The document analyzes the impacts of these + attacks on SEND and it recommends mechanisms to make SEND resistant + to such attacks. + + + + + +Kukec, et al. Informational [Page 2] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + +2. Impact of Collision Attacks on SEND + + [RFC4270] summarizes a study that assesses the threat of the + aforementioned attacks on the use of cryptographic hashes in Internet + protocols. This document analyzes the hash usage in SEND following + the approach recommended by [RFC4270] and [NEW-HASHES]. + + The following sections discuss the various aspects of hash usage in + SEND and determine whether they are affected by the attacks on the + underlying hash functions. + +2.1. Attacks against CGAs Used in SEND + + Cryptographically Generated Addresses (CGAs) are defined in [RFC3972] + and are used to securely associate a cryptographic public key with an + IPv6 address in the SEND protocol. Impacts of collision attacks on + current uses of CGAs are analyzed in [RFC4982]. The basic idea + behind collision attacks, as described in Section 4 of [RFC4270], is + on the non-repudiation feature of hash algorithms. However, CGAs do + not provide non-repudiation features. Therefore, as [RFC4982] points + out CGA-based protocols, including SEND, are not affected by + collision attacks on hash functions. If pre-image attacks were to + become feasible, an attacker can find new CGA Parameters that can + generate the same CGA as the victim. This class of attacks could be + potentially dangerous since the security of SEND messages relies on + the strength of the CGA. + +2.2. Attacks against PKIX Certificates in Authorization Delegation + Discovery Process + + To protect Router Discovery, SEND requires that routers be authorized + to act as routers. Routers are authorized by provisioning them with + certificates from a trust anchor, and the hosts are configured with + the trust anchor(s) used to authorize routers. Researchers + demonstrated attacks against PKIX certificates with MD5 signatures in + 2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007] [SLdeW2007], and in + 2009 [SSALMOdeW2009] [SLdeW2009]. An attacker can take advantage of + these vulnerabilities to obtain a certificate with a different + identity and use the certificate to impersonate a router. For this + attack to succeed, the attacker needs to predict the content of all + fields (some of them are human-readable) appearing before the public + key, including the serial number and validity periods. Even though a + relying party cannot verify the content of these fields, the CA can + identify the forged certificate, if necessary. + + + + + + + +Kukec, et al. Informational [Page 3] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + +2.3. Attacks against the Digital Signature in the SEND RSA Signature + Option + + The digital signature in the RSA Signature option is produced by + signing, with the sender's private key, the SHA-1 hash over certain + fields in the Neighbor Discovery message as described in Section 5.2 + of [RFC3971]. It is possible for an attacker to come up with two + different Neighbor Discovery messages m and m' that result in the + same value in the Digital Signature field. Since the structure of + the Neighbor Discovery messages is well defined, it is not practical + to use this vulnerability in real world attacks. + +2.4. Attacks against the Key Hash Field of the SEND RSA Signature + Option + + The SEND RSA signature option described in Section 5.2 of [RFC3971] + defines a Key Hash field. This field contains a SHA-1 hash of the + public key that was used to generate the CGA. To use a collision + attack on this field, the attacker needs to come up with another + public key (k') that produces the same hash as the real key (k). But + the real key (k) is already authorized through a parallel mechanism + (either CGAs or router certificates). Hence, collision attacks are + not possible on the Key Hash field. Pre-image attacks on the Key + Hash field are not useful for the same reason (any other key that + hashes into the same Key Hash value will be detected due to a + mismatch with the CGA or the router certificate). + +3. Conclusion + + Current attacks on hash functions do not constitute any practical + threat to the digital signatures used in SEND (both in the RSA + signature option and in the X.509 certificates). Attacks on CGAs, as + described in [RFC4982], will compromise the security of SEND and they + need to be addressed by encoding the hash algorithm information into + the CGA as specified in [RFC4982]. + +4. Security Considerations + + This document analyzes the impact that the attacks against hash + functions have on SEND. It concludes that the only practical attack + on SEND stems from a successful attack on an underlying CGA. It does + not add any new vulnerabilities to SEND. + + + + + + + + + +Kukec, et al. Informational [Page 4] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + +5. Acknowledgements + + The authors would like to thank Lars Eggert, Pete McCann, Julien + Laganier, Jari Arkko, Paul Hoffman, Pasi Eronen, Adrian Farrel, Dan + Romascanu, Tim Polk, Richard Woundy, Marcelo Bagnulo, and Barry Leiba + for reviewing earlier versions of this document and providing + comments to make it better. + +6. References + +6.1. Normative References + + [NEW-HASHES] Bellovin, S. and E. Rescorla, "Deploying a New Hash + Algorithm", November 2005. + + [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic + Hashes in Internet Protocols", RFC 4270, November 2005. + + [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash + Algorithms in Cryptographically Generated Addresses + (CGAs)", RFC 4982, July 2007. + +6.2. Informative References + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March + 2005. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [SHA1] NIST, FIPS PUB 180-1, "Secure Hash Standard", April + 1995. + + [SHA1-COLL] Wang, X., Yin, L., and H. Yu, "Finding Collisions in the + Full SHA-1. CRYPTO 2005: 17-36", 2005. + + [SLdeW2007] Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix + Collisions for MD5 and Colliding X.509 Certificates for + Different Identities". EuroCrypt 2007. + + + + + + +Kukec, et al. Informational [Page 5] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + + [SLdeW2009] Stevens, M., Lenstra, A., de Weger, B., "Chosen-prefix + Collisions for MD5 and Applications, Journal of + Cryptology", 2009, . + + [SSALMOdeW2009] + Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A., + Molnar, D., Osvik, D., and B. de Weger., "Short chosen- + prefix collisions for MD5 and the creation of a rogue CA + certificate, Crypto 2009", 2009. + + [STEV2007] Stevens, M., "On Collisions for MD5", + . + + [X509-COLL] Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix + Collisions for MD5 and Colliding X.509 Certificates for + Different Identities. EUROCRYPT 2007: 1-22", 2007. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kukec, et al. Informational [Page 6] + +RFC 6273 SEND Hash Threat Analysis June 2011 + + +Authors' Addresses + + Ana Kukec + University of Zagreb + Unska 3 + Zagreb + Croatia + + EMail: ana.kukec@fer.hr + + + Suresh Krishnan + Ericsson + 8400 Decarie Blvd. + Town of Mount Royal, QC + Canada + + EMail: suresh.krishnan@ericsson.com + + + Sheng Jiang + Huawei Technologies Co., Ltd + Huawei Building, No.3 Xinxi Rd., + Shang-Di Information Industry Base, Hai-Dian District, Beijing + P.R. China + + EMail: jiangsheng@huawei.com + + + + + + + + + + + + + + + + + + + + + + + + +Kukec, et al. Informational [Page 7] + -- cgit v1.2.3