draft-ietf-csi-hash-threat-01.txt   draft-ietf-csi-hash-threat-02.txt 
Network Working Group A. Kukec Network Working Group A. Kukec
Internet-Draft University of Zagreb Internet-Draft University of Zagreb
Intended status: Standards Track S. Krishnan Intended status: Standards Track S. Krishnan
Expires: May 7, 2009 Ericsson Expires: July 10, 2009 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
November 3, 2008 January 6, 2009
SeND Hash Threat Analysis SeND Hash Threat Analysis
draft-ietf-csi-hash-threat-01 draft-ietf-csi-hash-threat-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009. This Internet-Draft will expire on July 10, 2009.
Abstract Abstract
This document analysis the use of hashes in SeND, possible threats This document analysis the use of hashes in SeND, possible threats
and the impact of recent attacks on hash functions used by SeND. and the impact of recent attacks on hash functions used by SeND.
Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash Current SeND specification [rfc3971] uses SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc3280] and does not provide algorithm and PKIX certificates [rfc3280] and does not provide
support for the hash algorithm agility. The purpose of the document support for the hash algorithm agility. The purpose of the document
is to provide analysis of possible hash threats and to decide how to is to provide analysis of possible hash threats and to decide how to
encode the hash agility support in SeND. encode the hash agility support in SeND.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [rfc2119]. document are to be interpreted as described in RFC 2119 [rfc2119].
3. Impact of collision attacks on SeND 3. Impact of collision attacks on SeND
Due to the hash attacks demonstrated on the aforesaid hash algorithms Due to the hash attacks demonstrated on the aforesaid hash algorithms
a study was performed to assess the threat of these attacks on the a study was performed to assess the threat of these attacks on the
cryptographic hash usage in internet protocols [RFC4270]. This cryptographic hash usage in internet protocols [rfc4270]. This
document analyzes the hash usage in SEND following the approach document analyzes the hash usage in SEND following the approach
recommended by [rfc4270]. Following the approach recommended by recommended by [rfc4270]. Following the approach recommended by
[rfc4270] and [new-hashes], we will analyze the impact of these [rfc4270] and [new-hashes], we will analyze the impact of these
attacks on SeND case by case in this section. Through our analysis, attacks on SeND case by case in this section. Through our analysis,
whether we should support hash agility on SeND is also discussed. whether we should support hash agility on SeND is also discussed.
Up to date, all demonstrated attacks are attacks against a collision- Up to date, all demonstrated attacks are attacks against a collision-
free property. An attacker produces two messages which result in the free property. An attacker produces two messages which result in the
same hash. Attacks against the one-way property are not yet feasible same hash. Attacks against the one-way property are not yet feasible
[rfc4270]. There are two attacks against one property. In the [rfc4270]. There are two attacks against one property. In the
skipping to change at page 6, line 7 skipping to change at page 6, line 7
other hashes. But up to date, the preimage attacks are not yet other hashes. But up to date, the preimage attacks are not yet
feasible, but might be in the future. feasible, but might be in the future.
3.2. Attacks against PKIX certificates in ADD process 3.2. Attacks against PKIX certificates in ADD process
The second use of hash functions is for the router authorization in The second use of hash functions is for the router authorization in
ADD process. Router sends to host a certification path, which is a ADD process. Router sends to host a certification path, which is a
path between a router and hosts's trust anchor and consists of PKIX path between a router and hosts's trust anchor and consists of PKIX
certificates. Researchers demonstrated attacks against PKIX certificates. Researchers demonstrated attacks against PKIX
certificates with MD5 signature, in 2005 [new-hashes] and in 2007 certificates with MD5 signature, in 2005 [new-hashes] and in 2007
[X509-COLL]. [x509-coll].
In 2005 they succeeded to construct the original and the false In 2005 they succeeded to construct the original and the false
certificate that had the same identity data and digital signature, certificate that had the same identity data and digital signature,
but different public keys [new-hashes]. The problem for the attacker but different public keys [new-hashes]. The problem for the attacker
is that two certificates with the same identity are not very useful is that two certificates with the same identity are not very useful
in real-world scenarios, while Certification Authority is not allowed in real-world scenarios, while Certification Authority is not allowed
to provide such two certificates. Generally, attacks against the to provide such two certificates. Generally, attacks against the
human-readable fields demand much more effort than the attacks human-readable fields demand much more effort than the attacks
against non human-readable fields, such as a public key field. In against non human-readable fields, such as a public key field. In
case of the identity field, an attacker is faced with the problem of case of the identity field, an attacker is faced with the problem of
skipping to change at page 10, line 7 skipping to change at page 10, line 7
in the future SeND might be used completely without CGAs. in the future SeND might be used completely without CGAs.
5. Security Considerations 5. Security Considerations
This document analyzes the impact of hash attacks in SeND and offeres This document analyzes the impact of hash attacks in SeND and offeres
a higher security level for SeND by providing solution for the hash a higher security level for SeND by providing solution for the hash
agility support. agility support.
6. IANA Considerations 6. IANA Considerations
This document defines three new registries that have been created and This document only analyzes the possible hash threats in SEND and
are maintained by IANA. introduces the possible mechanisms to support hash agility. The
actual SEND extensions are defined in other documents. There are no
o Hash Algorithm for Key Hash field (HA-KH). The values in this IANA actions required by this document.
name space are 5-bit unsigned integers.
o Hash Algorithm for Digital Signature field (HA-DS). The values in
this name space are 5-bit unsigned integers.
o Signature Algorithm (SA). The values in this name space are 5-bit
unsigned integers.
Initial values for these registries are given below. Future
assignments are to be made through Standards Action [rfc2434].
Assignments for each registry consist of a name, a value and a RFC
number where the registry is defined.
The following initial values are assigned for HA-KH in this document:
Name | Value | RFCs
-------------------+-------+------------
SHA-1 | TBD1 | this document
The following initial values are assigned for HA-DS in this document:
Name | Value | RFCs
-------------------+-------+------------
SHA-1 | TBD2 | this document
The following initial values are assigned for HA-KH in this document:
Name | Value | RFCs
-------------------+-------+------------
RSASSA-PKCS1-v1_5 | TBD3 | this document
This document defines one new Neighbor Discovery Protocol [rfc4861]
options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages:
The Hash algorithm option (TBA1), described in Section 4.1.
7. References 7. References
7.1. Normative References 7.1. Normative References
[new-hashes] [new-hashes]
Bellovin, S. and E. Rescorla, "Deploying a New Hash Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005. Algorithm", November 2005.
[rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
skipping to change at page 11, line 28 skipping to change at page 11, line 28
[rfc4982] Bagnulo, M. and J. Arrko, "Support for Multiple Hash [rfc4982] Bagnulo, M. and J. Arrko, "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 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[rfc2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
April 1998.
[rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure [rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Certificate and Certificate Revocation List (CRL)
Profile", RFC rfc3280, April 2002. Profile", RFC rfc3280, April 2002.
[rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Solliman,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
April 1998.
[sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995. [sha-1] NIST, FIBS PUB 180-1, "Secure Hash Standard", April 1995.
[sha1-coll] [sha1-coll]
Wang, X., Yin, L., and H. Yu, "Finding Collisions in the Wang, X., Yin, L., and H. Yu, "Finding Collisions in the
Full SHA-1. CRYPTO 2005: 17-36", 2005. Full SHA-1. CRYPTO 2005: 17-36", 2005.
[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", 2005. Different Identitites. EUROCRYPT 2007: 1-22", 2005.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd., KuiKe Building, No.9 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: shengjiang@huawei.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright Notice
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copyright (c) 2009 IETF Trust and the persons identified as the
assurances of licenses to be made available, or the result of an document authors. All rights reserved.
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any This document is subject to BCP 78 and the IETF Trust's Legal
copyrights, patents or patent applications, or other proprietary Provisions Relating to IETF Documents
rights that may cover technology that may be required to implement (http://trustee.ietf.org/license-info) in effect on the date of
this standard. Please address the information to the IETF at publication of this document. Please review these documents
ietf-ipr@ietf.org. carefully, as they describe your rights and restrictions with respect
to this document.
 End of changes. 13 change blocks. 
88 lines changed or deleted 15 lines changed or added

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