draft-ietf-csi-hash-threat-02.txt   draft-ietf-csi-hash-threat-03.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: Informational S. Krishnan
Expires: July 10, 2009 Ericsson Expires: September 10, 2009 Ericsson
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
January 6, 2009 March 9, 2009
SeND Hash Threat Analysis SeND Hash Threat Analysis
draft-ietf-csi-hash-threat-02 draft-ietf-csi-hash-threat-03
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. 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.
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 July 10, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 the SHA-1 [sha-1] hash
algorithm and PKIX certificates [rfc3280] and does not provide algorithm and PKIX 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Impact of collision attacks on SeND . . . . . . . . . . . . . 5 3. Impact of collision attacks on SeND . . . . . . . . . . . . . 6
3.1. Attacks against CGAs in stateless autoconfiguration . . . 5 3.1. Attacks against CGAs in stateless autoconfiguration . . . 6
3.2. Attacks against PKIX certificates in ADD process . . . . . 5 3.2. Attacks against PKIX certificates in ADD process . . . . . 7
3.3. Attacks against Digital Signature in RSA Signature 3.3. Attacks against the Digital Signature in the SEND
option . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Universal Signature option . . . . . . . . . . . . . . . . 8
3.4. Attacks against Key Hash in RSA Signature option . . . . . 7 3.4. Attacks against the Key Hash in the SEND Universal
4. Support for the hash agility in SeND . . . . . . . . . . . . . 8 Signature option . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Support for the hash agility in SeND . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.1. The negotiation approach for the SEND hash agility . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 and the Digital Signature fields of the RSA of the Key Hash field and the Digital Signature field of the RSA
signature. It also uses a hash algorithm (SHA-1,MD5 etc.) in the Signature option. It also uses a hash algorithm (SHA-1, MD5, etc.)
PKIX certificates [rfc3280] used for the router authorization in the in the PKIX certificates [rfc5280] used for the router authorization
ADD process. Recently there have been demonstrated attacks against in the ADD process. Recently there have been demonstrated attacks
the collision free property of such hash functions [sha1-coll]. against the collision free property of such hash functions
There have also been attacks on the PKIX X.509 certificates that use [sha1-coll], and attacks on the PKIX X.509 certificates that use the
the MD5 hash algorithm [x509-coll] This document analyzes the effects MD5 hash algorithm [x509-coll] This document analyzes the effects of
of such attacks and other hash attacks on the SEND protocol and those attacks and other possible hash attacks on the SEND protocol.
proposes changes to make it resistant to such attacks. The document proposes changes to make it resistant to such attacks.
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] and [new-hashes].
[rfc4270] and [new-hashes], we will analyze the impact of these
attacks on SeND case by case in this section. Through our analysis,
whether we should support hash agility on SeND is also discussed.
Up to date, all demonstrated attacks are attacks against a collision- The basic cryptographic properties of a hash function are that it is
free property. An attacker produces two messages which result in the both one-way and collision free. There are two attacks against the
same hash. Attacks against the one-way property are not yet feasible one-way property, the first-preimage attack and the second-preimage
[rfc4270]. There are two attacks against one property. In the attack. In the first-preimage attack, given a knowledge of a
first-preimage attack, based on the hash of the real message, an particular value hash(m), an attacker finds an input message m' such
attacker finds a false message which results in the same hash. In that hash(m') yields hash(m). The second-preimage attack deals with
the second-preimage attack an attacker based on the real message the fixed messages. Given a knowledge of a fixed value m used as the
itself, finds the false message which results in the same hash. input message to the hash function, an attacker finds a different
value m' that yields hash(m)=hash(m'). Supposing that the hash
function produces an n-bit long output, since each output is equally
likely, an attack takes an order of 2^n operations to be successful.
Due to the birthday attack, if the hash function is supplied with a
random input, it returns one of the k equally-likely values, and the
number of operations can be reduced to the number of 1.2*2^(n/2)
operations. However, attacks against the one-way property are not
yet feasible [rfc4270]. Up to date, all demonstrated attacks are
attacks against a collision-free property, in which an attacker
produces two different messages m and m' such that hash(m)=hash(m').
We will analyze the impact of hash attacks on SeND case by case in
this section. Through our analysis, we also discuss whether we
should support the hash agility in SeND.
3.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 CGA specification [rfc4982], of CGAs are analyzed in the update of the CGA specification
which also enables CGAs to support hash agility. CGAs provide proof- [rfc4982], which also enables CGAs to support the hash agility. CGAs
of-ownership of the private key corresponding to the public key used provide the proof-of-ownership of the private key corresponding to
to generate CGA, and they don't deal with the non-repudiation the public key used to generate the CGA. CGAs do not deal with the
feature, while collision attacks are mainly about affecting non- non-repudiation feature, while collision attacks are mainly about
repudiation feature. CGAs are not suspectable to the collision affecting the non-repudiation feature, i.e. in the collision attack
attacks. In the collision attack, an attacker finds two keys (and against the CGA both of the CGA Parameters sets are choosen by an
other CGA parameters) K and K', where CGA = hash(K, ..) = hash(K', attacker, which is not useful in the real-world scenarios.
..). Since both keys have to be choosen by an attacker, CGAs are not Therefore, as [rfc4982] points out CGA based protocols, including
vulnerable to the collision attack. So, as [rfc4982] points out CGA SeND, are not affected by the recent collision attacks. Regarding
based protocols, including SeND, are not affected by the recent the pre-image attacks, if pre-image attacks were feasible, an
collision attacks. But, CGAs are vulnerable to the preimage attack attacker would manage to find the new CGA Parameters based on the
in which an attacker could manage to find the false key K' based on associated, victim's CGA, and produce the Key Hash field and the
node's CGA = hash(K, ..), use key K' to produce the Key Hash field Digital Signature field afterwards using the new public key. Since
and to sign the SeND message afterwards. In that case, an attacker the strength of all hashes in SEND depends on the strength of the
just has to break the CGA, and all other hashes are automatically CGA, the pre-image attack is potentially dangerous, but it is not yet
broken, because an attacker can use the false key K' to produce all feasible.
other hashes. But up to date, the preimage attacks are not yet
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 the ADD process. Router sends to a host a certification path, which
path between a router and hosts's trust anchor and consists of PKIX is a path between a router and the hosts's trust anchor, consisting
certificates. Researchers demonstrated attacks against PKIX of 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 were constructed the original and the false
certificate that had the same identity data and the same digital
In 2005 they succeeded to construct the original and the false signature, but different public keys [new-hashes]. The problem for
certificate that had the same identity data and digital signature, the attacker is that two certificates with the same identity are not
but different public keys [new-hashes]. The problem for the attacker actually useful in real-world scenarios, because the Certification
is that two certificates with the same identity are not very useful Authority is not allowed to provide such two certificates. In
in real-world scenarios, while Certification Authority is not allowed addition, attacks against the human-readable fields demand much more
to provide such two certificates. Generally, attacks against the effort than the attacks against non human-readable fields, such as a
human-readable fields demand much more effort than the attacks public key field. In case of the identity field, an attacker is
against non human-readable fields, such as a public key field. In faced with the problem of the prediction and the generation of the
case of the identity field, an attacker is faced with the problem of false but meaningful identity data, which at the end might be
the prediction and the generation of the false but meaningful revealed by the Certification Authority. Thus, in practice,
identity data, which at the end might be revealed by the collision attacks do not affect non human-readable parts of the
Certification Authority. Thus, in practice, collision attacks do not certificate. In 2007 were demonstrated certificates which differ in
affect non human-readable parts of the certificate. the identity data and in the public key, but still result in the same
signature value. In such attack, even if an attacker produced such
In 2007 were demonstrated certificates which differ in the identity two certificates in order to claim that he was someone else, he still
data and public key, but still result in the same signature value. needs to predict the content of all fields appearing before the
In such attack, even if an attacker produces such two certificates in public key, e.g. the serial number and validity periods. Although a
order to claim that he is someone else, he still needs to predict the relying party cannot verify the content of these fields (each
content of all fields appearing before the public key, eg. serial certificate by itself is unsuspicious), the Certification Authority
number or validity periods. Although a relying party cannot verify keeps track of those fields and it can reveal the false certificate
the content of these fields (each certificate by itself is during the fraud analysis. Regarding certificates in SeND,
unsuspicious), the CA keeps track of those fields and during the potentially dangerous are attacks against the X.509 certificate
fraud analysis, the false certificate can be revealed. Future extensions. For example, an attack against the IP address extension
attacks might affect other human-readable fields. Attacks against would enable the router to advertize the changed IP prefix range,
the validity period field and the IP address extension might have an although, not broader than the prefix range of the parent certificate
implication to the current SeND protocol. An attack against the IP in the ADD chain.
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 public-private key pair associated to the Router Authorization
for message signing. In the future, CGA might not be used at all in Certificate in the ADD process is used both for the CGA generation
SeND, just certificates. Thus, attacks against certificates are and for the message signing. Since in the future CGAs might be used
potentially very dangerous. Generally, the most dangerous are only with certificates, attacks against certificates are even more
attacks against middle-certificates in the certification path, where dangerous. Generally, the most dangerous are attacks against middle-
for the cost of one false certificate, attacker launches attack on certificates in the certification path, where for the cost of the one
multiple routers. In such scenarios, we will be at least safe from false certificate, an attacker launches an attack on multiple
attacks against Trust Anchor's certificate because it is not routers. Regarding the attacks against certificates in SEND, the
exchanged in SeND messages. 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.
3.3. Attacks against Digital Signature in RSA Signature option 3.3. Attacks against the Digital Signature in the SEND Universal
Signature option
The digital signature in RSA Signature option is produced as the The SEND Universal Signature option is an updated version of the RSA
SHA-1 hash of IPv6 addresses, ICMPv6 header, ND message and other Signature option, defined in [sig-agility]. In combination with the
fields like Message Type Tag and ND options [rfc3971], and is signed public key agility support described in [pk-agility], it allows the
with the sender's private key, which corresponds to the public key node to use the public key signing algorithm different then the RSA-
from the CGA parameters structure and is authorized usually through based signing algorithm. No matter of the type of the SEND Universal
CGAs. The possible attack on such explicit digital signature is Signature option, the Digital Signature field is computed in the same
typical non-repudiation attack. The Digital Signature field is way as the Digital Signature field of the RSA Signature option
vulnerable to the collision attack. In such collision attack an descibed in [rfc3971]. The digital signature in the RSA Signature
attacker produces two messages M and M', where hash(M) = hash(M'), option is produced as the SHA-1 hash over the IPv6 addresses, the
underlays one of the messages to be signed with authorized keys ICMPv6 header, the ND message and other fields, e.g. the Message Type
(through CGAs), but uses another message afterwards. However, the Tag and ND options [rfc3971], that is signed with the sender's
structure of at least one of two messages in collision attack is private key. The sender's private key corresponds to the public key
strictly predefined [rfc4270]. But we have to take into account that in the CGA parameters structure. It is usually authorized through
a variant of SHA-1 was already affected by recent collision attacks CGAs. The possible attack on such explicit digital signature is a
and we have to prepare for future improved attacks. typical non-repudiation attack, i.e. the Digital Signature field is
vulnerable to the collision attack. An attacker produces two
different messages, m 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 message afterwards. However, as denoted in
[rfc4270], the structure of at least one of two messages 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.
3.4. Attacks against Key Hash in RSA Signature option 3.4. Attacks against the Key Hash in the SEND Universal Signature
option
Key Hash field in the RSA Signature option is a SHA-1 hash of the The Key Hash field in the SEND Universal signature option is a SHA-1
public key from the CGA parameters structure in the CGA option of hash of the public key from the CGA Parameters structure in the CGA
SeND message. Key Hash field is potentially dangerous because it option. The pre-image attack against the Key Hash field is
contains a non human-readable data. Since in the collision attack an potentially dangerous, as in the case of all other hashes in SEND,
attacker itself chooses both keys, K and K', where hash(K) = because the Key Hash field contains a non human-readable data.
hash(K'), the Key Hash field is not suspectable to the collision However the Key Hash field is not suspectable to the collision
attack. The preimage attack in which an attacker derives the key K' attack, since in the collision attack an attacker itself chooses both
based on hash(K) could be theoretically more useful. But even in keys, k and k', where hash(k) = hash(k'). The reason for the former
that case, if an attacker signes the SeND message with the key K', he is that the associated public key is already authorized through the
has to break also the CGA, since the Digital Signature is verified use of CGAs, and possibly the certification path in the ADD process.
against the CGA and possibly against a certification path.
4. 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 While all of analyzed hash functions in SeND are theoretically
affected by recent hash attacks, these attacks indicate the affected by hash attacks, these attacks indicate the possibility of
possibility of future real-world attacks. In order to increase the future real-world attacks. In order to increase the future security
future security of SeND, we suggest the support for the hash and of SeND, we suggest the support for the hash and algorithm agility in
algorithm agility in SeND. SeND.
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 [rfc4982] option with something that can not be changed at all, like
does for CGA - encoding the hash function information into addresses. [rfc4982] does for CGA - encoding the hash function information
But, there is no possibilty to do that in SeND. We could decide to into addresses. But, there is no possibilty to do that in SeND.
use by default the same hash function in SeND as in CGA. The We could decide to use by default the same hash function in SeND
security of all hashes in SeND depends on CGA, ie. if an attacker as in CGA. The security of all hashes in SeND depends on CGA, ie.
could break CGA, all other hashes are automatically broken. From the if an attacker could break CGA, all other hashes are automatically
security point of view, at the moment, this solution is more broken. From the security point of view, at the moment, this
reasonable then defining different hash algorithm for each hash. solution is more reasonable then defining different hash algorithm
Additionally, if using the hash algorithm from the CGA, no bidding for each hash. Additionally, if using the hash algorithm from the
down attacks are possible. CGA, no bidding down attacks are possible. On the other hand,
this solution introduces the limition for SEND to be used
exclusively with CGAs.
Another solution is to incorporate the Hash algorithm option into o Another solution is to incorporate the Hash algorithm option into
SeND message, and use different hash algorithms for different hashes, the SeND message. However, if the algorithm is defined in the
or the same algorithm for all hashes. As already mentioned, from the Hash algorithm option in the SeND message, it is vulnerable to the
security point of view, it is reasonable to define just one bidding down attack.
algorithm, because additional algorithms does not increase the
security. If that algorithm is defined in the Hash algorithm option o The third possible solution is to encode the algorithm in the CGA.
in SeND message, it is vulnerable to the bidding down attack. On the However, this will reduce the strength of the CGAs and make them
other hand, different algorithms provides additional flexibility, and vulnerable to brute force attacks.
in the future SeND might be used completely without CGAs.
o One of the possible solutions is also the hybrid solution, i.e. to
require 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
not present.
4.1. The negotiation approach for the SEND hash agility
None of the previous solutions supports the negotiation of the hash
function. Therefore we propose the negotiation approach for the SEND
hash agility 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
algorithm defined associated to the signature algorithm negotiated
in the signature agility process through the use of the Supported
Signature Algorithms option.
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 The negotiation approach for the hash agility in SeND based on the
Supported Signature Algorithms option is vulnerable to bidding-down
This document only analyzes the possible hash threats in SEND and attacks, which is usual in the case of any negotiation approach.
introduces the possible mechanisms to support hash agility. The This issue can be mitigated with the appropriate local policies.
actual SEND extensions are defined in other documents. There are no
IANA actions required by this document.
7. References 6. References
7.1. Normative References 6.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.
[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.
7.2. Informative References [sig-agility]
Cheneau, T. and M. Maknavicius, "Signature Algorithm
Agility in the Secure Neighbor Discovery (SEND) Protocol",
draft-cheneau-send-sig-agility-00 (work in progress),
February 2009.
6.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.
[rfc3280] Housley, R., "Internet X.509 Public Key Infrastructure [rfc5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Certificate and Certificate Revocation List (CRL) Housley, R., and W. Polk, "Internet X.509 Public Key
Profile", RFC rfc3280, April 2002. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC rfc5280, May 2008.
[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
skipping to change at page 13, line 4 skipping to change at line 400
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., 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
Copyright Notice
Copyright (c) 2009 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.
 End of changes. 29 change blocks. 
172 lines changed or deleted 257 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/