Network Working Group P. Nikander Internet-Draft Ericsson Research Nomadic Lab Expires: March 6, 2006 J. Laganier DoCoMo Euro-Labs F. Dupont Point6 September 2, 2005 A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI) draft-laganier-ipv6-khi-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document introduces Keyed Hash Identifiers (KHI) as a new, experimental class of IPv6-address-lookalike identifiers. They are Nikander, et al. Expires March 6, 2006 [Page 1] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 constructed to be statistically globally unique. They are intended to be used as identifiers only, and not as locators. They should not appear in actual IPv6 headers. Consequently, they are considered as non-routable addresses from the IPv6 point of view. These identifiers are expected to be used at the existing IPv6 API and application protocols between consenting hosts. They may be defined and used in different contexts, suitable for different protocols. Examples of these include Host Identity Tags (HIT) in the Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Keyed Hash Identifiers. 1. Introduction This document introduces Keyed Hash Identifiers (KHI), a new class of IPv6-address-lookalike identifiers. They are intended to be statistically unique and non-routable at the IP layer. The identifiers are designed to be securely bound to a bitstring used as input to a secure hash function, keyed with a context identifier. Typically, but not necessarily, the input bitstring will include a suitably encoded public cryptographic key. These identifiers have the following properties: o Statistically unique (i.e. high probability uniqueness.) o Securely bound to the input parameters used for their generation (i.e., the context identifier and a bitstring.) o Conforming with the IPv6 global unicast address format defined in Section 2.5.4 of [RFC3513]. o Aggregated under the TBD IPv6 prefix. o Non-routable as IPv6 addresses, due to their structure and identifier-only nature. As mentioned above, KHIs are intended to be generated and used in different contexts, as suitable for different mechanisms and protocols. The context identifier is meant to be used to differentiate between the different contexts; see Section 4 for a discussion of the related API and kernel level implementation issues, and Section 5 for the design choices behind it. Examples of identifiers and protocols that are expected to adopt the KHI format include Host Identity Tags (HIT) in the Host Identity Protocol [I-D.ietf-hip-base] and the Temporary Mobile Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 [I-D.dupont- mip6-privacyext]. The format is designed to be extensible to allow other experimental proposals to share the same name space. Nikander, et al. Expires March 6, 2006 [Page 2] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Keyed Hash Identifiers. By default, the prefix will be returned to IANA in January 1st 2009, continued use requiring IETF consensus. 2. Keyed Hash Identifier Construction A KHI is generated using the algorithm below, which takes as input a bitstring and a context identifier: Input := any bitstring Hash Input := Context ID | Input Hash := SHA1( Expand( Hash Input ) ) KHI := Prefix | Encode_n( Hash ) where: | : Denotes concatenation of bitstrings Input : A bitstring unique or statistically unique within a given context intended to be associated with the to-be-created KHI in the given context. Context ID : A randomly generated value defining the expected usage context the the particular KHI. As a baseline (TO BE DISCUSSED), we propose sharing the name space introduced for CGA Type Tags; see http://www.iana.org/assignments/cga-message-types and RFC 3972. Expand( ) : An expansion function designed to overcome recent attacks on SHA1. As a baseline (TO BE DISCUSSED), we propose inserting four (4) zero (0) bytes after every twelve (12) bytes of the argument bitstring. Encode_n( ): An extraction function which output is obtained by extracting an -bits-long bitstring from the argument bitstring. As a baseline (TO BE DISCUSSED), we propose taking middlemost bits from the SHA1 output. Prefix : A constant ( 128 - ) bits long bitstring value, TBD, assigned by IANA. Nikander, et al. Expires March 6, 2006 [Page 3] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 3. Routing Considerations Keyed Hash Identifiers are designed to serve as identifiers rather than locators. Therefore, routers SHOULD NOT forward any packets containing a KHI as a source or a destination address. If the destination address is a KHI but the source address is a valid unicast source address, an ICMP Destination Unreachable, Administratively Prohibited message MAY be generated. Note that while KHIs are designed to be non-routable at the IP layer, there are ongoing research efforts for creating overlay routing for these kinds of identifiers. For example, the Host Identity Indirection Infrastructure (Hi3) proposal outlines a way for using a Distributed Hash Table to forward HIP packets based on the Host Identity Tag. 4. Collision Considerations As noted above, KHIs are expected to be used at the legacy IPv6 APIs between consenting hosts. The context ID is intended to differentiate between the various mechanisms, or contexts, sharing the same name space. However, that context ID not being present in the KHI itself, but only in front of the input bitstring as an input to the hash function, might lead to certain implementation-related complications. Because KHIs are not routable, in order to send packets using KHIs at the API level, the sending host must have additional state within the stack in order to determine parameters (e.g. what locators) to use in the outgoing packet. An underlying assumption here, and a matter of fact in the proposals that the authors are aware of, is that there is a protocol for setting up and maintaining the additional state. It is assumed that the state-set-up protocol carries the input bitstring, and that the resulting KHI-related state in the stack can be associated back with the appropriate context and state-set-up protocol. Even though KHI collisions are expected to be extremely rare, two kinds of collisions may happen. Firstly, it is possible that two different input bitstrings within the same context may map to the same KHI. In that case, the state-set-up might be able to resolve the conflict. A second type of collision may happen if two different input bitstrings, used in different usage contexts, map to the same KHI. In this case the main confusion is about which context to use. In order to prevent these types of collisions, it is RECOMMENDED that implementations that simultaneously support multiple different Nikander, et al. Expires March 6, 2006 [Page 4] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 contexts maintain a host-wide unified database of known KHIs, and indicate a conflict if any of the mechanisms attempt to register a KHI that is already in use. For example, if a given KHI is already being used as a HIT in HIP, it cannot be simultaneously used as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the KHI, it will be notified (by the kernel) that the KHI in question is already in use. 5. Design Choices The design of this name space faces two competing forces: As many bits as possible should be preserved for the hash result. It should be possible to share the name space between multiple mechanisms. The desire to have a long hash result requires the prefix to be as short as possible, and to use few (if any) bits for additional encoding. The present design takes this desire to the maxim: all the bits beyond the prefix are used as hash output. This leaves no bits in the KHI itself available for separating the context. Additionally, due to security considerations, the present design REQUIRES that the hash function used in constructing KHIs is constant; see Section 6. The authors explicitly considered including a hash extension mechanism, similar to the one in CGA [RFC3972], but decided to leave it out. There were two reasons: desire for simplicity, and the somewhat unclear IPR situation around the hash extension mechanism. If there is a future revision of this document, we strongly advice the future authors to reconsider the situation. The desire to allow multiple mechanism to share the name space has been resolved by including the context identifier in the hash function input. While this does not allow the mechanism to be directly inferred from a KHI, it allows one to verify that a given input bitstring and KHI belong to a given context, with high probability; but see also Section 6. 6. Security Considerations Keyed Hash Identifiers are designed to be securely bound to the context identifier and the bitstring used as the input parameters during their generation. To provide this property, the KHI generation algorithm relies on the second-preimage resistance (a.k.a. one-way) property of the hash function used in the generation [I-D.hoffman-hash-attacks]. To have this property, and to avoid collisions, it is important that the allocated prefix is as short as possible, leaving as many bits as possible for the hash output. Nikander, et al. Expires March 6, 2006 [Page 5] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 All mechanism using KHIs MUST use exactly the same mechanism for generating a KHI from the input bitstring. Allowing different mechanisms, without explicitly encoding the mechanism in the KHI itself, would allow so called bidding down attacks. That is, if multiple different hash functions were allowed in constructing KHIs in a given shared name space, and if one of the hash functions became insecure, that would allow attacks against even those KHIs that had been constructed using with the other, still secure hash functions. Due to the desire to keep the hash output value as long as possible, the present design allows only one method for constructing KHIs from input bitstrings. If other methods (perhaps using more secure hash functions) are later needed, they MUST use a different prefix. Consequently, the suggested method to react to the hash result becoming too short due to increased computational power or the used hash function becoming insecure due to advances in cryptology is to allocate a new prefix and cease to use the present one. As of today, SHA1 applied in conjunction with a proper expansion function of the hash input is considered as satisfying the second- preimage resistance requirement [I-D.hoffman-hash-attacks]. Hash output of at least 100 bits, but preferably up to 120 bits, is considered to have a low enough probability of collisions. In order to preserve low enough probability of collisions (see Section 4), each method MUST utilize a mechanism that makes sure that the distinct input bitstrings are either unique or statistically unique, within that context. There are several possible methods to ensure that; for example, one can include into the input bitstring a globally maintained counter value, a pseudo- random number of sufficient entropy (minimum 120 bits), or a randomly generated public cryptographic key. The Context ID makes sure that input bitstrings from different contexts never overlap. These together make sure that the probability of collisions is determined only by the probability of natural collisions in the hash space and not increased by a possibility of colliding input bit strings. 7. IANA Considerations IANA is requested to allocate a temporary non-routable prefix from the IPv6 address space, to be defaulted back to "Reserved by IETF" by January 1st 2009. As per Sections 2.5.1 and 2.5.4 of [RFC3513], the prefix must be allocated from the 0000::/3 block, since KHIs do not have a 64-bit interface identifier part. The allocation will require updating http://www.iana.org/assignments/ipv6-address-space As a baseline (TO BE DISCUSSED), we propose an 8-bit prefix to be allocated from the 1000::/4 block. Nikander, et al. Expires March 6, 2006 [Page 6] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 The Context Identifier (or Context ID) is a randomly generated value defining the usage context of a KHI. This document defines no specific value. As a baseline (TO BE DISCUSSED), we propose sharing the name space introduced for CGA Type Tags. Hence, defining new values would follow the rules of Section 8 of [RFC3972], i.e., on a First Come First Served basis. The policy will require updating the policy for http://www.iana.org/assignments/cga-message-types 8. Acknowledgments Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. 9. References 9.1 Normative references [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 9.2 Informative references [I-D.dupont-mip6-privacyext] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension for Mobile IPv6", draft-dupont-mip6-privacyext-02 (work in progress), July 2005. [I-D.hoffman-hash-attacks] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", draft-hoffman-hash-attacks-04 (work in progress), June 2005. [I-D.ietf-hip-base] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-03 (work in progress), June 2005. [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003. Nikander, et al. Expires March 6, 2006 [Page 7] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 Authors' Addresses Pekka Nikander Ericsson Research Nomadic Lab JORVAS FI-02420 FINLAND Phone: +358 9 299 1 Email: pekka.nikander@nomadiclab.com Julien Laganier DoCoMo Communications Laboratories Europe GmbH Landsberger Strasse 312 Munich 80687 Germany Phone: +49 89 56824 231 Email: julien.ietf@laposte.net URI: http://www.docomolab-euro.com/ Francis Dupont Point6 c/o GET/ENST Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Fax: +33 2 99 12 70 30 Email: Francis.Dupont@enst-bretagne.fr Nikander, et al. Expires March 6, 2006 [Page 8] Internet-Draft Keyed Hash Identifiers (KHI) September 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Nikander, et al. Expires March 6, 2006 [Page 9]