draft-ietf-csi-hash-threat-05.txt   draft-ietf-csi-hash-threat-06.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: Standards Track S. Krishnan
Expires: May 13, 2010 Ericsson Expires: August 16, 2010 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
November 9, 2009 February 12, 2010
SeND Hash Threat Analysis SEND Hash Threat Analysis
draft-ietf-csi-hash-threat-05 draft-ietf-csi-hash-threat-06
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 the SHA-1 [sha-1] hash Current SEND specification [rfc3971] uses the SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc5280] and does not provide algorithm and X.509 certificates [rfc5280] 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), 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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 13, 2010. This Internet-Draft will expire on August 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Impact of collision attacks on SeND . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Attacks against CGAs in stateless autoconfiguration . . . 4 3. Impact of collision attacks on SEND . . . . . . . . . . . . . 6
2.2. Attacks against PKIX certificates in ADD process . . . . . 5 3.1. Attacks against CGAs in stateless autoconfiguration . . . 6
2.3. Attacks against the Digital Signature in the RSA 3.2. Attacks against X.509 certificates in ADD process . . . . 7
Signature option . . . . . . . . . . . . . . . . . . . . . 6 3.3. Attacks against the Digital Signature in the RSA
2.4. Attacks against the Key Hash field in the RSA Signature option . . . . . . . . . . . . . . . . . . . . . 8
Signature option . . . . . . . . . . . . . . . . . . . . . 6 3.4. Attacks against the Key Hash field in the RSA
3. Support for the hash agility in SeND . . . . . . . . . . . . . 7 Signature option . . . . . . . . . . . . . . . . . . . . . 8
3.1. The negotiation approach for the SEND hash agility . . . . 7 4. Support for the hash agility in SEND . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
SEND [rfc3971] uses the SHA-1 hash algorithm to generate the contents SEND [rfc3971] uses the hash algorithm in different ways. It uses
of the Key Hash field and the Digital Signature field of the RSA the SHA-1 hash algorithm to generate Cryptographically Generated
Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.) Addresses (CGA) [rfc3972], the contents of the Key Hash field and the
in the PKIX certificates [rfc5280] used for the router authorization Digital Signature field of the RSA Signature option. It also uses a
in the ADD process. Recently there have been demonstrated attacks hash algorithm (SHA-1, MD5, etc.) within the digital signature in the
against the collision free property of such hash functions X.509 certificates [rfc5280] for the router authorization in the
[sha1-coll], and attacks against the PKIX X.509 certificates that use Authorizaton Delegation Discovery (ADD) process.
the MD5 hash algorithm [x509-coll] This document analyzes the effects
of those attacks and other possible hash attacks on the SEND
protocol. The document proposes changes to make it resistant to such
attacks.
2. Impact of collision attacks on SeND There is a great variaty of hash function, but only MD5 and SHA-1 are
in the wide use. They both derive from MD4, which has been well
known for its weaknesses. First hash attacks affected the
compression function of MD5, while the latest hash attacks against
SHA-1 delivered colliding hash in significantlly smaller number of
rounds compared to the brute force attack number of rounds
[sha1-coll]. Attacks against X.509 certificates improved as well,
and researchers demonstrated colliding certificate with MD5 hash,
both for the same and different identities [x509-coll].
Depending on the way of use of hash algorithm, Internet protocol can
be affected by the weakness of the underlaying hash function. This
document analyzes uses of hash algorithms in SEND, possible weakness
that hash attacks could introduce to SEND, and possible ways to make
SEND resistant to such attacks.
2. Terminology
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
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 recommended
recommended by [rfc4270] and [new-hashes]. approach [rfc4270] [new-hashes].
The basic cryptographic properties of a hash function are that it is Basic cryptographic properties of a hash function are that it is both
both one-way and collision free. There are two attacks against the one-way and collision free. There are two attacks against the one-
one-way property, the first-preimage attack and the second-preimage way property, the first-preimage attack and the second-preimage
attack. In the first-preimage attack, given a knowledge of a attack. In the first-preimage attack, given a knowledge of a
particular value hash(m), an attacker finds an input message m' such particular hash value h, an attacker finds an input message m such
that hash(m') yields hash(m). The second-preimage attack deals with that hash(m) = h. The second-preimage attack deals with fixed
the fixed messages. Given a knowledge of a fixed value m used as the messages. Given a knowledge of a fixed value m used as the input
input message to the hash function, an attacker finds a different message to the hash function, an attacker finds a different value m'
value m' that yields hash(m)=hash(m'). Supposing that the hash that yields hash(m)=hash(m'). Supposing that the hash function
function produces an n-bit long output, since each output is equally produces an n-bit long output, since each output is equally likely,
likely, an attack takes an order of 2^n operations to be successful. an attack takes an order of 2^n operations to be successful. Due to
Due to the birthday attack, if the hash function is supplied with a the birthday attack, if the hash function is supplied with a random
random input, it returns one of the k equally-likely values, and the input, it returns one of the k equally-likely values, and the number
number of operations can be reduced to the number of 1.2*2^(n/2) of operations can be reduced to the number of 1.2*2^(n/2) operations.
operations. However, attacks against the one-way property are not Attack against the collision-free property deals with two fixed
feasible yet [rfc4270]. Up to date, all demonstrated attacks are messages, both produced by an attacker. Attacker produces two
attacks against a collision-free property, in which an attacker different messages, m and m', such that hash(m)=hash(m'). Up to
produces two different messages m and m' such that hash(m)=hash(m'). date, all demonstrated attacks are attacks against a collision-free
The rest of the document deals with the collision attacks. property. Attacks against the one-way property are not yet feasible
[rfc4270].
We will analyze the impact of hash attacks on SeND case by case in The strength of Internet protocol does not have to be necessarily
this section. Through our analysis, we also discuss whether we affected by the weakness of the underlaying hash function. The
should support the hash agility in SeND. appropriate way of use of the hash algorithm will keep the protocol
immune, no matter of the hash algorithm weaknesses. Out of many
possible hash algorithm uses, such as non-repudiable digital
signatures, certificate digital signatures, message authentication
with shared secrets, fingerprints, only the first two can introduce
weaknesses to the Internet protocol [rfc4270]. The rest of the
section analyzes the impact of hash attacks, mainly collision
attacks, on SEND by the cases of use. Through our analysis, we also
discuss whether we should support the hash agility in SEND.
2.1. Attacks against CGAs in stateless autoconfiguration 3.1. Attacks against CGAs in stateless autoconfiguration
Hash functions are used in the stateless autoconfiguration process Hash functions are used in the stateless autoconfiguration process
that is based on CGAs. Impacts of collision attacks on current uses that is based on CGAs. Impacts of collision attacks on current uses
of CGAs are analyzed in the update of the CGA specification of CGAs and the CGA hash agility are analyzed in the update of the
[rfc4982], which also enables CGAs to support the hash agility. CGAs CGA specification [rfc4982]. CGAs provide the proof-of-ownership of
provide the proof-of-ownership of the private key corresponding to the private key corresponding to the public key used to generate the
the public key used to generate the CGA. CGAs do not deal with the CGA. The collision attack against the CGA assume that attacker
non-repudiation feature, while collision attacks are mainly about generates two different sets of CGA Parameters that result in the
affecting the non-repudiation feature, i.e. in the collision attack same hash value. Since CGAs do not deal with the non-repudiation
against the CGA both of the CGA Parameters sets are choosen by an feature, and both sets are chosen by the attacker, this attack is not
attacker, which is not useful in the real-world scenarios. useful in any real-world scenario. CGA-based protocols, including
Therefore, as [rfc4982] points out CGA based protocols, including SEND, are not affected by the recent collision attacks. If pre-image
SeND, are not affected by the recent collision attacks. Regarding attacks were feasible, an attacker would find colliding CGA
the pre-image attacks, if pre-image attacks were feasible, an Parameters for the victim's CGA, and produce the Key Hash field and
attacker would manage to find the new CGA Parameters based on the the Digital Signature field afterwards using the new public key.
associated, victim's CGA, and produce the Key Hash field and the Since the strength of all hashes in SEND depends on the strength of
Digital Signature field afterwards using the new public key. Since the CGA, the pre-image attack is potentially dangerous, but it is not
the strength of all hashes in SEND depends on the strength of the yet feasible.
CGA, the pre-image attack is potentially dangerous, but it is not yet
feasible.
2.2. Attacks against PKIX certificates in ADD process 3.2. Attacks against X.509 certificates in ADD process
The second use of hash functions is for the router authorization in Another use of hash functions is for the router authorization in the
the ADD process. Router sends to a host a certification path, which ADD process. Router sends to a host a certification path, which is a
is a path between a router and the hosts's trust anchor, consisting path between a router and the host's trust anchor, consisting of
of PKIX certificates. Researchers demonstrated attacks against PKIX X.509 certificates. Researchers demonstrated attacks against X.509
certificates with MD5 signature, in 2005 [new-hashes] and in 2007 certificates with MD5 signature in 2005 [new-hashes] and in 2007
[x509-coll]. In 2005 were constructed the original and the false [x509-coll]. In 2005 researchers constructed colliding certificates
certificate that had the same identity data and the same digital with the same distinguished name, different public keys, and
signature, but different public keys [new-hashes]. The problem for identical signatures, based on different public keys. The problem
the attacker is that two certificates with the same identity are not for the attacker is that two certificates with the same identity are
actually useful in real-world scenarios, because the Certification not actually useful in real-world scenarios, because the
Authority is not allowed to provide such two certificates. In Certification Authority can take care of not allowing to provide such
addition, attacks against the human-readable fields demand much more two certificates. In addition, attacks against the human-readable
effort than the attacks against non human-readable fields, such as a fields demand much more effort than the attacks against non human-
public key field. In case of the identity field, an attacker is readable fields, such as a public key field. In case of the identity
faced with the problem of the prediction and the generation of the field, an attacker is faced with the problem of the prediction and
false but meaningful identity data, which at the end might be the generation of the false but meaningful identity data, which at
revealed by the Certification Authority. Thus, in practice, the end might be revealed by the Certification Authority. Thus, in
collision attacks do not affect non human-readable parts of the practice, there is a very low probability that collision attacks
certificate. In 2007 were demonstrated certificates which differ in affect non human-readable parts of the certificate. In 2007
the identity data and in the public key, but still result in the same researchers demonstrated colliding certificates which differ in the
signature value. In such attack, even if an attacker produced such identity data and in the public key, but still result in the same
two certificates in order to claim that he was someone else, he still signature value. Even in this case, the real-world scenarios prevent
needs to predict the content of all fields appearing before the the hash algorithm weaknesses to introduce vulnerabilities of the
certificate or the protocol. Even if an attacker produced such two
colliding certificates in order to claim that he was someone else, he
still needs to predict the content of all fields appearing before the
public key, e.g. the serial number and validity periods. Although a public key, e.g. the serial number and validity periods. Although a
relying party cannot verify the content of these fields (each relying party cannot verify the content of these fields (each
certificate by itself is unsuspicious), the Certification Authority certificate by itself is unsuspicious), the Certification Authority
keeps track of those fields and it can reveal the false certificate keeps track of those fields and it can reveal the false certificate
during the fraud analysis. Regarding certificates in SeND, during the fraud analysis. Even though the real-world scenarios make
potentially dangerous are attacks against the X.509 certificate SEND immune to recent hash attacks introduced through X.509
extensions. For example, an attack against the IP address extension certificates, theoretically they are possible, but only in case of
would enable the router to advertize the changed IP prefix range, the human-readable fields. Regarding X.509 certificates in SEND,
although, not broader than the prefix range of the parent certificate biggest concer are attacks against the RFC3779 IP address extension
in the ADD chain. which would enable the bogus router to advertize the changed IP
prefix range, if the IP prefix range used, although, not broader than
The public-private key pair associated to the Router Authorization the prefix range of the parent certificate in the ADD chain. Adding
Certificate in the ADD process is used both for the CGA generation some form of randomness to human-readble data would prevent such
and for the message signing. Since in the future CGAs might be used attacks, which can be considered once when the collision attack
only with certificates, attacks against certificates are even more improve.
dangerous. Generally, the most dangerous are attacks against middle-
certificates in the certification path, where for the cost of the one
false certificate, an attacker launches an attack on multiple
routers. Regarding the attacks against certificates in SEND, the
only attack that SEND is not suspectable to, is an attack against the
Trust Anchor's certificate because it is not exchanged in SeND
messages, i.e. it is not the part of the certification path in the
ADD process.
2.3. Attacks against the Digital Signature in the RSA Signature option 3.3. Attacks against the Digital Signature in the RSA Signature option
The computation of the Digital Signature field is described in The computation of the Digital Signature field is described
[rfc3971]. The digital signature in the RSA Signature option is [rfc3971]. It is produced as the SHA-1 hash over the IPv6 addresses,
produced as the SHA-1 hash over the IPv6 addresses, the ICMPv6 the ICMPv6 header, the ND message and other fields, e.g. the Message
header, the ND message and other fields, e.g. the Message Type Tag Type Tag and ND options, and signed with the sender's private key.
and ND options [rfc3971], that is signed with the sender's private Private key corresponds to the public key in the CGA parameters
key. The sender's private key corresponds to the public key in the structure. It is usually authorized through CGAs. The Digital
CGA parameters structure. It is usually authorized through CGAs. Signature field is vulnerable to recent collision attacks. Possible
Possible attack on such explicit digital signature is a typical non- attack on such explicit digital signature is a typical non-
repudiation attack, i.e. the Digital Signature field is vulnerable to repudiation attack. An attacker produces two different messages, m
the collision attack. An attacker produces two different messages, m
and m', where hash(m) = hash(m'). He underlays one of the messages and m', where hash(m) = hash(m'). He underlays one of the messages
to be signed with the key authorized through CGAs, but uses another to be signed with the key authorized through CGAs, but uses another
message afterwards. If a SEND attacker would manage to find the message afterwards. However, the structure of at least one of two
collision in the message made of the ICMPv6 and ND fields mentioned messages in a collision attack is strictly predefined. The previous
in the beginning of the paragraph, he could underlay the false requirement makes this collision attack to be much more then the
message. The fields that make sense to be changed are ND fields, as simple collision attack, and requires the attacker to know or predict
opposite to the ICMPv6 fields which would be easy to reveal. the communication context. Theoretically this attack could harm
However, as denoted in [rfc4270], the structure of at least one of SEND, but in real-world situation is extremely hard to achieve it.
two messages (m, m') in a collision attack is strictly predefined.
The previous requirement complicates the collision attack, but we
have to take into account that a variant of SHA-1 was already
affected by recent collision attacks and we have to prepare for
future improved attacks.
2.4. Attacks against the Key Hash field in the RSA Signature option 3.4. Attacks against the Key Hash field in the RSA Signature option
The Key Hash field is a SHA-1 hash of the public key from the CGA The Key Hash field in the RSA Signature option is a SHA-1 hash of the
Parameters structure in the CGA option. The pre-image attack against public key from the CGA Parameters structure in the CGA option. It
the Key Hash field is potentially dangerous, as in the case of all is a fingerprint that provides the integrity protection.
other hashes in SEND, because the Key Hash field contains a non Fingerprints are generally not affected by the collision attacks
human-readable data. However the Key Hash field is not suspectable because they involve random data as one of the inputs, which prevents
to the collision attack, since in the collision attack an attacker recent collision attacks. In addition, context of the SEND message
itself chooses both keys, k and k', where hash(k) = hash(k'). The and the protocol makes this attack unable to introduce new
reason for the former is that the associated public key is already vulnerabilities to SEND. An attacker has to produce both keys, k and
authorized through the use of CGAs, and possibly the certification k', such that hash(k) = hash(k'). Since the key is authorized
path in the ADD process. through CGA, and possibily through the certification in the ADD
process, this attack is of no use for the attacker. The pre-image
attack against the Key Hash field, if it was possible, would affect
SEND since the Key Hash field contains a non human-readable data.
3. Support for the hash agility in SeND 4. Support for the hash agility in SEND
While all of analyzed hash functions in SeND are theoretically Previous section analyzed that CGAs and fingerprints affected by the
affected by hash attacks, these attacks indicate the possibility of collision attacks (Key Hash field of the Send message) do not
future real-world attacks. In order to increase the future security introduce new vulnerabilities to SEND. Digital signatures in the
of SeND, the following possible approaches can be used. Digital Signature field of the SEND message and X.509 certificate
theoretically are affected by the recent collision attacks, but the
SEND context prevents those attacks of almost any use in the real-
world scenarios. However, recent attacks indicate the possibility
for the future improved real-world attacks. Researchers advise to
migrate away from currently used hash algorithms. In order to
increase the future security of SEND, we suggest the support for the
hash and algorithm agility in SEND.
o The most effective and secure would be to bind the hash function o The most effective and secure would be to bind the hash function
option with something that can not be changed at all, like option with something that can not be changed at all, like
[rfc4982] does for CGA - encoding the hash function information [rfc4982] does for CGA. It encodes the hash function information
into addresses. But, there is no possibilty to do that in SeND. into addresses. We could decide to use by default the same hash
We could decide to use by default the same hash function in SeND function in SEND as in CGA. The security of all hashes in SEND
as in CGA. The security of all hashes in SeND depends on CGA, ie. depends on CGA, i.e. if an attacker breaks CGA, all other hashes
if an attacker could break CGA, all other hashes are automatically are automatically broken. The use of the hash algorithm embedded
broken. From the security point of view, at the moment, this in CGA protects from the bidding down attacks. From the security
solution is more reasonable then defining different hash algorithm point of view, at the moment, this solution is more reasonable
for each hash. Additionally, if using the hash algorithm from the then defining different hash algorithm for each hash. The
CGA, no bidding down attacks are possible. On the other hand, disadvantage of this solution is that it introduces the limitation
this solution introduces the limition for SEND to be used for SEND to be used exclusively with CGAs.
exclusively with CGAs.
o Another solution is to incorporate the Hash algorithm option into o Another solution is to incorporate the Hash algorithm option into
the SeND message. However, if the algorithm is defined in the the SEND message. This solution is vulnerable to the bidding down
Hash algorithm option in the SeND message, it is vulnerable to the attack.
bidding down attack.
o The third possible solution is to encode the algorithm in the CGA. o The third possible solution is to encode the algorithm in the CGA.
However, this will reduce the strength of the CGAs and make them This would reduce the strength of the CGA and make it vulnerable
vulnerable to brute force attacks. to brute force attacks.
o One of the possible solutions is also the hybrid solution, i.e. to o Possible solution is also the hybrid solution which would require
require the hash algorithm to be the same as CGA, if CGA option is the hash algorithm to be the same as CGA, if CGA option is
present, and to use the Hash agility option if the CGA option is present, and to use the Hash agility option if the CGA option is
not present. not present. In such way, SEND is not bound exclusively to CGA.
3.1. The negotiation approach for the SEND hash agility
None of the previous solutions supports the negotiation of the hash
function. Another possibility is to use a negotiation approach for
the SEND hash agility such as the one based on the Supported
Signature Algorithm option described in [sig-agility]. Based on the
processing rules described in [sig-agility] nodes find the
intersection between the sender's and the receiver's supported
signature algorithms set, as well as the preferred signature
algorithm. When producing and validating hashes in SEND, nodes must
observe the following rules:
o In the ADD process, if any of the certificates in the
certification path uses the signature algorithm which is not one
of the signature algorithms negotiated in the signature agility
process through the use of the Supported Signature Algorithms
option, nodes must reject the Router Authorization certificate.
o In order to produce the Digital Signature field, nodes must use
the signature algorithm negotiated in the signature agility
process through the use of the Supported Signature Algorithms
option.
o In order to produce the Key Hash field, nodes must use the hash o None of the previous solutions supports the negotiation of the
algorithm defined associated to the signature algorithm negotiated hash function. One of possible solutions is the negotiation
in the signature agility process through the use of the Supported approach for the SEND hash agility based on the Supported
Signature Algorithms option. Signature Algorithm option described in [sig-agility]. Based on
the processing rules described in [sig-agility] nodes find the
intersection between the sender's and the receiver's supported
signature algorithms set.
4. 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.
The negotiation approach for the hash agility in SeND based on the The negotiation approach for the hash agility in SEND based on the
Supported Signature Algorithms option is vulnerable to bidding-down Supported Signature Algorithms option is vulnerable to bidding-down
attacks, which is usual in the case of any negotiation approach. attacks, which is usual in the case of any negotiation approach.
This issue can be mitigated with the appropriate local policies. This issue can be mitigated with the appropriate local policies.
5. IANA Considerations
There have been no IANA considerations so far in this document.
6. References 6. References
6.1. Normative References 6.1. Normative References
[new-hashes]
Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005.
[pk-agility]
Cheneau, T., Maknavicius, M., Sean, S., and M. Vanderveen,
"Support for Multiple Signature Algorithms in
Cryptographically generated Addresses (CGAs)",
draft-cheneau-cga-pk-agility-00 (work in progress),
February 2009.
[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.
[rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [rfc4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashed in Internet Protocols", RFC 4270, November 2005. Hashed in Internet Protocols", RFC 4270, November 2005.
[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.
[sig-agility]
Cheneau, T. and M. Maknavicius, "Signature Algorithm
Agility in the Secure Neighbor Discovery (SEND) Protocol",
draft-cheneau-send-sig-agility-01 (work in progress),
May 2010.
6.2. Informative References
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[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 rfc5280, May 2008. (CRL) Profile", RFC rfc5280, May 2008.
6.2. Informative References
[new-hashes]
Bellovin, S. and E. Rescorla, "Deploying a New Hash
Algorithm", November 2005.
[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.
[sig-agility]
Cheneau, T., Maknavicius, M., Shen, S., and M. Vanderveen,
"Signature Algorithm Agility in the Secure Neighbor
Discovery (SEND) Protocol",
draft-cheneau-csi-send-sig-agility-00 (work in progress),
October 2009.
[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.
Authors' Addresses Authors' Addresses
Ana Kukec Ana Kukec
University of Zagreb University of Zagreb
Unska 3 Unska 3
 End of changes. 42 change blocks. 
227 lines changed or deleted 245 lines changed or added

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