idnits 2.17.1 draft-moskowitz-hip-hierarchical-hit-02.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 is 1 instance of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 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 (17 October 2019) is 1647 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track S. Card 5 Expires: 19 April 2020 A. Wiethuechter 6 AX Enterprize 7 17 October 2019 9 Hierarchical HITs for HIPv2 10 draft-moskowitz-hip-hierarchical-hit-02 12 Abstract 14 This document describes using a hierarchical HIT to facilitate large 15 deployments of managed devices. Hierarchical HITs differ from HIPv2 16 flat HITs by only using 64 bits for mapping the Host Identity, 17 freeing 32 bits to bind in a hierarchy of Registering Entities that 18 provide services to the consumers of hierarchical HITs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 19 April 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 56 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Meeting the future of Mobile Devices in a public 59 space . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Semi-permanency of Identities . . . . . . . . . . . . . . 4 61 3.3. Managing a large flat address space . . . . . . . . . . . 4 62 3.4. Defense against fraudulent HITs . . . . . . . . . . . . . 4 63 4. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 4 64 4.1. HHIT prefix . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 5 66 4.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 5 67 4.3.1. The Registered Assigning Authority (RAA) . . . . . . 5 68 4.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 6 69 4.3.3. Example of the HID DNS . . . . . . . . . . . . . . . 6 70 4.3.4. HHIT DNS Retrieval . . . . . . . . . . . . . . . . . 6 71 4.3.5. Changes to ORCHIDv2 to support Hierarchical 72 HITs . . . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3.6. Collision risks with Hierarchical HITs . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Appendix A. Calculating Collision Probabilities . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 This document expands on HIPv2 [RFC7401] to describe the structure of 86 a hierarchical HIT (HHIT). Some of the challenges for large scale 87 deployment addressed by HHITs are presented. The basics for the 88 hierarchical HIT registries are defined here. 90 Separate documents will further expand on the registry service and 91 how a device can advertise its availability and services provided. 93 2. Terms and Definitions 95 2.1. Requirements Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. ` 103 2.2. Definitions 105 HDA (Hierarchical HIT Domain Authority): The 14 bit field 106 identifying the HIT Domain Authority under an RAA. 108 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 110 RAA (Registered Assigning Authority): The 18 bit field identifying 111 the Hierarchical HIT Assigning Authority. 113 3. Problem Space 115 3.1. Meeting the future of Mobile Devices in a public space 117 Public safety may impose a "right to know" what devices are in a 118 public space. Public space use may only be permitted to devices that 119 meet an exacting "who are you" query. This implies a device identity 120 that can be quickly validated by public safety personal and even the 121 general public in many situations. 123 Many proposals for mobile device identities are nothing more than a 124 string of bits. These may provide information about the device but 125 provide no assurance that the identity associated with a device 126 really belongs to a particular device. Further they may impose a 127 slow, complex method to discover the device owner to those with 128 appropriate authorization. 130 The Host Identity Tag (HIT) from the Host Identity Protocol (HIP) 131 provides a self-asserting Identity through a public key signing 132 operation using the Host Identity's (HI) private key. 134 Although the HIT provides a "trust me, I am me" claim, it does not 135 provide an assertion as to why the claim should be trusted and any 136 additional side information about the device. The later could be 137 distributed directly from the device in a secure manner, but again 138 there is no 3rd-party assertion of such a claim. 140 3.2. Semi-permanency of Identities 142 A device Identity has some degree of permanency. A device creates 143 its identity and registers it to some 3rd-party that will assert a 144 level of trust for that identity. A device may have multiple 145 identities to use in different contexts, and it may deprecate an 146 identity for any number of reasons. The asserting 3rd-party may 147 withdraw its assertion of an identity for any number of reasons. An 148 identity system needs to facilitate all of this. 150 3.3. Managing a large flat address space 152 For HITs to be successfully used by a large population of mobile 153 devices, it must support an Identity per device; potentially 10 154 billion Identities. Perhaps a Distributed Hash Table [RFC6537] can 155 scale this large. There is still the operational challenges in 156 establishing such a world-wide DHT implementation and how RVS 157 [RFC8004] works with such a large population. There is also the 158 challenge of how to turn this into a viable business. How can 159 different controlling jurisdictions operate in such an environment? 161 Even though the probability of collisions with 7B HITs (one HIT per 162 person) in a 96 bit flat address space is 3.9E-10, it is still real. 163 How are collisions managed? It is also possible that weak key 164 uniqueness, as has been shown in deployed TLS certificates 165 [WeakKeys], results in a much greater probability of collisions. 166 Thus resolution of collisions needs to be a feature in a global 167 namespace. 169 3.4. Defense against fraudulent HITs 171 How can a host protect against a fraudulent HIT? That is, a second 172 pre-image attack on the HI hash that produces the HIT. A strong 173 defense would require every HIT/HI registered and openly verifiable. 174 This would best be done as part of the R1 and I2 validation. Or any 175 other message that is signed by the HI private key. 177 4. The Hierarchical Host Identity Tag (HHIT) 179 The Hierarchical HIT (HHIT) is a small but important enhancement over 180 the flat HIT space. By adding two levels of hierarchical 181 administration control, the HHIT provides for device registration/ 182 ownership, thereby enhancing the trust framework for HITs. 184 HHITs represent the HI in only a 64 bit hash and uses the other 32 185 bits to create a hierarchical administration organization for HIT 186 domains. Hierarchical HITs are ORCHIDs [RFC7343]. The change in 187 construction rules are in Section 4.3.5. 189 A HHIT is built from the following fields: 191 * 28 bit IANA prefix 193 * 4 bit HIT Suite ID 195 * 32 bit Hierarchy ID (HID) 197 * 64 bit ORCHID hash 199 4.1. HHIT prefix 201 A unique 28 bit prefix for HHITs would be ideal. It would clearly 202 separate the flat-space HIT processing from HHIT processing. 203 However, the prefix is the domain of ORCHIDs [RFC7343], and cannot be 204 changed directly here. Proposing a unique prefix to simplify 205 Section 4.2 is in scope of this draft. 207 4.2. HHIT Suite IDs 209 The HIT Suite IDs specifies the HI and hash algorithms. Any HIT 210 Suite ID can be used for HHITs, provided that the prefix for HHITs is 211 different from flat space HITs. Without a unique prefix Section 4.1, 212 additional HIT Suite IDs would be needed for HHITs. This would risk 213 exhausting the limited Suite ID space of only 15 IDs. 215 4.3. The Hierarchy ID (HID) 217 The Hierarchy ID (HID) provides the structure to organize HITs into 218 administrative domains. HIDs are further divided into 2 fields: 220 * 14 bit Registered Assigning Authority (RAA) 222 * 18 bit Hierarchical HIT Domain Authority (HDA) 224 4.3.1. The Registered Assigning Authority (RAA) 226 An RAA is a business or organization that manages a registry of HDAs. 227 For example, the Federal Aviation Authority (FAA) could be an RAA. 229 The RAA is a 14 bit field (16,384 RAAs) assigned by a numbers 230 management organization, perhaps ICANN's IANA service. An RAA must 231 provide a set of services to allocate HDAs to organizations. It must 232 have a public policy on what is necessary to obtain an HDA. The RAA 233 need not maintain any HIP related services. It must maintain a DNS 234 zone minimally for discovering HID RVS servers. 236 This DNS zone may be a PTR for its RAA. It may be a zone in a HHIT 237 specific DNS zone. Assume that the RAA is 100. The PTR record could 238 be constructed: 240 100.hhit.arpa IN PTR raa.bar.com. 242 4.3.2. The Hierarchical HIT Domain Authority (HDA) 244 An HDA may be an ISP or any third party that takes on the business to 245 provide RVS and other needed services for HIP enabled devices. 247 The HDA is an 18 bit field (262,144 HDAs per RAA) assigned by an RAA. 248 An HDA should maintain a set of RVS servers that its client HIP- 249 enabled customers use. How this is done and scales to the 250 potentially millions of customers is outside the scope of this 251 document. This service should be discoverable through the DNS zone 252 maintained by the HDA's RAA. 254 An RAA may assign a block of values to an individual organization. 255 This is completely up to the individual RAA's published policy for 256 delegation. 258 4.3.3. Example of the HID DNS 260 HID related services should be discoverable via DNS. For example the 261 RVS for a HID could be found via the following. Assume that the RAA 262 is 100 and the HDA is 50. The PTR record is constructed as: 264 50.100.hhit.arpa IN PTR rvs.foo.com. 266 The RAA is running its zone, 100.hhit.arpa under the hhit.arpa zone. 268 4.3.4. HHIT DNS Retrieval 270 The HDA SHOULD provide DNS retrieval per [RFC8005]. Assume that the 271 RAA is 10 and the HDA is 20 and the HHIT is: 273 2001:14:28:14:a3ad:1952:ad0:a69e 275 The HHIT FQDN is: 277 2001:14:28:14:a3ad:1952:ad0:a69e.20.10.hhit.arpa. 279 The NS record for the HDA zone is constructed as: 281 20.10.hhit.arpa IN NS registry.foo.com. 283 registry.foo.com returns a HIP RR with the HHIT and matching HI. The 284 HDA sets its policy on TTL for caching the HIP RR. Optionally, the 285 HDA may include RVS information. Including RVS in the HIP RR may 286 impact the TTL for the response. 288 4.3.5. Changes to ORCHIDv2 to support Hierarchical HITs 290 ORCHIDv2 [RFC7343] has a number of inputs including a Context ID 291 (unique for HHITs), some header bits, the hash algorithm, and the 292 public key. The output is a 96 bit value. Hierarchical HIT makes 293 the following changes. The HID is added as part of the header bits 294 and the output is a 64 bit value, derived the same way as the 96 bit 295 hash. 297 Input := HID | HOST_ID 298 OGA ID := 4-bit Orchid Generation Algorithm identifier 299 The HHIT Suite ID 300 Hash Input := Context ID | Input 301 Context ID = 0x00B5 A69C 795D F5D5 302 F008 7F56 843F 2C40 303 Prefix := HIPv2 Prefix 304 Note: per section 4.1, this should be a different Prefix 305 HID := Hierarchy ID 306 Hash := Hash_function( Hash Input ) 307 Encode_64 := Same as Encode_96, but only 64 bits 308 ORCHID := Prefix | OGA ID | HID | Encode_64( Hash ) 310 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 311 as they are clearly separated by the distinct HIT Suite ID. 313 4.3.6. Collision risks with Hierarchical HITs 315 The 64 bit hash size does have an increased risk of collisions over 316 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 317 probability of a collision in a population of 66 million. The 318 probability goes up to 1% for a population of 663 million. See 319 Appendix A for the collision probability formula. 321 However, this risk of collision is within a single HDA. Further, all 322 HDAs are expected to provide a registration process for reverse 323 lookup validation. This registration process would reject a 324 collision, forcing the client to generate a new HI and thus 325 hierarchical HIT and reapplying to the registration process. 327 5. IANA Considerations 329 Because HHIT use of ORCHIDv2 format is not compatible with [RFC7343], 330 IANA is requested to allocated a new 28-bit prefix out of the IANA 331 IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per 332 [RFC6890]. 334 6. Security Considerations 336 A 64 bit hash space presents a real risk of second pre-image attacks. 337 The HHIT Registry services effectively block attempts to "take over" 338 a HHIT. It does not stop a rogue attempting to impersonate a known 339 HHIT. This attack can be mitigated by the Responder using DNS to 340 find the HI for the HHIT or the RVS for the HHIT that then provides 341 the registered HI. 343 The two risks with hierarchical HITs are the use of an invalid HID 344 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 345 a strong protection against invalid HIDs. Querying an HDA's RVS for 346 a HIT under the HDA protects against talking to unregistered clients. 347 The Registry service has direct protection against forced or 348 accidental HIT hash collisions. 350 7. Acknowledgments 352 The initial versions of this document were developed with the 353 assistance of Xiaohu Xu and Bingyang Liu of Huawei. 355 Sue Hares contributed to the clarity in this document. 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 367 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 368 May 2017, . 370 8.2. Informative References 372 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 373 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 374 2012, . 376 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 377 "Special-Purpose IP Address Registries", BCP 153, 378 RFC 6890, DOI 10.17487/RFC6890, April 2013, 379 . 381 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 382 Routable Cryptographic Hash Identifiers Version 2 383 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 384 2014, . 386 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 387 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 388 RFC 7401, DOI 10.17487/RFC7401, April 2015, 389 . 391 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 392 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 393 October 2016, . 395 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 396 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 397 October 2016, . 399 [WeakKeys] Heninger, N.H., Durumeric, Z.D., Wustrow, E.W., and J.A.H. 400 Halderman, "Detection of Widespread Weak Keys in Network 401 Devices", August 2012, 402 . 404 Appendix A. Calculating Collision Probabilities 406 The accepted formula for calculating the probability of a collision 407 is: 409 p = 1 - e^{-k^2/(2n)} 411 P Collision Probability 412 n Total possible population 413 k Actual population 415 Authors' Addresses 417 Robert Moskowitz 418 HTT Consulting 419 Oak Park, MI 48237 420 United States of America 422 Email: rgm@labs.htt-consult.com 424 Stuart W. Card 425 AX Enterprize 426 4947 Commercial Drive 427 Yorkville, NY 13495 428 United States of America 430 Email: stu.card@axenterprize.com 432 Adam Wiethuechter 433 AX Enterprize 434 4947 Commercial Drive 435 Yorkville, NY 13495 436 United States of America 438 Email: adam.wiethuechter@axenterprize.com