GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6273

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, <http://deweger.xs4all.nl/
              papers/%5B42%5DStLedW-MD5-JCryp%5B2009%5D.pdf>.
 [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",
              <http://www.win.tue.nl/hashclash/
              On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf>.
 [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]

/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc6273.txt · Last modified: 2011/06/14 03:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki