Network Working Group                                         M. Bagnulo
Request for Comments: 4982                                          UC3M
Updates: 3972                                                   J. Arkko
Category: Standards Track                                       Ericsson
                                                               July 2007
Network Working Group                                         M. Bagnulo
Request for Comments: 4982                                          UC3M
Updates: 3972                                                   J. Arkko
Category: Standards Track                                       Ericsson
                                                               July 2007

Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)


Status of This Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。

Copyright Notice


Copyright (C) The IETF Trust (2007).




This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.


Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
   4.  Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
     4.1.  Where to Encode the Hash Function?  . . . . . . . . . . . . 4
   5.  CGA Generation Procedure  . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
   4.  Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
     4.1.  Where to Encode the Hash Function?  . . . . . . . . . . . . 4
   5.  CGA Generation Procedure  . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
1. Introduction
1. 介绍

Recent attacks to currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [6] [10] to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation.


This document performs such analysis for the Cryptographically Generated Addresses (CGAs) defined in [2]. The first conclusion of the analysis is that the security of the protocols using CGAs is not affected by the recently available attacks against hash functions. The second conclusion of the analysis is that the hash function used is hard coded in the CGA specification. This document updates the CGA specification [2] to enable the support of alternative hash functions. In order to do so, this document creates a new registry managed by IANA to register the different hash algorithms used in CGAs.


2. Terminology
2. 术语

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 [1].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。

3. Impact of Collision Attacks in CGAs
3. CGAs中碰撞攻击的影响

Recent advances in cryptography have resulted in simplified attacks against the collision-free property of certain commonly used hash functions [6] [10], including SHA-1 that is the hash function used by CGAs [2]. The result is that it is possible to obtain two messages, M1 and M2, that have the same hash value with much less than 2^(L/2) attempts. We will next analyze the impact of such attacks in the currently proposed usages of CGAs.


As we understand it, the attacks against the collision-free property of a hash function mostly challenge the application of such hash functions, for the provision of non-repudiation capabilities. This is because an attacker would be capable to create two different messages that result in the same hash value and it can then present any of the messages interchangeably (for example after one of them has been signed by the other party involved in the transaction). However, it must be noted that both messages must be generated by the same party.


As far as we understand, current usages of CGAs does not include the provision of non-repudiation capabilities, so attacks against the collision-free property of the hash function do not enable any useful attack against CGA-based protocols.


Current usages of the CGAs are basically oriented to prove the ownership of a CGA and then bind it to alternative addresses that can be used to reach the original CGA. This type of application of the CGA include:


o The application of CGAs to protect the shim6 protocol [7]. In this case, CGAs are used as identifiers for the established communications. CGA features are used to prove that the owner of the identifier is the one that is providing the alternative addresses that can be used to reach the initial identifier. This is achieved by signing the list of alternative addresses available in the multihomed host with the private key of the CGA.

o CGAs在保护shim6协议中的应用[7]。在这种情况下,cga被用作所建立的通信的标识符。CGA特征用于证明标识符的所有者是提供可用于访问初始标识符的替代地址的所有者。这是通过使用CGA的私钥对多宿主机中可用的备选地址列表进行签名来实现的。

o The application of CGAs to secure the IPv6 mobility support protocol [8] as proposed in [9]. In this case, the CGAs are used as Home Addresses and they are used to prove that the owner of the Home Address is the one creating the binding with the new Care-off Address. Similarly to the previous case, this is achieved by signing the Binding Update message carrying the Care-off Address with the private key of the CGA.

o 应用CGA保护IPv6移动支持协议[8],如[9]所述。在这种情况下,CGA用作家庭地址,用于证明家庭地址的所有者是创建与新转交地址绑定的人。与前一种情况类似,这是通过使用CGA的私钥对携带转交地址的绑定更新消息进行签名来实现的。

