draft-ietf-csi-hash-threat-00.txt   draft-ietf-csi-hash-threat-01.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: March 14, 2009 Ericsson Expires: May 7, 2009 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
September 10, 2008 November 3, 2008
SeND Hash Threat Analysis SeND Hash Threat Analysis
draft-ietf-csi-hash-threat-00 draft-ietf-csi-hash-threat-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 March 14, 2009. This Internet-Draft will expire on May 7, 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Impact of collision attacks on SeND . . . . . . . . . . . . . 5 3. Impact of collision attacks on SeND . . . . . . . . . . . . . 5
3.1. Attacks against CGAs in stateless autoconfiguration . . . 5 3.1. Attacks against CGAs in stateless autoconfiguration . . . 5
3.2. Attacks against PKIX certificates in ADD process . . . . . 5 3.2. Attacks against PKIX certificates in ADD process . . . . . 5
3.3. Attacks against Digital Signature in RSA Signature 3.3. Attacks against Digital Signature in RSA Signature
option . . . . . . . . . . . . . . . . . . . . . . . . . . 6 option . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Attacks against Key Hash in RSA Signature option . . . . . 7 3.4. Attacks against Key Hash in RSA Signature option . . . . . 7
4. Support for the hash agility in SeND . . . . . . . . . . . . . 8 4. Support for the hash agility in SeND . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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. Additionally, since identity field to provide such two certificates. Generally, attacks against the
is humane readable data, certificates are not affected by collision human-readable fields demand much more effort than the attacks
attacks in practice. Implementations SHOULD use human-readable against non human-readable fields, such as a public key field. In
certificate extensions only if SeND certificate profile demands. We case of the identity field, an attacker is faced with the problem of
also have to take into account that attacker could produce such false the prediction and the generation of the false but meaningful
certificate only if he could predict context- useful certificate identity data, which at the end might be revealed by the
data. So, although collision attacks against PKIX certificates are Certification Authority. Thus, in practice, collision attacks do not
theoretically possible, they can hardly be performed in practice. affect non human-readable parts of the certificate.
In 2007 were demonstrated certificates with the same identity data In 2007 were demonstrated certificates which differ in the identity
and signatures, which differed only in public keys. Such attacks are data and public key, but still result in the same signature value.
potentially more dangerous, since attacker can decide about contents In such attack, even if an attacker produces such two certificates in
of human readable fields, and produce for example certificates with order to claim that he is someone else, he still needs to predict the
the same signatures, but different identities or validity periods. content of all fields appearing before the public key, eg. serial
However, in order to perform a real-world useful attack, attacker number or validity periods. Although a relying party cannot verify
still needs to predict the content of all fields appearing before the the content of these fields (each certificate by itself is
public key, eg. serial number or validity periods. Although a unsuspicious), the CA keeps track of those fields and during the
relying party cannot verify the content of these fields (each fraud analysis, the false certificate can be revealed. Future
certificate by itself is unsuspicious), the CA keeps track of those attacks might affect other human-readable fields. Attacks against
fields and during the fraud analysis, the false certificate can be the validity period field and the IP address extension might have an
revealed. implication to the current SeND protocol. An attack against the IP
address extension might enable the router to advertize changed IP
prefix range, although, not broader than the prefix range of the
parent certificate in the ADD chain.
The certificate key in SeND is used both for the CGA generation and The certificate key in SeND is used both for the CGA generation and
for message signing. In the future, CGA might not be used at all in for message signing. In the future, CGA might not be used at all in
SeND, just certificates. Thus, attacks against certificates are SeND, just certificates. Thus, attacks against certificates are
potentially very dangerous. Generally, the most dangerous are potentially very dangerous. Generally, the most dangerous are
attacks against middle-certificates in the certification path, where attacks against middle-certificates in the certification path, where
for the cost of one false certificate, attacker launches attack on for the cost of one false certificate, attacker launches attack on
multiple routers. In such scenarios, we will be at least safe from multiple routers. In such scenarios, we will be at least safe from
attacks against Trust Anchor's certificate because it is not attacks against Trust Anchor's certificate because it is not
exchanged in SeND messages. exchanged in SeND messages.
skipping to change at page 7, line 11 skipping to change at page 7, line 18
SHA-1 hash of IPv6 addresses, ICMPv6 header, ND message and other SHA-1 hash of IPv6 addresses, ICMPv6 header, ND message and other
fields like Message Type Tag and ND options [rfc3971], and is signed fields like Message Type Tag and ND options [rfc3971], and is signed
with the sender's private key, which corresponds to the public key with the sender's private key, which corresponds to the public key
from the CGA parameters structure and is authorized usually through from the CGA parameters structure and is authorized usually through
CGAs. The possible attack on such explicit digital signature is CGAs. The possible attack on such explicit digital signature is
typical non-repudiation attack. The Digital Signature field is typical non-repudiation attack. The Digital Signature field is
vulnerable to the collision attack. In such collision attack an vulnerable to the collision attack. In such collision attack an
attacker produces two messages M and M', where hash(M) = hash(M'), attacker produces two messages M and M', where hash(M) = hash(M'),
underlays one of the messages to be signed with authorized keys underlays one of the messages to be signed with authorized keys
(through CGAs), but uses another message afterwards. However, the (through CGAs), but uses another message afterwards. However, the
prediction and production of the useful content of messages M and M' structure of at least one of two messages in collision attack is
is just theoretically possible, since SeND message contains mostly strictly predefined [rfc4270]. But we have to take into account that
human readable data. Additionally, the structure of at least one of a variant of SHA-1 was already affected by recent collision attacks
two messages (M and M') is predefined [rfc4270]. But we have to take and we have to prepare for future improved attacks.
into account that a variant of SHA-1 was already affected by recent
collision attacks and we have to prepare for future improved attacks.
3.4. Attacks against Key Hash in RSA Signature option 3.4. Attacks against Key Hash in RSA Signature option
Key Hash field in the RSA Signature option is a SHA-1 hash of the Key Hash field in the RSA Signature option is a SHA-1 hash of the
public key from the CGA parameters structure in the CGA option of public key from the CGA parameters structure in the CGA option of
SeND message. Key Hash field is potentially dangerous because it SeND message. Key Hash field is potentially dangerous because it
contains a non human-readable data. Since in the collision attack an contains a non human-readable data. Since in the collision attack an
attacker itself chooses both keys, K and K', where hash(K) = attacker itself chooses both keys, K and K', where hash(K) =
hash(K'), the Key Hash field is not suspectable to the collision hash(K'), the Key Hash field is not suspectable to the collision
attack. The preimage attack in which an attacker derives the key K' attack. The preimage attack in which an attacker derives the key K'
 End of changes. 8 change blocks. 
31 lines changed or deleted 32 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/