idnits 2.17.1 draft-laganier-ipv6-khi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '...erefore, routers SHOULD NOT forward an...' RFC 2119 keyword, line 153: '...y Prohibited message MAY be generated....' RFC 2119 keyword, line 192: '... of collisions, it is RECOMMENDED that...' RFC 2119 keyword, line 243: '...anism using KHIs MUST use exactly the ...' RFC 2119 keyword, line 255: '...ter needed, they MUST use a different ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2, 2005) is 6783 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.dupont-mip6-privacyext' is defined on line 320, but no explicit reference was found in the text == Unused Reference: 'RFC3587' is defined on line 336, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-04) exists of draft-dupont-mip6-privacyext-02 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-03 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft Ericsson Research Nomadic Lab 4 Expires: March 6, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 F. Dupont 7 Point6 8 September 2, 2005 10 A Non-Routable IPv6 Prefix for Keyed Hash Identifiers (KHI) 11 draft-laganier-ipv6-khi-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 This document may not be modified, and derivative works of it may not 20 be created, except to publish it as an RFC and to translate it into 21 languages other than English. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 6, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document introduces Keyed Hash Identifiers (KHI) as a new, 48 experimental class of IPv6-address-lookalike identifiers. They are 49 constructed to be statistically globally unique. They are intended 50 to be used as identifiers only, and not as locators. They should not 51 appear in actual IPv6 headers. Consequently, they are considered as 52 non-routable addresses from the IPv6 point of view. 54 These identifiers are expected to be used at the existing IPv6 API 55 and application protocols between consenting hosts. They may be 56 defined and used in different contexts, suitable for different 57 protocols. Examples of these include Host Identity Tags (HIT) in the 58 Host Identity Protocol (HIP) and Temporary Mobile Identifiers (TMI) 59 for Mobile IPv6 Privacy Extension. 61 This document requests IANA to allocate a temporary prefix out of the 62 IPv6 addressing space for Keyed Hash Identifiers. 64 1. Introduction 66 This document introduces Keyed Hash Identifiers (KHI), a new class of 67 IPv6-address-lookalike identifiers. They are intended to be 68 statistically unique and non-routable at the IP layer. The 69 identifiers are designed to be securely bound to a bitstring used as 70 input to a secure hash function, keyed with a context identifier. 71 Typically, but not necessarily, the input bitstring will include a 72 suitably encoded public cryptographic key. 74 These identifiers have the following properties: 75 o Statistically unique (i.e. high probability uniqueness.) 76 o Securely bound to the input parameters used for their generation 77 (i.e., the context identifier and a bitstring.) 78 o Conforming with the IPv6 global unicast address format defined in 79 Section 2.5.4 of [RFC3513]. 80 o Aggregated under the TBD IPv6 prefix. 81 o Non-routable as IPv6 addresses, due to their structure and 82 identifier-only nature. 84 As mentioned above, KHIs are intended to be generated and used in 85 different contexts, as suitable for different mechanisms and 86 protocols. The context identifier is meant to be used to 87 differentiate between the different contexts; see Section 4 for a 88 discussion of the related API and kernel level implementation issues, 89 and Section 5 for the design choices behind it. 91 Examples of identifiers and protocols that are expected to adopt the 92 KHI format include Host Identity Tags (HIT) in the Host Identity 93 Protocol [I-D.ietf-hip-base] and the Temporary Mobile Identifiers 94 (TMI) in the Simple Privacy Extension for Mobile IPv6 [I-D.dupont- 95 mip6-privacyext]. The format is designed to be extensible to allow 96 other experimental proposals to share the same name space. 98 This document requests IANA to allocate a temporary prefix out of the 99 IPv6 addressing space for Keyed Hash Identifiers. By default, the 100 prefix will be returned to IANA in January 1st 2009, continued use 101 requiring IETF consensus. 103 2. Keyed Hash Identifier Construction 105 A KHI is generated using the algorithm below, which takes as input a 106 bitstring and a context identifier: 108 Input := any bitstring 109 Hash Input := Context ID | Input 110 Hash := SHA1( Expand( Hash Input ) ) 111 KHI := Prefix | Encode_n( Hash ) 113 where: 115 | : Denotes concatenation of bitstrings 117 Input : A bitstring unique or statistically unique within a 118 given context intended to be associated with the 119 to-be-created KHI in the given context. 121 Context ID : A randomly generated value defining the expected usage 122 context the the particular KHI. 124 As a baseline (TO BE DISCUSSED), we propose sharing the 125 name space introduced for CGA Type Tags; see 126 http://www.iana.org/assignments/cga-message-types 127 and RFC 3972. 129 Expand( ) : An expansion function designed to overcome recent 130 attacks on SHA1. 132 As a baseline (TO BE DISCUSSED), we propose inserting 133 four (4) zero (0) bytes after every twelve (12) bytes 134 of the argument bitstring. 136 Encode_n( ): An extraction function which output is obtained by 137 extracting an -bits-long bitstring from the argument 138 bitstring. 140 As a baseline (TO BE DISCUSSED), we propose taking 141 middlemost bits from the SHA1 output. 143 Prefix : A constant ( 128 - ) bits long bitstring value, 144 TBD, assigned by IANA. 146 3. Routing Considerations 148 Keyed Hash Identifiers are designed to serve as identifiers rather 149 than locators. Therefore, routers SHOULD NOT forward any packets 150 containing a KHI as a source or a destination address. If the 151 destination address is a KHI but the source address is a valid 152 unicast source address, an ICMP Destination Unreachable, 153 Administratively Prohibited message MAY be generated. 155 Note that while KHIs are designed to be non-routable at the IP layer, 156 there are ongoing research efforts for creating overlay routing for 157 these kinds of identifiers. For example, the Host Identity 158 Indirection Infrastructure (Hi3) proposal outlines a way for using a 159 Distributed Hash Table to forward HIP packets based on the Host 160 Identity Tag. 162 4. Collision Considerations 164 As noted above, KHIs are expected to be used at the legacy IPv6 APIs 165 between consenting hosts. The context ID is intended to 166 differentiate between the various mechanisms, or contexts, sharing 167 the same name space. However, that context ID not being present in 168 the KHI itself, but only in front of the input bitstring as an input 169 to the hash function, might lead to certain implementation-related 170 complications. 172 Because KHIs are not routable, in order to send packets using KHIs at 173 the API level, the sending host must have additional state within the 174 stack in order to determine parameters (e.g. what locators) to use in 175 the outgoing packet. An underlying assumption here, and a matter of 176 fact in the proposals that the authors are aware of, is that there is 177 a protocol for setting up and maintaining the additional state. It 178 is assumed that the state-set-up protocol carries the input 179 bitstring, and that the resulting KHI-related state in the stack can 180 be associated back with the appropriate context and state-set-up 181 protocol. 183 Even though KHI collisions are expected to be extremely rare, two 184 kinds of collisions may happen. Firstly, it is possible that two 185 different input bitstrings within the same context may map to the 186 same KHI. In that case, the state-set-up might be able to resolve 187 the conflict. 189 A second type of collision may happen if two different input 190 bitstrings, used in different usage contexts, map to the same KHI. 191 In this case the main confusion is about which context to use. In 192 order to prevent these types of collisions, it is RECOMMENDED that 193 implementations that simultaneously support multiple different 194 contexts maintain a host-wide unified database of known KHIs, and 195 indicate a conflict if any of the mechanisms attempt to register a 196 KHI that is already in use. For example, if a given KHI is already 197 being used as a HIT in HIP, it cannot be simultaneously used as a TMI 198 in Mobile IP. Instead, if Mobile IP attempts to use the KHI, it will 199 be notified (by the kernel) that the KHI in question is already in 200 use. 202 5. Design Choices 204 The design of this name space faces two competing forces: 205 As many bits as possible should be preserved for the hash result. 206 It should be possible to share the name space between multiple 207 mechanisms. 209 The desire to have a long hash result requires the prefix to be as 210 short as possible, and to use few (if any) bits for additional 211 encoding. The present design takes this desire to the maxim: all the 212 bits beyond the prefix are used as hash output. This leaves no bits 213 in the KHI itself available for separating the context. 214 Additionally, due to security considerations, the present design 215 REQUIRES that the hash function used in constructing KHIs is 216 constant; see Section 6. 218 The authors explicitly considered including a hash extension 219 mechanism, similar to the one in CGA [RFC3972], but decided to leave 220 it out. There were two reasons: desire for simplicity, and the 221 somewhat unclear IPR situation around the hash extension mechanism. 222 If there is a future revision of this document, we strongly advice 223 the future authors to reconsider the situation. 225 The desire to allow multiple mechanism to share the name space has 226 been resolved by including the context identifier in the hash 227 function input. While this does not allow the mechanism to be 228 directly inferred from a KHI, it allows one to verify that a given 229 input bitstring and KHI belong to a given context, with high 230 probability; but see also Section 6. 232 6. Security Considerations 234 Keyed Hash Identifiers are designed to be securely bound to the 235 context identifier and the bitstring used as the input parameters 236 during their generation. To provide this property, the KHI 237 generation algorithm relies on the second-preimage resistance (a.k.a. 238 one-way) property of the hash function used in the generation 239 [I-D.hoffman-hash-attacks]. To have this property, and to avoid 240 collisions, it is important that the allocated prefix is as short as 241 possible, leaving as many bits as possible for the hash output. 243 All mechanism using KHIs MUST use exactly the same mechanism for 244 generating a KHI from the input bitstring. Allowing different 245 mechanisms, without explicitly encoding the mechanism in the KHI 246 itself, would allow so called bidding down attacks. That is, if 247 multiple different hash functions were allowed in constructing KHIs 248 in a given shared name space, and if one of the hash functions became 249 insecure, that would allow attacks against even those KHIs that had 250 been constructed using with the other, still secure hash functions. 252 Due to the desire to keep the hash output value as long as possible, 253 the present design allows only one method for constructing KHIs from 254 input bitstrings. If other methods (perhaps using more secure hash 255 functions) are later needed, they MUST use a different prefix. 256 Consequently, the suggested method to react to the hash result 257 becoming too short due to increased computational power or the used 258 hash function becoming insecure due to advances in cryptology is to 259 allocate a new prefix and cease to use the present one. 261 As of today, SHA1 applied in conjunction with a proper expansion 262 function of the hash input is considered as satisfying the second- 263 preimage resistance requirement [I-D.hoffman-hash-attacks]. Hash 264 output of at least 100 bits, but preferably up to 120 bits, is 265 considered to have a low enough probability of collisions. 267 In order to preserve low enough probability of collisions (see 268 Section 4), each method MUST utilize a mechanism that makes sure that 269 the distinct input bitstrings are either unique or statistically 270 unique, within that context. There are several possible methods to 271 ensure that; for example, one can include into the input bitstring a 272 globally maintained counter value, a pseudo- random number of 273 sufficient entropy (minimum 120 bits), or a randomly generated public 274 cryptographic key. The Context ID makes sure that input bitstrings 275 from different contexts never overlap. These together make sure that 276 the probability of collisions is determined only by the probability 277 of natural collisions in the hash space and not increased by a 278 possibility of colliding input bit strings. 280 7. IANA Considerations 282 IANA is requested to allocate a temporary non-routable prefix from 283 the IPv6 address space, to be defaulted back to "Reserved by IETF" by 284 January 1st 2009. As per Sections 2.5.1 and 2.5.4 of [RFC3513], the 285 prefix must be allocated from the 0000::/3 block, since KHIs do not 286 have a 64-bit interface identifier part. The allocation will require 287 updating http://www.iana.org/assignments/ipv6-address-space 289 As a baseline (TO BE DISCUSSED), we propose an 8-bit prefix to be 290 allocated from the 1000::/4 block. 292 The Context Identifier (or Context ID) is a randomly generated value 293 defining the usage context of a KHI. This document defines no 294 specific value. 296 As a baseline (TO BE DISCUSSED), we propose sharing the name space 297 introduced for CGA Type Tags. Hence, defining new values would 298 follow the rules of Section 8 of [RFC3972], i.e., on a First Come 299 First Served basis. The policy will require updating the policy for 300 http://www.iana.org/assignments/cga-message-types 302 8. Acknowledgments 304 Julien Laganier is partly funded by Ambient Networks, a research 305 project supported by the European Commission under its Sixth 306 Framework Program. 308 9. References 310 9.1 Normative references 312 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 313 (IPv6) Addressing Architecture", RFC 3513, April 2003. 315 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 316 RFC 3972, March 2005. 318 9.2 Informative references 320 [I-D.dupont-mip6-privacyext] 321 Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple 322 Privacy Extension for Mobile IPv6", 323 draft-dupont-mip6-privacyext-02 (work in progress), 324 July 2005. 326 [I-D.hoffman-hash-attacks] 327 Hoffman, P. and B. Schneier, "Attacks on Cryptographic 328 Hashes in Internet Protocols", 329 draft-hoffman-hash-attacks-04 (work in progress), 330 June 2005. 332 [I-D.ietf-hip-base] 333 Moskowitz, R., "Host Identity Protocol", 334 draft-ietf-hip-base-03 (work in progress), June 2005. 336 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 337 Unicast Address Format", RFC 3587, August 2003. 339 Authors' Addresses 341 Pekka Nikander 342 Ericsson Research Nomadic Lab 343 JORVAS FI-02420 344 FINLAND 346 Phone: +358 9 299 1 347 Email: pekka.nikander@nomadiclab.com 349 Julien Laganier 350 DoCoMo Communications Laboratories Europe GmbH 351 Landsberger Strasse 312 352 Munich 80687 353 Germany 355 Phone: +49 89 56824 231 356 Email: julien.ietf@laposte.net 357 URI: http://www.docomolab-euro.com/ 359 Francis Dupont 360 Point6 361 c/o GET/ENST Bretagne 362 2 rue de la Chataigneraie 363 CS 17607 364 35576 Cesson-Sevigne Cedex 365 France 367 Fax: +33 2 99 12 70 30 368 Email: Francis.Dupont@enst-bretagne.fr 370 Intellectual Property Statement 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Disclaimer of Validity 396 This document and the information contained herein are provided on an 397 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 398 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 399 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 400 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 401 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 402 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 404 Copyright Statement 406 Copyright (C) The Internet Society (2005). This document is subject 407 to the rights, licenses and restrictions contained in BCP 78, and 408 except as set forth therein, the authors retain all their rights. 410 Acknowledgment 412 Funding for the RFC Editor function is currently provided by the 413 Internet Society.