idnits 2.17.1 draft-ietf-hip-rfc4843-bis-07.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 (June 25, 2014) is 3565 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: December 27, 2014 June 25, 2014 8 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 9 Version 2 (ORCHIDv2) 10 draft-ietf-hip-rfc4843-bis-07 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 December 27, 2014. 50 Copyright Notice 52 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 IETF 117 would consider such practice potentially dangerous. A specific 118 danger would be realised if the IETF community later decided to use 119 the ORCHID prefix for some different purpose. In that case, hosts 120 using the ORCHID prefix would be, for practical purposes, unable to 121 use the prefix for the other new purpose. That would lead to partial 122 balkanisation of the Internet, similar to what has happened as a 123 result of historical hijackings of non-RFC 1918 [RFC1918] IPv4 124 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 implement with 144 protocol stack extensions, such as secure overlay routing, HIP, or 145 Mobile IP privacy extensions, without requiring them to update their 146 applications. The goal is to facilitate large-scale deployments with 147 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 was returned to IANA in March 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 | OGA ID | 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, is to be implemented via configuration rather than by 313 hardwired software code, e.g., the ORCHID prefix can be blocked by a 314 simple configuration rule such as an Access Control List entry. 316 4. Design Choices 318 The design of this namespace faces two competing forces: 320 o As many bits as possible should be preserved for the hash result. 322 o It should be possible to share the namespace between multiple 323 mechanisms. 325 The desire to have a long hash result requires that the prefix be as 326 short as possible, and use few (if any) bits for additional encoding. 327 The present design takes this desire to the maximum: all the bits 328 beyond the prefix and the ORCHID generation algorithm identifier are 329 used as hash output. This leaves no bits in the ORCHID itself 330 available for identifying the context, however the 4 bits used to 331 encode the ORCHID generation algorithm identifier provides 332 cryptographich agility with respect to the hash function in use for a 333 given context; see Section 5. 335 The desire to allow multiple mechanisms to share the namespace has 336 been resolved by including the context identifier in the hash- 337 function input. While this does not allow the mechanism to be 338 directly inferred from a ORCHID, it allows one to verify that a given 339 input bitstring and ORCHID belong to a given context, with high- 340 probability; but also see Section 5. 342 5. Security Considerations 344 ORCHIDs are designed to be securely bound to the Context ID and the 345 bitstring used as the input parameters during their generation. To 346 provide this property, the ORCHID generation algorithm relies on the 347 second-preimage resistance (a.k.a. one-way) property of the hash 348 function used in the generation [RFC4270]. To have this property and 349 to avoid collisions, it is important that the allocated prefix is as 350 short as possible, leaving as many bits as possible for the hash 351 output. 353 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 354 the same mechanism for generating an ORCHID from the input bitstring. 355 Allowing different mechanisms, without explicitly encoding the 356 mechanism in the Context ID or the ORCHID itself, would allow so- 357 called bidding-down attacks. That is, if multiple different hash 358 functions were allowed to construct ORCHIDs valid for the same 359 Context ID, and if one of the hash functions became insecure, that 360 would allow attacks against even those ORCHIDs valid for the same 361 Context ID that had been constructed using the other, still secure 362 hash functions. 364 An identifier for the hash function to be used for the ORCHID 365 generation is encoded in the ORCHID itself, while the semantic for 366 the values taken by this identifier are defined separately for each 367 Context ID. Therefore, the present design allows to use different 368 hash functions to be used per given Context ID for constructing 369 ORCHIDs from input bitstrings. If more secure hash functions are 370 later needed, newer values for the ORCHID generation algorithm can be 371 defined for the given Context ID. 373 In order to preserve a low enough probability of collisions (see 374 Appendix A), each method MUST utilize a mechanism that makes sure 375 that the distinct input bitstrings are either unique or statistically 376 unique within that context. There are several possible methods to 377 ensure this; for example, one can include into the input bitstring a 378 globally maintained counter value, a pseudo-random number of 379 sufficient entropy (minimum 96 bits), or a randomly generated public 380 cryptographic key. The Context ID makes sure that input bitstrings 381 from different contexts never overlap. These together make sure that 382 the probability of collisions is determined only by the probability 383 of natural collisions in the hash space and is not increased by a 384 possibility of colliding input bitstrings. 386 6. IANA Considerations 388 Because the updated ORCHIDv2 format is not backward compatible with 389 the earlier one, IANA is requested to allocate a new 28-bit prefix 390 out of the IANA IPv6 Special Purpose Address Block, namely 391 2001:0000::/23, as per [RFC6890]. The prefix that was temporarily 392 allocated for the experimental ORCHID was returned to IANA in March 393 2014 [RFC4843]. 395 The Context Identifier (or Context ID) is a randomly generated value 396 defining the usage context of an ORCHID and the hash function to be 397 used for generation of ORCHIDs in this context. This document 398 defines no specific value. The Context ID shares the name space 399 introduced for CGA Type Tags. Hence, defining new values follows the 400 rules of Section 8 of [RFC3972], i.e., First Come First Served. 402 7. Contributors 404 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an 405 earlier, experimental version of this specification [RFC4843]. 407 8. Acknowledgments 409 Special thanks to Geoff Huston for his sharp but constructive 410 critique during the development of this memo. Tom Henderson helped 411 to clarify a number of issues. This document has also been improved 412 by reviews, comments, and discussions originating from the IPv6, 413 Internet Area, and IETF communities. 415 9. References 417 9.1. Normative references 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, March 1997. 422 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 423 RFC 3972, March 2005. 425 9.2. Informative references 427 [I-D.ietf-hip-rfc5201-bis] 428 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 429 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 430 hip-rfc5201-bis-14 (work in progress), October 2013. 432 [PRIVACYTEXT] 433 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 434 Work in Progress, July 2006. 436 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 437 E. Lear, "Address Allocation for Private Internets", BCP 438 5, RFC 1918, February 1996. 440 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 441 (SHA1)", RFC 3174, September 2001. 443 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 444 Hashes in Internet Protocols", RFC 4270, November 2005. 446 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 447 Architecture", RFC 4291, February 2006. 449 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 450 for Overlay Routable Cryptographic Hash Identifiers 451 (ORCHID)", RFC 4843, April 2007. 453 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 454 "Special-Purpose IP Address Registries", BCP 153, RFC 455 6890, April 2013. 457 Appendix A. Collision Considerations 459 As noted earlier, the aim is that so long as keys are not reused, 460 ORCHIDs be globally unique in a statistical sense. That is, given 461 the ORCHID referring to a given entity, the probability of the same 462 ORCHID being used to refer to another entity elsewhere in the 463 Internet must be sufficiently low so that it can be ignored for most 464 practical purposes. We believe that the presented design meets this 465 goal; see Section 4. 467 As mentioned above, ORCHIDs are expected to be used at the legacy 468 IPv6 APIs between consenting hosts. The context ID is intended to 469 differentiate between the various experiments, or contexts, sharing 470 the ORCHID namespace. However, the context ID is not present in the 471 ORCHID itself, but only in front of the input bitstring as an input 472 to the hash function. While this may lead to certain implementation- 473 related complications, we believe that the trade-off of allowing the 474 hash result part of an ORCHID being longer more than pays off the 475 cost. 477 Because ORCHIDs are not routable at the IP layer, in order to send 478 packets using ORCHIDs at the API level, the sending host must have 479 additional overlay state within the stack to determine which 480 parameters (e.g., what locators) to use in the outgoing packet. An 481 underlying assumption here, and a matter of fact in the proposals 482 that the authors are aware of, is that there is an overlay protocol 483 for setting up and maintaining this additional state. It is assumed 484 that the state-set-up protocol carries the input bitstring, and that 485 the resulting ORCHID-related state in the stack can be associated 486 back with the appropriate context and state-set-up protocol. 488 Appendix B. Changes from RFC 4843 490 o Updated HIP references to revised HIP specifications. 492 o The Overlay Routable Cryptographic Hash Identifiers originally 493 defined in [RFC4843] lacked a mechanism for cryptographic 494 algorithm agility. The updated ORCHID format specified in this 495 document removes this limitation by encoding in the identifier 496 itself an index to the suite of cryptographic algorithms in use. 498 o Moved the collision considerations section into an annex, and 499 removed unnecessary discussions. 501 o Removed the discussion on overlay routing. 503 Authors' Addresses 505 Julien Laganier 506 Luminate Wireless, Inc. 507 Cupertino, CA 508 USA 510 EMail: julien.ietf@gmail.com 512 Francis Dupont 513 Internet Systems Consortium 515 EMail: fdupont@isc.org