o The application of CGA to Secure Neighbour Discovery [4]. In this case, the CGA features are used to prove the address ownership, so that it is possible to verify that the owner of the IP address is the one that is providing the layer 2 address information. This is achieved by signing the layer 2 address information with the private key of the CGA.

o CGA在安全邻居发现中的应用[4]。在这种情况下,CGA特征用于证明地址所有权,因此可以验证IP地址的所有者是提供第2层地址信息的所有者。这是通过使用CGA的私钥对第2层地址信息进行签名来实现的。

Essentially, all the current applications of CGAs rely on CGAs to protect a communication between two peers from third party attacks and not to provide protection from the peer itself. Attacks against the collision-free property of the hash functions suppose that one of the parties is generating two messages with the same hash value in order to launch an attack against its communicating peer. Since CGAs are not currently used to providing this type of protection, it is then natural that no additional attacks are enabled by a weaker collision resistance of the hash function.


4. Options for Multiple Hash Algorithm Support in CGAs
4. CGAs中支持多哈希算法的选项

CGAs, as currently defined in [2], are intrinsically bound to the SHA-1 hash algorithm and no other hash function is supported.


Even though the attacks against the collision-free property of the hash functions do not result in new vulnerabilities in the current applications of CGAs, it seems wise to enable multiple hash function support in CGAs. This is mainly for two reasons: first, potential future applications of the CGA technology may be susceptible to attacks against the collision-free property of SHA-1. Supporting alternative hash functions would allow applications that have stricter requirements on the collision-free property to use CGAs. Second, one lesson learned from the recent attacks against hash functions is that it is possible that one day we need to start using alternative hash functions because of successful attacks against other properties of the commonly used hash functions. Therefore, it seems wise to modify protocols in general and the CGAs in particular to support this transition to alternative hash functions as easy as possible.


4.1. Where to Encode the Hash Function?
4.1. 在哪里对哈希函数进行编码?

The next question we need to answer is where to encode the hash function that is being used. There are several options that can be considered:


One option would be to include the hash function used as an input to the hash function. This basically means to create an extension to the CGA Parameter Data Structure, as defined in [3], that codifies the hash function used. The problem is that this approach is vulnerable to bidding down attacks or downgrading attacks as defined in [10]. This means that even if a strong hash function is used, an attacker could find a CGA Parameter Data Structure that uses a weaker function but results in an equal hash value. This happens when the original hash function H1 and CGA Parameters Data Structure indicating H1 result in value X, and another hash function H2 and CGA Parameters Data Structure indicating H2 also result in the same value X.


In other words, the downgrading attack would work as follows: suppose that Alice generates a CGA CGA_A using the strong hash function HashStrong and using a CGA Parameter Data Structure CGA_PDS_A. The selected hash function HashStrong is encoded as an extension field in the CGA_PDS_A. Suppose that by using a brute force attack, an attacker X finds an alternative CGA Parameter Data Structure CGA_PDS_X whose hash value, by using a weaker hash function, is CGA_A. At this point, the attacker can pretend to be the owner of CGA_A and the stronger hash function has not provided additional protection.

换句话说,降级攻击的工作原理如下:假设Alice使用强哈希函数HashStrong和CGA参数数据结构CGA_PDS_a生成CGA CGA CGA_a。所选哈希函数HashStrong被编码为CGA_PDS_a中的扩展字段。假设通过使用暴力攻击,攻击者X通过使用较弱的散列函数找到另一个CGA参数数据结构CGA_PDS_X,其散列值为CGA_a。此时,攻击者可以假装是CGA_a的所有者,而较强的散列函数没有提供额外的保护。

The conclusion from the previous analysis is that the hash function used in the CGA generation must be encoded in the address itself.


Since we want to support several hash functions, we will likely need at least 2 or 3 bits for this.


One option would be to use more bits from the hash bits of the interface identifier. However, the problem with this approach is that the resulting CGA is weaker because less hash information is encoded in the address. In addition, since those bits are currently used as hash bits, it is impossible to make this approach backward compatible with existent implementations.


