SEND hash threats: The Secure Neighbor Discovery (SEND) Hash Threat Analysis
Evaluating hash function vulnerabilities in secure neighbor discovery.
Kukec, A., Krishnan, S., and S. Jiang, "The Secure Neighbor Discovery (SEND) Hash Threat Analysis", RFC 6273, DOI 10.17487/RFC6273, June 2011, <https://www.rfc-editor.org/info/rfc6273>.
@misc{rfc6273,
series = {Request for Comments},
number = 6273,
howpublished = {RFC 6273},
publisher = {RFC Editor},
doi = {10.17487/RFC6273},
url = {https://www.rfc-editor.org/info/rfc6273},
author = {A. Kukec and S. Krishnan and S. Jiang},
title = {{The Secure Neighbor Discovery (SEND) Hash Threat Analysis}},
pagetotal = 7,
year = 2011,
month = jun,
} RFC text
Contents
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.
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.
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.
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.
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.
[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.
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
AI ELI5
On this page
§1Introduction
SEND (Secure Neighbor Discovery) is an IPv6 security protocol that uses the SHA-1 hash algorithm to associate cryptographic keys with IPv6 addresses and to create digital signatures on router authorization certificates. The document was written when researchers had recently demonstrated collision attacks against SHA-1 and similar attacks against MD5 used in X.509 certificates.
The authors set out to determine whether these cryptographic attacks pose a real threat to SEND's actual use in networks. Rather than assume the worst, they analyze each place where SEND uses hashing and evaluate the practical impact of each type of attack.
People found ways to break SHA-1 fingerprints. The document checks if those breaks can actually hurt SEND.
§2How SEND Uses Hashes
SEND relies on hashes in four distinct places. First, it uses SHA-1 in Cryptographically Generated Addresses (CGAs), which bind a public key to an IPv6 address by hashing the key material. Second, it hashes key material again in the Key Hash field of the RSA Signature option. Third, SEND uses hashes embedded in X.509 certificates from a trust anchor to authorize routers. Fourth, it uses SHA-1 to create digital signatures over neighbor discovery messages.
Each of these uses has different properties. Some rely on the collision-resistance of the hash—its ability to resist finding two different inputs that produce the same output. Others rely on preimage resistance—the difficulty of finding any input that hashes to a target value. Understanding which property matters for each use is key to assessing risk.
SEND checks fingerprints in four different places: when making addresses, when signing messages, when checking router certificates, and when protecting key material. Each place needs a different kind of protection.
§3Threat Analysis
Attacks on CGAs present the most significant risk. CGAs do not depend on collision resistance—an attacker cannot forge a CGA by finding a collision. However, if preimage attacks become practical (finding any key material that hashes to a target address), an attacker could generate a new CGA that appears to belong to a victim. This is the only attack the document identifies as genuinely dangerous to SEND's operation.
Attacks on digital signatures and key hashes are analyzed as not practically exploitable. Collision attacks on the SHA-1 signature itself cannot work because the structure of neighbor discovery messages is rigid and well-known; an attacker cannot create two different meaningful messages with the same hash. Attacks on the Key Hash field also fail because the real key is already authorized through separate mechanisms (either the CGA itself or router certificates), so any hash collision would be detected immediately as invalid.
Attacks on X.509 certificates using MD5 could theoretically allow an attacker to create a forged router certificate with a different identity if they can predict unpredictable fields like serial numbers and validity periods. In practice, the certificate authority can detect such forgeries if necessary, limiting the window of exposure.
Breaking fingerprints in messages is hard because messages have a fixed shape. Breaking fingerprints on certificates is possible in theory but hard in practice because the CA can spot the fake.
§4Conclusion
The analysis concludes that current hash function attacks, while impressive as cryptographic research, do not constitute a practical threat to most of SEND's mechanisms. The digital signatures in SEND messages, the key hashes they contain, and even the X.509 certificates used for router authorization all remain secure against known attacks.
The one exception is the CGA mechanism: if preimage attacks on SHA-1 become feasible, SEND would be compromised. To mitigate this risk, the authors recommend that CGAs encode the hash algorithm used during generation, allowing the system to migrate to stronger hashes without breaking compatibility. This approach, specified separately in RFC 4982, lets SEND remain secure even if SHA-1 weakens further.
Most of SEND is safe. Only the address fingerprints are at risk, and that risk can be managed by letting the system remember which fingerprint machine was used.