From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4982.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4982.txt (limited to 'doc/rfc/rfc4982.txt') diff --git a/doc/rfc/rfc4982.txt b/doc/rfc/rfc4982.txt new file mode 100644 index 0000000..f1c3aa2 --- /dev/null +++ b/doc/rfc/rfc4982.txt @@ -0,0 +1,507 @@ + + + + + + +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. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + 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 + + + + + + + + +Bagnulo & Arkko Standards Track [Page 1] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + +1. Introduction + + 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 + + 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]. + +3. Impact of Collision Attacks in 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. + + + + +Bagnulo & Arkko Standards Track [Page 2] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + 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 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 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. + + 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 + + CGAs, as currently defined in [2], are intrinsically bound to the + SHA-1 hash algorithm and no other hash function is supported. + + + + +Bagnulo & Arkko Standards Track [Page 3] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + 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? + + 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. + + The conclusion from the previous analysis is that the hash function + used in the CGA generation must be encoded in the address itself. + + + +Bagnulo & Arkko Standards Track [Page 4] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + 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. + + 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 + + + +Bagnulo & Arkko Standards Track [Page 5] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + 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 + + 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 + + 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. + + 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. + + + + + + + + +Bagnulo & Arkko Standards Track [Page 6] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + 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 + +7. Security Considerations + + This document is about security issues and, in particular, about + protection against potential attacks against hash functions. + +8. Acknowledgements + + Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik + Levkowetz reviewed and provided comments about this document. + + Marcelo Bagnulo worked on this document while visiting Ericsson + Research Laboratory Nomadiclab. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [3] Bagnulo, M. and J. Arkko, "Cryptographically Generated + Addresses (CGA) Extension Field Format", RFC 4581, + October 2006. + + [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + +9.2. Informative References + + [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes + in Internet Protocols", RFC 4270, November 2005. + + + + + +Bagnulo & Arkko Standards Track [Page 7] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + + [7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", + Work in Progress, July 2005. + + [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in + IPv6", RFC 3775, June 2004. + + [9] Arkko, J., "Applying Cryptographically Generated Addresses and + Credit-Based Authorization to Mobile IPv6", Work in Progress, + June 2006. + + [10] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", + NDSS '06, February 2006. + +Authors' Addresses + + Marcelo Bagnulo + Universidad Carlos III de Madrid + Av. Universidad 30 + Leganes, Madrid 28911 + SPAIN + + Phone: 34 91 6249500 + EMail: marcelo@it.uc3m.es + URI: http://www.it.uc3m.es + + + Jari Arkko + Ericsson + Jorvas 02420 + Finland + + EMail: jari.arkko@ericsson.com + + + + + + + + + + + + + + + + + + + +Bagnulo & Arkko Standards Track [Page 8] + +RFC 4982 Multiple Hash Support in CGAs July 2007 + + +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. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + 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 + http://www.ietf.org/ipr. + + 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 + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Bagnulo & Arkko Standards Track [Page 9] + -- cgit v1.2.3