idnits 2.17.1 draft-ietf-hip-rfc4843-bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 11, 2013) is 3761 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) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc5201-bis-14 -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Luminate Wireless, Inc. 4 Obsoletes: 4843 (if approved) F. Dupont 5 Intended status: Standards Track Internet Systems Consortium 6 Expires: June 14, 2014 December 11, 2013 8 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 9 Version 2 (ORCHIDv2) 10 draft-ietf-hip-rfc4843-bis-05 12 Abstract 14 This document specifies an updated Overlay Routable Cryptographic 15 Hash Identifiers format that obsoletes RFC4843. These identifiers 16 are intended to be used as endpoint identifiers at applications and 17 Application Programming Interfaces (API) and not as identifiers for 18 network location at the IP layer, i.e., locators. They are designed 19 to appear as application layer entities and at the existing IPv6 20 APIs, but they should not appear in actual IPv6 headers. To make 21 them more like regular IPv6 addresses, they are expected to be 22 routable at an overlay level. Consequently, while they are 23 considered non-routable addresses from the IPv6 layer point-of-view, 24 all existing IPv6 applications are expected to be able to use them in 25 a manner compatible with current IPv6 addresses. 27 The Overlay Routable Cryptographic Hash Identifiers originally 28 defined in RFC4843 lacked a mechanism for cryptographic algorithm 29 agility. The updated ORCHID format specified in this document 30 removes this limitation by encoding in the identifier itself an index 31 to the suite of cryptographic algorithms in use. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 14, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3 69 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 71 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Cryptographic Hash Identifier Construction . . . . . . . . . 5 74 3. Routing and Forwarding Considerations . . . . . . . . . . . . 7 75 4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 9.1. Normative references . . . . . . . . . . . . . . . . . . 10 82 9.2. Informative references . . . . . . . . . . . . . . . . . 10 83 Appendix A. Collision Considerations . . . . . . . . . . . . . . 11 84 Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 11 86 1. Introduction 88 This document introduces Overlay Routable Cryptographic Hash 89 Identifiers (ORCHID), a new class of IP address-like identifiers. 90 These identifiers are intended to be globally unique in a statistical 91 sense (see Appendix A), non-routable at the IP layer, and routable at 92 some overlay layer. The identifiers are securely bound, via a secure 93 hash function, to the concatenation of an input bitstring and a 94 context tag. Typically, but not necessarily, the input bitstring 95 will include a suitably encoded public cryptographic key. 97 1.1. Rationale and Intent 99 These identifiers are expected to be used at the existing IPv6 100 Application Programming Interfaces (API) and application protocols 101 between consenting hosts. They may be defined and used in different 102 contexts, suitable for different overlay protocols. Examples of 103 these include Host Identity Tags (HIT) in the Host Identity Protocol 104 (HIP) [I-D.ietf-hip-rfc5201-bis] and Temporary Mobile Identifiers 105 (TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT]. 107 As these identifiers are expected to be used along with IPv6 108 addresses at both applications and APIs, co-ordination is desired to 109 make sure that an ORCHID is not inappropriately taken for a regular 110 IPv6 address and vice versa. In practice, allocation of a separate 111 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 112 addresses at the upper layers while simultaneously making it trivial 113 to prevent their usage at the IP layer. 115 While being technically possible to use ORCHIDs between consenting 116 hosts without any co-ordination with the IETF and the IANA, the 117 authors would consider such practice potentially dangerous. A 118 specific danger would be realised if the IETF community later decided 119 to use the ORCHID prefix for some different purpose. In that case, 120 hosts using the ORCHID prefix would be, for practical purposes, 121 unable to use the prefix for the other new purpose. That would lead 122 to partial balkanisation of the Internet, similar to what has 123 happened as a result of historical hijackings of non-RFC 1918 124 [RFC1918] IPv4 addresses for private use. 126 The whole need for the proposed allocation grows from the desire to 127 be able to use ORCHIDs with existing applications and APIs. This 128 desire leads to the potential conflict, mentioned above. Resolving 129 the conflict requires the proposed allocation. 131 One can argue that the desire to use these kinds of identifiers via 132 existing APIs is architecturally wrong, and there is some truth in 133 that argument. Indeed, it would be more desirable to introduce a new 134 API and update all applications to use identifiers, rather than 135 locators, via that new API. That is exactly what we expect to happen 136 in the long run. 138 However, given the current state of the Internet, we do not consider 139 it viable to introduce any changes that, at once, require 140 applications to be rewritten and host stacks to be updated. Rather 141 than that, we believe in piece-wise architectural changes that 142 require only one of the existing assets to be touched. ORCHIDs are 143 designed to address this situation: to allow people to experiment 144 with protocol stack extensions, such as secure overlay routing, HIP, 145 or Mobile IP privacy extensions, without requiring them to update 146 their applications. The goal is to facilitate large-scale 147 experiments with minimum user effort. 149 For example, there already exists, at the time of this writing, HIP 150 implementations that run fully in user space, using the operating 151 system to divert a certain part of the IPv6 address space to a user 152 level daemon for HIP processing. In practical terms, these 153 implementations are already using a certain IPv6 prefix for 154 differentiating HIP identifiers from IPv6 addresses, allowing them 155 both to be used by the existing applications via the existing APIs. 157 The Overlay Routable Cryptographic Hash Identifiers originally 158 defined in [RFC4843] lacked a mechanism for cryptographic algorithm 159 agility. The updated ORCHID format specified in this document 160 removes this limitation by encoding in the identifier itself an index 161 to the suite of cryptographic algorithms in use. 163 Because the updated ORCHIDv2 format is not backward compatible with 164 the earlier one, IANA is requested to allocate a new 28-bit prefix 165 out of the IANA IPv6 Special Purpose Address Block, namely 166 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily 167 allocated for the experimental ORCHID is to be returned to IANA in 168 2014 [RFC4843]. 170 1.2. ORCHID Properties 172 ORCHIDs are designed to have the following properties: 174 o Statistical uniqueness; also see Appendix A 176 o Secure binding to the input parameters used in their generation 177 (i.e., the context identifier and a bitstring). 179 o Aggregation under a single IPv6 prefix. Note that this is only 180 needed due to the co-ordination need as indicated above. Without 181 such co-ordination need, the ORCHID namespace could potentially be 182 completely flat. 184 o Non-routability at the IP layer, by design. 186 o Routability at some overlay layer, making them, from an 187 application point of view, semantically similar to IPv6 addresses. 189 As mentioned above, ORCHIDs are intended to be generated and used in 190 different contexts, as suitable for different mechanisms and 191 protocols. The context identifier is meant to be used to 192 differentiate between the different contexts; see Appendix A for a 193 discussion of the related API and kernel level implementation issues, 194 and Section 4 for the design choices explaining why the context 195 identifiers are used. 197 1.3. Expected use of ORCHIDs 199 Examples of identifiers and protocols that are expected to adopt the 200 ORCHID format include Host Identity Tags (HIT) in the Host Identity 201 Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile 202 Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 203 [PRIVACYTEXT]. The format is designed to be extensible to allow 204 other experimental proposals to share the same namespace. 206 1.4. Action Plan 208 This document requests IANA to allocate a prefix out of the IPv6 209 addressing space for Overlay Routable Cryptographic Hash Identifiers. 211 1.5. Terminology 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 215 document are to be interpreted as described in [RFC2119]. 217 2. Cryptographic Hash Identifier Construction 219 An ORCHID is generated using the ORCHID Generation Algorithm (OGA) 220 below. The algorithm takes a bitstring and a context identifier as 221 input and produces an ORCHID as output. The hash function used in 222 the ORCHID Generation Algorithm is defined for each OGA identifier by 223 the specification for the respective usage context (e.g., HIPv2). 225 Input := any bitstring 226 OGA ID := 4-bits Orchid Generation Algorithm identifier 227 Hash Input := Context ID | Input 228 Hash := Hash_function( Hash Input ) 229 ORCHID := Prefix | Encode_96( Hash ) 231 where: 233 | : Denotes concatenation of bitstrings 235 Input : A bitstring that is unique or statistically unique 236 within a given context. The bitstring is intended 237 to be associated with the to-be-created ORCHID in 238 the given context. 240 Context ID : A randomly generated value defining the expected 241 usage context for the particular ORCHID and the 242 hash function to be used for generation of ORCHIDs 243 in this context. These values are allocated out of 244 the namespace introduced for CGA Type Tags; see RFC 245 3972 and 246 http://www.iana.org/assignments/cga-message-types. 248 OGA ID : A 4-bit long identifier for the Hash_function 249 in use within the specific usage context. 251 Hash_function : The one-way hash function (i.e., hash function 252 with pre-image resistance and second pre-image 253 resistance) to be used as identified by the 254 value for the OGA ID according document 255 defining the context usage identified by the 256 Context ID. For example, the version 2 of the 257 HIP specification defines SHA1 [RFC3174] as 258 the hash function to be used to generate 259 ORCHIDv2 used in the HIPv2 protocol when the 260 OGA ID is 3 [I-D.ietf-hip-rfc5201-bis]. 262 Encode_96( ) : An extraction function in which output is obtained 263 by extracting the middle 96-bit-long bitstring 264 from the argument bitstring. 266 Prefix : A constant 28-bit-long bitstring value 267 (IANA TBD 2001:????::/28 ?). 269 To form an ORCHID, two pieces of input data are needed. The first 270 piece can be any bitstring, but is typically expected to contain a 271 public cryptographic key and some other data. The second piece is a 272 context identifier, which is a 128-bit-long datum, allocated as 273 specified in Section 6. Each specific experiment (such as HIP HITs 274 or MIP6 TMIs) is expected to allocate their own, specific context 275 identifier. 277 The input bitstring and context identifier are concatenated to form 278 an input datum, which is then fed to the cryptographic hash function 279 to be used for the value of the OGA identifier according to the 280 document defining the context usage identified by the Context ID. 281 The result of the hash function is processed by an encoding function, 282 resulting in a 96-bit-long value. This value is prepended with the 283 concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The 284 result is the ORCHID, a 128-bit-long bitstring that can be used at 285 the IPv6 APIs in hosts participating to the particular experiment. 287 The ORCHID prefix is allocated under the IPv6 global unicast address 288 block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast 289 addresses. However, it should be noted that ORCHIDs do not conform 290 with the IPv6 global unicast address format defined in Section 2.5.4 291 of [RFC4291] since they do not have a 64-bit Interface ID formatted 292 as described in Section 2.5.1. of [RFC4291]. 294 3. Routing and Forwarding Considerations 296 ORCHIDs are designed to serve as location independent endpoint- 297 identifiers rather than IP-layer locators. Therefore, routers MAY be 298 configured not to forward any packets containing an ORCHID as a 299 source or a destination address. If the destination address is an 300 ORCHID but the source address is a valid unicast source address, 301 routers MAY be configured to generate an ICMP Destination 302 Unreachable, Administratively Prohibited message. 304 ORCHIDs are not designed for use in IPv6 routing protocols, since 305 such routing protocols are based on the architectural definition of 306 IPv6 addresses. Future non-IPv6 routing systems, such as overlay 307 routing systems, may be designed based on ORCHIDs. Any such ORCHID- 308 based routing system is out of scope of this document. 310 Router software MUST NOT include any special handling code for 311 ORCHIDs. In other words, the non-routability property of ORCHIDs, if 312 implemented, MUST be implemented via configuration and NOT by 313 hardwired software code. At this time, it is RECOMMENDED that the 314 default router configuration not handle ORCHIDs in any special way. 315 In other words, there is no need to touch existing or new routers due 316 to ORCHIDs. If such a reason should later appear, for example, due 317 to a faulty implementation leaking ORCHIDs to the IP layer, the 318 prefix can be and should be blocked by a simple configuration rule. 320 4. Design Choices 322 The design of this namespace faces two competing forces: 324 o As many bits as possible should be preserved for the hash result. 326 o It should be possible to share the namespace between multiple 327 mechanisms. 329 The desire to have a long hash result requires that the prefix be as 330 short as possible, and use few (if any) bits for additional encoding. 331 The present design takes this desire to the maximum: all the bits 332 beyond the prefix and the ORCHID generation algorithm identifier are 333 used as hash output. This leaves no bits in the ORCHID itself 334 available for identifying the context, however the 4 bits used to 335 encode the ORCHID generation algorithm identifier provides 336 cryptographich agility with respect to the hash function in use for a 337 given context; see Section 5. 339 The desire to allow multiple mechanisms to share the namespace has 340 been resolved by including the context identifier in the hash- 341 function input. While this does not allow the mechanism to be 342 directly inferred from a ORCHID, it allows one to verify that a given 343 input bitstring and ORCHID belong to a given context, with high- 344 probability; but also see Section 5. 346 5. Security Considerations 348 ORCHIDs are designed to be securely bound to the Context ID and the 349 bitstring used as the input parameters during their generation. To 350 provide this property, the ORCHID generation algorithm relies on the 351 second-preimage resistance (a.k.a. one-way) property of the hash 352 function used in the generation [RFC4270]. To have this property and 353 to avoid collisions, it is important that the allocated prefix is as 354 short as possible, leaving as many bits as possible for the hash 355 output. 357 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 358 the same mechanism for generating an ORCHID from the input bitstring. 359 Allowing different mechanisms, without explicitly encoding the 360 mechanism in the Context ID or the ORCHID itself, would allow so- 361 called bidding-down attacks. That is, if multiple different hash 362 functions were allowed to construct ORCHIDs valid for the same 363 Context ID, and if one of the hash functions became insecure, that 364 would allow attacks against even those ORCHIDs valid for the same 365 Context ID that had been constructed using the other, still secure 366 hash functions. 368 An identifier for the hash function to be used for the ORCHID 369 generation is encoded in the ORCHID itself, while the semantic for 370 the values taken by this identifier are defined separately for each 371 Context ID. Therefore, the present design allows to use different 372 hash functions to be used per given Context ID for constructing 373 ORCHIDs from input bitstrings. If more secure hash functions are 374 later needed, newer values for the ORCHID generation algorithm can be 375 defined for the given Context ID. 377 In order to preserve a low enough probability of collisions (see 378 Appendix A), each method MUST utilize a mechanism that makes sure 379 that the distinct input bitstrings are either unique or statistically 380 unique within that context. There are several possible methods to 381 ensure this; for example, one can include into the input bitstring a 382 globally maintained counter value, a pseudo-random number of 383 sufficient entropy (minimum 96 bits), or a randomly generated public 384 cryptographic key. The Context ID makes sure that input bitstrings 385 from different contexts never overlap. These together make sure that 386 the probability of collisions is determined only by the probability 387 of natural collisions in the hash space and is not increased by a 388 possibility of colliding input bitstrings. 390 6. IANA Considerations 392 Because the updated ORCHIDv2 format is not backward compatible with 393 the earlier one, IANA is requested to allocate a new 28-bit prefix 394 out of the IANA IPv6 Special Purpose Address Block, namely 395 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily 396 allocated for the experimental ORCHID is to be returned to IANA in 397 2014 [RFC4843]. 399 The Context Identifier (or Context ID) is a randomly generated value 400 defining the usage context of an ORCHID and the hash function to be 401 used for generation of ORCHIDs in this context. This document 402 defines no specific value. The Context ID shares the name space 403 introduced for CGA Type Tags. Hence, defining new values follows the 404 rules of Section 8 of [RFC3972], i.e., First Come First Served. 406 7. Contributors 408 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an 409 earlier, experimental version of this specification [RFC4843]. 411 8. Acknowledgments 413 Special thanks to Geoff Huston for his sharp but constructive 414 critique during the development of this memo. Tom Henderson helped 415 to clarify a number of issues. This document has also been improved 416 by reviews, comments, and discussions originating from the IPv6, 417 Internet Area, and IETF communities. 419 9. References 421 9.1. Normative references 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 427 RFC 3972, March 2005. 429 9.2. Informative references 431 [I-D.ietf-hip-rfc5201-bis] 432 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 433 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 434 hip-rfc5201-bis-14 (work in progress), October 2013. 436 [PRIVACYTEXT] 437 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 438 Work in Progress, July 2006. 440 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 441 E. Lear, "Address Allocation for Private Internets", BCP 442 5, RFC 1918, February 1996. 444 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 445 (SHA1)", RFC 3174, September 2001. 447 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 448 Hashes in Internet Protocols", RFC 4270, November 2005. 450 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 451 Architecture", RFC 4291, February 2006. 453 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 454 for Overlay Routable Cryptographic Hash Identifiers 455 (ORCHID)", RFC 4843, April 2007. 457 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 458 "Special-Purpose IP Address Registries", BCP 153, RFC 459 6890, April 2013. 461 Appendix A. Collision Considerations 463 As noted earlier, the aim is that so long as keys are not reused, 464 ORCHIDs be globally unique in a statistical sense. That is, given 465 the ORCHID referring to a given entity, the probability of the same 466 ORCHID being used to refer to another entity elsewhere in the 467 Internet must be sufficiently low so that it can be ignored for most 468 practical purposes. We believe that the presented design meets this 469 goal; see Section 4. 471 As mentioned above, ORCHIDs are expected to be used at the legacy 472 IPv6 APIs between consenting hosts. The context ID is intended to 473 differentiate between the various experiments, or contexts, sharing 474 the ORCHID namespace. However, the context ID is not present in the 475 ORCHID itself, but only in front of the input bitstring as an input 476 to the hash function. While this may lead to certain implementation- 477 related complications, we believe that the trade-off of allowing the 478 hash result part of an ORCHID being longer more than pays off the 479 cost. 481 Because ORCHIDs are not routable at the IP layer, in order to send 482 packets using ORCHIDs at the API level, the sending host must have 483 additional overlay state within the stack to determine which 484 parameters (e.g., what locators) to use in the outgoing packet. An 485 underlying assumption here, and a matter of fact in the proposals 486 that the authors are aware of, is that there is an overlay protocol 487 for setting up and maintaining this additional state. It is assumed 488 that the state-set-up protocol carries the input bitstring, and that 489 the resulting ORCHID-related state in the stack can be associated 490 back with the appropriate context and state-set-up protocol. 492 Appendix B. Changes from RFC 4843 494 o Updated HIP references to revised HIP specifications. 496 o The Overlay Routable Cryptographic Hash Identifiers originally 497 defined in [RFC4843] lacked a mechanism for cryptographic 498 algorithm agility. The updated ORCHID format specified in this 499 document removes this limitation by encoding in the identifier 500 itself an index to the suite of cryptographic algorithms in use. 502 o Moved the collision considerations section into an annex, and 503 removed unnecessary discussions. 505 o Removed the discussion on overlay routing. 507 Authors' Addresses 509 Julien Laganier 510 Luminate Wireless, Inc. 511 Cupertino, CA 512 USA 514 EMail: julien.ietf@gmail.com 516 Francis Dupont 517 Internet Systems Consortium 519 EMail: fdupont@isc.org