Another option would be to use the "u" and the "g" bits to encode this information, but this is probably not such a good idea since those bits have been honoured so far in all interface identifier generation mechanisms, which allow them to be used for the original purpose (for instance we can still create a global registry for unique interface identifiers). Finally, another option is to encode the hash value used in the Sec bits. The Sec bits are used to artificially introduce additional difficulty in the CGA generation process in order to provide additional protection against brute force attacks. The Sec bits have been designed in a way that the lifetime of CGAs are extended, when it is feasible to attack 59-bits long hash values. However, this is not the case today, so in general CGA will have a Sec value of 000. The proposal is to encode in the Sec bits, not only information about brute force attack protection but also to encode the hash function used to generate the hash. So for instance, the Sec value 000 would mean that the hash function used is SHA-1 and the 0 bits of hash2 (as defined in RFC 3972) must be 0. Sec value of 001 could be that the hash function used is SHA-1 and the 16 bits of hash2 (as defined in RFC 3972) must be zero. However, the other values of Sec could mean that an alternative hash function needs to be used and that a certain amount of bits of hash2 must be zero. The proposal is not to define any concrete hash function to be used for other Sec values, since it is not yet clear that we need to do so nor is it clear which hash function should be selected.

另一种选择是使用“u”和“g”位对该信息进行编码,但这可能不是一个好主意,因为到目前为止,所有接口标识符生成机制都采用了这些位,允许它们用于原始目的(例如,我们仍然可以为唯一的接口标识符创建一个全局注册表)最后,另一种选择是对Sec位中使用的哈希值进行编码。Sec位用于人为地在CGA生成过程中引入额外的困难,以提供额外的保护,防止暴力攻击。Sec位的设计方式是,在可行的情况下,延长CGA的寿命o攻击59位长的散列值。然而,今天的情况并非如此,因此通常CGA的秒值为000。建议使用秒位编码,不仅包括暴力攻击保护信息,还包括用于生成散列的散列函数的编码。例如,秒值000意味着散列函数使用的离子为SHA-1,哈希2的0位(如RFC 3972中所定义)必须为0。001的秒值可以是使用的哈希函数为SHA-1,哈希2的16位(如RFC 3972中所定义)必须为零。但是,Sec的其他值可能意味着需要使用替代哈希函数,并且哈希2的某些位必须为零。建议不定义任何用于其他Sec值的具体哈希函数,因为我们还不清楚是否需要这样做,也不清楚应该使用哪个哈希函数e被选中。

Note that since there are only 8 Sec values, it may be necessary to reuse Sec values when we run out of unused Sec values. The scenario where such an approach makes sense is where there are some Sec values that are no longer being used because the resulting security has become weak. In this case, where the usage of the Sec value has long been abandoned, it would be possible to reassign the Sec values. However, this must be a last resource option, since it may affect interoperability. This is because two implementations using different meanings of a given Sec value would not be able to interoperate properly (i.e., if an old implementation receives a CGA generated with the new meaning of the Sec value, it will fail and the same for a new implementation receiving a CGA generated with the old meaning of the Sec value). In case the approach of reassigning a Sec


value is followed, a long time is required between the deprecation of the old value and the reassignment in order to prevent misinterpretation of the value by old implementations.


An erroneous interpretation of a reused Sec value, both on the CGA owner's side and the CGA verifier's side, would have the following result, CGA verification would fail in the worst case and both nodes would have to revert to unprotected IPv6 addresses. This can happen only with obsolete CGA parameter sets, which would be considered insecure anyway. In any case, an implementation must not simultaneously support two different meanings of a Sec value.


5. CGA Generation Procedure
5. CGA生成程序

The SEC registry defined in the IANA considerations section of this document contains entries for the different Sec values. Each of these entries points to an RFC that defines the CGA generation procedure that MUST be used when generating CGAs with the associated Sec value.


