draft-ietf-csi-hash-threat-11.txt   draft-ietf-csi-hash-threat-12.txt 
Network Working Group A. Kukec Network Working Group A. Kukec
Internet-Draft University of Zagreb Internet-Draft University of Zagreb
Intended status: Informational S. Krishnan Intended status: Informational S. Krishnan
Expires: May 30, 2011 Ericsson Expires: September 2, 2011 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
November 26, 2010 March 7, 2011
SEND Hash Threat Analysis SEND Hash Threat Analysis
draft-ietf-csi-hash-threat-11 draft-ietf-csi-hash-threat-12
Abstract Abstract
This document analyzes the use of hashes in Secure Neighbor Discovery This document analyzes the use of hashes in Secure Neighbor Discovery
(SEND), the possible threats to these hashes and the impact of recent (SEND), the possible threats to these hashes and the impact of recent
attacks on hash functions used by SEND. The SEND specification attacks on hash functions used by SEND. The SEND specification
currently uses the SHA-1 hash algorithm and PKIX certificates and currently uses the SHA-1 hash algorithm [SHA1] and PKIX certificates
does not provide support for hash algorithm agility. This document and does not provide support for hash algorithm agility. This
provides an analysis of possible threats to the hash algorithms used document provides an analysis of possible threats to the hash
in SEND. algorithms used in SEND.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 30, 2011. This Internet-Draft will expire on September 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Impact of collision attacks on SEND . . . . . . . . . . . . . . 3
3. Impact of collision attacks on SEND . . . . . . . . . . . . . . 3 2.1. Attacks against CGAs used in SEND . . . . . . . . . . . . . 3
3.1. Attacks against CGAs used in SEND . . . . . . . . . . . . . 3 2.2. Attacks against PKIX certificates in Authorization
3.2. Attacks against PKIX certificates in Authorization Delegation Discovery process . . . . . . . . . . . . . . . 3
Delegation Discovery process . . . . . . . . . . . . . . . 4 2.3. Attacks against the Digital Signature in the SEND RSA
3.3. Attacks against the Digital Signature in the SEND RSA
Signature option . . . . . . . . . . . . . . . . . . . . . 4 Signature option . . . . . . . . . . . . . . . . . . . . . 4
3.4. Attacks against the Key Hash field of the SEND RSA 2.4. Attacks against the Key Hash field of the SEND RSA
Signature option . . . . . . . . . . . . . . . . . . . . . 4 Signature option . . . . . . . . . . . . . . . . . . . . . 4
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
SEND [RFC3971] uses the SHA-1 hash algorithm to generate the contents SEND [RFC3971] uses the SHA-1 hash algorithm to generate the contents
of the Key Hash field and the Digital Signature field of the RSA of the Key Hash field and the Digital Signature field of the RSA
Signature option. It also indirectly uses a hash algorithm (SHA-1, Signature option. It also indirectly uses a hash algorithm (SHA-1,
MD5, etc.) in the PKIX certificates [RFC5280] used for router MD5, etc.) in the PKIX certificates [RFC5280] used for router
authorization in the Authorization Delegation Discovery(ADD) process. authorization in the Authorization Delegation Discovery(ADD) process.
Recently there have been demonstrated attacks against the collision Recently there have been demonstrated attacks against the collision
free property of such hash functions [SHA1-COLL], and attacks on the free property of such hash functions [SHA1-COLL], and attacks on the
PKIX X.509 certificates that use the MD5 hash algorithm [X509-COLL]. PKIX X.509 certificates that use the MD5 hash algorithm [X509-COLL].
The document analyzes the impacts of these attacks on SEND and it The document analyzes the impacts of these attacks on SEND and it
recommends mechanisms to make SEND resistant to such attacks. recommends mechanisms to make SEND resistant to such attacks.
2. Terminology 2. Impact of collision attacks on SEND
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Impact of collision attacks on SEND
[RFC4270] performed a study to assess the threat of theaforementioned [RFC4270] performed a study to assess the threat of the
attacks on the use of cryptographic hashes in Internet protocols . aforementioned attacks on the use of cryptographic hashes in Internet
This document analyzes the hash usage in SEND following the approach protocols. This document analyzes the hash usage in SEND following
recommended by [RFC4270] and [NEW-HASHES]. the approach recommended by [RFC4270] and [NEW-HASHES].
The following sections discuss the various aspects of hash usage in The following sections discuss the various aspects of hash usage in
SEND and determine whether they are affected by the attacks on the SEND and determine whether they are affected by the attacks on the
underlying hash functions. underlying hash functions.
3.1. Attacks against CGAs used in SEND 2.1. Attacks against CGAs used in SEND
Cryptographically Generated Addresses (CGAs) are defined in [RFC3972] Cryptographically Generated Addresses (CGAs) are defined in [RFC3972]
and are used to securely associate a cryptographic public key with an and are used to securely associate a cryptographic public key with an
IPv6 address in the SEND protocol. Impacts of collision attacks on IPv6 address in the SEND protocol. Impacts of collision attacks on
current uses of CGAs are analyzed in [RFC4982]. The basic idea current uses of CGAs are analyzed in [RFC4982]. The basic idea
behind collision attacks, as described in Section 4 of [RFC4270], is behind collision attacks, as described in Section 4 of [RFC4270], is
on the non-repudiation feature of hash algorithms. Since CGAs do not on the non-repudiation feature of hash algorithms. However, CGAs do
provide non-repudiation features anyway. Therefore, as [RFC4982] not provide non-repudiation features. Therefore, as [RFC4982] points
points out CGA based protocols, including SEND, are not affected by out CGA based protocols, including SEND, are not affected by
collision attacks on hash functions. If pre-image attacks were to collision attacks on hash functions. If pre-image attacks were to
become feasible, an attacker can find new CGA Parameters that can become feasible, an attacker can find new CGA Parameters that can
generate the same CGA as the victim. This class of attacks could be generate the same CGA as the victim. This class of attacks could be
potentially dangerous since the security of SEND messages relies on potentially dangerous since the security of SEND messages relies on
the strength of the CGA. the strength of the CGA.
3.2. Attacks against PKIX certificates in Authorization Delegation 2.2. Attacks against PKIX certificates in Authorization Delegation
Discovery process Discovery process
To protect Router Discovery, SEND requires that routers be authorized To protect Router Discovery, SEND requires that routers be authorized
to act as routers. Routers are authorized by provisioning them with to act as routers. Routers are authorized by provisioning them with
certificates from a trust anchor, and the hosts are configured with certificates from a trust anchor, and the hosts are configured with
the trust anchor(s) used to authorize routers. Researchers the trust anchor(s) used to authorize routers. Researchers
demonstrated attacks against PKIX certificates with MD5 signatures in demonstrated attacks against PKIX certificates with MD5 signatures in
2005 [NEW-HASHES] and in 2007 [X509-COLL]. An attacker can take 2005 [NEW-HASHES], in 2007 [X509-COLL] [STEV2007], and in 2009
advantage of these vulnerabilities to obtain an certificate with a [SSALMOdeW2009] [SLdeW2009]. An attacker can take advantage of these
different identity and use the certificate to impersonate a router. vulnerabilities to obtain an certificate with a different identity
For this attack to succeed the attacker needs to predict the content and use the certificate to impersonate a router. For this attack to
of all fields (some of them are human-readable) appearing before the succeed the attacker needs to predict the content of all fields (some
public key including the serial number and validity periods. Even of them are human-readable) appearing before the public key including
though a relying party cannot verify the content of these fields, the the serial number and validity periods. Even though a relying party
CA can identify the forged certificate, if necessary. cannot verify the content of these fields, the CA can identify the
forged certificate, if necessary.
3.3. Attacks against the Digital Signature in the SEND RSA Signature 2.3. Attacks against the Digital Signature in the SEND RSA Signature
option option
The digital signature in the RSA Signature option is produced by The digital signature in the RSA Signature option is produced by
signing, with the sender's private key, the SHA-1 hash over certain 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 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 of [RFC3971]. It is possible for an attacker to come up with two
different Neighbor Discovery messages m and m' that result in the different Neighbor Discovery messages m and m' that result in the
same value in the Digital Signature field. Since the structure of same value in the Digital Signature field. Since the structure of
the Neighbor Discovery messages is well defined, it is not practical the Neighbor Discovery messages is well defined, it is not practical
to use this vulnerability in real world attacks. to use this vulnerability in real world attacks.
3.4. Attacks against the Key Hash field of the SEND RSA Signature 2.4. Attacks against the Key Hash field of the SEND RSA Signature
option option
The SEND RSA signature option described in Section 5.2 of [RFC3971] 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 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 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 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 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 the real key (k) is already authorized through a parallel mechanism
(either CGAs or router certificates). Hence collision attacks are (either CGAs or router certificates). Hence collision attacks are
not possible on the Key Hash field. Pre-image attacks on the Key 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 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 hashes into the same Key Hash value will be detected due to a
mismatch with the CGA or the router certificate). mismatch with the CGA or the router certificate).
4. Conclusion 3. Conclusion
Current attacks on hash functions do not constitute any practical Current attacks on hash functions do not constitute any practical
threat to the digital signatures used in SEND (both in the RSA threat to the digital signatures used in SEND (both in the RSA
signature option and in the X.509 certificates). Attacks on CGAs, as signature option and in the X.509 certificates). Attacks on CGAs, as
described in [RFC4982], will compromise the security of SEND and they described in [RFC4982], will compromise the security of SEND and they
need to be addressed by encoding the hash algorithm information into need to be addressed by encoding the hash algorithm information into
the CGA as specified in [RFC4982]. the CGA as specified in [RFC4982].
4. IANA Considerations
5. Security Considerations 5. Security Considerations
This document analyzes the impact that the attacks against hash This document analyzes the impact that the attacks against hash
functions hash attacks have on SEND. It concludes that the only functions hash attacks have on SEND. It concludes that the only
practical attack on SEND stems from a successful attack on an practical attack on SEND stems from a successful attack on an
underlying CGA. It does not add any new vulnerabilities to SEND. underlying CGA. It does not add any new vulnerabilities to SEND.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Lars Eggert, Pete McCann, Julien The authors would like to thank Lars Eggert, Pete McCann, Julien
skipping to change at page 5, line 42 skipping to change at page 5, line 39
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, November 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash [RFC4982] Bagnulo, M. and J. Arkko, "Support for Multiple Hash
Algorithms in Cryptographically Generated Addresses Algorithms in Cryptographically Generated Addresses
(CGAs)", RFC 4982, July 2007. (CGAs)", RFC 4982, July 2007.
7.2. Informative References 7.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
skipping to change at page 6, line 37 skipping to change at page 6, line 31
certificate, Crypto 2009", 2009. certificate, Crypto 2009", 2009.
[STEV2007] [STEV2007]
Stevens, M., "On Collisions for MD5", <http:// Stevens, M., "On Collisions for MD5", <http://
www.win.tue.nl/hashclash/ www.win.tue.nl/hashclash/
On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf>. On%20Collisions%20for%20MD5%20-%20M.M.J.%20Stevens.pdf>.
[X509-COLL] [X509-COLL]
Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix Stevens, M., Lenstra, A., and B. Weger, "Chosen-Prefix
Collisions for MD5 and Colliding X.509 Certificates for Collisions for MD5 and Colliding X.509 Certificates for
Different Identitites. EUROCRYPT 2007: 1-22", 2007. Different Identities. EUROCRYPT 2007: 1-22", 2007.
Authors' Addresses Authors' Addresses
Ana Kukec Ana Kukec
University of Zagreb University of Zagreb
Unska 3 Unska 3
Zagreb Zagreb
Croatia Croatia
Email: ana.kukec@fer.hr Email: ana.kukec@fer.hr
skipping to change at page 7, line 4 skipping to change at page 6, line 42
Authors' Addresses Authors' Addresses
Ana Kukec Ana Kukec
University of Zagreb University of Zagreb
Unska 3 Unska 3
Zagreb Zagreb
Croatia Croatia
Email: ana.kukec@fer.hr Email: ana.kukec@fer.hr
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd., Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China P.R. China
Email: shengjiang@huawei.com Email: jiangsheng@huawei.com
 End of changes. 25 change blocks. 
50 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/