It should be noted that the CGA generation procedure may be changed by the new procedure not only in terms of the hash function used but also in other aspects, e.g., longer Modifier values may be required if the number of 0s required in hash2 exceed the currently defined bound of 112 bits. The new procedure (which potentially involves a longer Modifier value) would be described in the RFC pointed to by the corresponding Sec registry entry.


In addition, the RFC that defines the CGA generation procedure for a Sec value MUST explicitly define the minimum key length acceptable for CGAs with that Sec value. This is to provide a coherent protection both in the hash and the public key techniques.


6. IANA Considerations
6. IANA考虑

This document defines a new registry entitled "CGA SEC" for the Sec field defined in RFC 3972 [2] that has been created and is maintained by IANA. The values in this name space are 3-bit unsigned integers.

本文件为RFC 3972[2]中定义的SEC字段定义了一个名为“CGA SEC”的新注册表,该字段由IANA创建并维护。此名称空间中的值是3位无符号整数。

Initial values for the CGA Extension Type field are given below; future assignments are to be made through Standards Action [5]. Assignments consist of a name, the value, and the RFC number where the CGA generation procedure is defined.


The following initial values are assigned in this document:


          Name        | Value |  RFCs
   SHA-1_0hash2bits   |   000 | 3972, 4982
   SHA-1_16hash2bits  |   001 | 3972, 4982
   SHA-1_32hash2bits  |   010 | 3972, 4982
          Name        | Value |  RFCs
   SHA-1_0hash2bits   |   000 | 3972, 4982
   SHA-1_16hash2bits  |   001 | 3972, 4982
   SHA-1_32hash2bits  |   010 | 3972, 4982
7. Security Considerations
7. 安全考虑

This document is about security issues and, in particular, about protection against potential attacks against hash functions.


8. Acknowledgements
8. 致谢

Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik Levkowetz reviewed and provided comments about this document.

Russ Housley、James Kempf、Christian Vogt、Pekka Nikander和Henrik Levkowetz对本文件进行了审查并提供了意见。

Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.

Marcelo Bagnulo在访问爱立信研究实验室Nomadiclab时编写了此文档。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[2] Aura,T.,“加密生成地址(CGA)”,RFC 39722005年3月。

[3] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.

[3] Bagnulo,M.和J.Arkko,“加密生成地址(CGA)扩展字段格式”,RFC 4581,2006年10月。

[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[4] Arkko,J.,Kempf,J.,Zill,B.,和P.Nikander,“安全邻居发现(SEND)”,RFC 39712005年3月。

9.2. Informative References
9.2. 资料性引用

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[5] Narten,T.和H.Alvestrand,“在RFCs中编写IANA注意事项部分的指南”,BCP 26,RFC 2434,1998年10月。

[6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.

[6] Hoffman,P.和B.Schneier,“对互联网协议中加密哈希的攻击”,RFC 42702005年11月。

[7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", Work in Progress, July 2005.

[7] Nordmark,E.和M.Bagnulo,“多归宿L3垫片法”,正在进行的工作,2005年7月。

[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[8] Johnson,D.,Perkins,C.,和J.Arkko,“IPv6中的移动支持”,RFC 37752004年6月。

[9] Arkko, J., "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6", Work in Progress, June 2006.

[9] Arkko,J.“将加密生成的地址和基于信用的授权应用于移动IPv6”,正在进行的工作,2006年6月。

[10] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.

[10] Bellovin,S.和E.Rescorla,“部署新的哈希算法”,NDSS'06,2006年2月。

Authors' Addresses


Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN


   Phone: 34 91 6249500
   Phone: 34 91 6249500

Jari Arkko Ericsson Jorvas 02420 Finland



Full Copyright Statement


Copyright (C) The IETF Trust (2007).


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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an 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


The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at




Funding for the RFC Editor function is currently provided by the Internet Society.