idnits 2.17.1 draft-moskowitz-hip-hierarchical-hit-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 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. -- The draft header indicates that this document updates RFC7401, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 May 2020) is 1443 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft HTT Consulting 4 Updates: 7401 (if approved) S. Card 5 Intended status: Standards Track A. Wiethuechter 6 Expires: 13 November 2020 AX Enterprize 7 12 May 2020 9 Hierarchical HITs for HIPv2 10 draft-moskowitz-hip-hierarchical-hit-05 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 13 November 2020. 37 Copyright Notice 39 Copyright (c) 2020 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 space . 4 59 3.2. Semi-permanency of Identities . . . . . . . . . . . . . . 4 60 3.3. Managing a large flat address space . . . . . . . . . . . 4 61 3.4. Defense against fraudulent HITs . . . . . . . . . . . . . 5 62 4. The Hierarchical Host Identity Tag (HHIT) . . . . . . . . . . 5 63 4.1. HHIT prefix . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2. HHIT Suite IDs . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 6 66 4.3.1. The Registered Assigning Authority (RAA) . . . . . . 6 67 4.3.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 6 68 4.3.3. Example of the HID DNS . . . . . . . . . . . . . . . 7 69 4.3.4. HHIT DNS Retrieval . . . . . . . . . . . . . . . . . 7 70 4.3.5. Changes to ORCHIDv2 to support Hierarchical HITs . . 7 71 4.3.6. Collision risks with Hierarchical HITs . . . . . . . 8 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Appendix A. Calculating Collision Probabilities . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 This document expands on HIPv2 [RFC7401] to describe the structure of 84 a hierarchical HIT (HHIT). Some of the challenges for large scale 85 deployment addressed by HHITs are presented. The basics for the 86 hierarchical HIT registries are defined here. 88 Including hierarchy information within the HIT is not a new concept. 89 This was part of the original HIPv1 Architecture 90 [draft.moskowitz-hip-arch-02]. It was dropped from the HIPv1 work 91 for lack of a use case and concerns over the smaller HI mapping 92 space. It was later brought up in the HIP Research Group (HIP-RG) in 93 [draft.zhang-hip-hierarchical-parameter-00], but this never gained 94 concensus. 96 Hierarchical HITs now have a solid use case with Public, mobile 97 devices (e.g. Unmanned Aircraft). The math to evaluate the 98 statistical collision risk is available, Appendix A. And finally, 99 HHIT Registries [hhit-registries] provide a way to manage the 100 hierarchy. 102 2. Terms and Definitions 104 2.1. Requirements Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2.2. Definitions 114 HDA (Hierarchical HIT Domain Authority): 115 The 16 bit field identifying the HIT Domain Authority under an 116 RAA. 118 HID (Hierarchy ID): 119 The 32 bit field providing the HIT Hierarchy ID. 121 RAA (Registered Assigning Authority): 122 The 16 bit field identifying the Hierarchical HIT Assigning 123 Authority. 125 RVS (Rendezvous Server): 126 The HIP Rendezvous Server for enabling mobility, as defined in 127 [RFC8004]. 129 3. Problem Space 130 3.1. Meeting the future of Mobile Devices in a public space 132 Public safety may impose a "right to know" what devices are in a 133 public space. Public space use may only be permitted to devices that 134 meet an exacting "who are you" query. This implies a device identity 135 that can be quickly validated by public safety personal and even the 136 general public in many situations. 138 Many proposals for mobile device identities are nothing more than a 139 string of bits. These may provide information about the device but 140 provide no assurance that the identity associated with a device 141 really belongs to a particular device; they are highly susceptible to 142 fraudulent use. Further they may impose a slow, complex method to 143 discover the device owner to those with appropriate authorization. 145 The Host Identity Tag (HIT) from the Host Identity Protocol (HIP) 146 provides a self-asserting Identity through a public key signing 147 operation using the Host Identity's (HI) private key. 149 Although the HIT provides a "trust me, I am me" claim, it does not 150 provide an assertion as to why the claim should be trusted and any 151 additional side information about the device. The later could be 152 distributed directly from the device in a secure manner, but again 153 there is no 3rd-party assertion of such a claim. 155 3.2. Semi-permanency of Identities 157 A device Identity has some degree of permanency. A device creates 158 its identity and registers it to some 3rd-party that will assert a 159 level of trust for that identity. A device may have multiple 160 identities to use in different contexts, and it may deprecate an 161 identity for any number of reasons. The asserting 3rd-party may 162 withdraw its assertion of an identity for any number of reasons. An 163 identity system needs to facilitate all of this. 165 3.3. Managing a large flat address space 167 For HITs to be successfully used by a large population of mobile 168 devices, they must support an Identity per device; potentially 10 169 billion Identities. Perhaps a Distributed Hash Table [RFC6537] can 170 scale this large. There is still the operational challenges in 171 establishing such a world-wide DHT implementation and how RVS 172 [RFC8004] works with such a large population. There is also the 173 challenge of how to turn this into a viable business. How can 174 different controlling jurisdictions operate in such an environment? 175 Even though the probability of collisions with 7B HITs (one HIT per 176 person) in a 96 bit flat address space is 3.9E-10, it is still real. 177 How are collisions managed? It is also possible that weak key 178 uniqueness, as has been shown in deployed TLS certificates 179 [WeakKeys], results in a much greater probability of collisions. 180 Thus resolution of collisions needs to be a feature in a global 181 namespace. 183 3.4. Defense against fraudulent HITs 185 How can a host protect against a fraudulent HIT? That is, a second 186 pre-image attack on the HI hash that produces the HIT. A strong 187 defense would require every HIT/HI registered and openly verifiable. 188 This would best be done as part of the R1 and I2 validation. Or any 189 other message that is signed by the HI private key. 191 4. The Hierarchical Host Identity Tag (HHIT) 193 The Hierarchical HIT (HHIT) is a small but important enhancement over 194 the flat HIT space. By adding two levels of hierarchical 195 administration control, the HHIT provides for device registration/ 196 ownership, thereby enhancing the trust framework for HITs. 198 HHITs represent the HI in only a 64 bit hash and uses the other 32 199 bits to create a hierarchical administration organization for HIT 200 domains. Hierarchical HITs are "Using cSHAKE in ORCHIDs" 201 [new-orchid]. The input values for the Encoding rules are in 202 Section 4.3.5. 204 A HHIT is built from the following fields: 206 * 28 bit IANA prefix 208 * 4 bit HIT Suite ID 210 * 32 bit Hierarchy ID (HID) 212 * 64 bit ORCHID hash 214 4.1. HHIT prefix 216 A unique 28 bit prefix for HHITs is recommended. It clearly 217 separates the flat-space HIT processing from HHIT processing per 218 Section 4 of "Using cSHAKE in ORCHIDs" [new-orchid]. 220 4.2. HHIT Suite IDs 222 The HIT Suite IDs specifies the HI and hash algorithms. Any HIT 223 Suite ID can be used for HHITs, provided that the prefix for HHITs is 224 different from flat space HITs. Without a unique prefix, 225 Section 4.1, additional HIT Suite IDs would be needed for HHITs. 226 This would risk exhausting the limited Suite ID space of only 15 IDs. 228 4.3. The Hierarchy ID (HID) 230 The Hierarchy ID (HID) provides the structure to organize HITs into 231 administrative domains. HIDs are further divided into 2 fields: 233 * 16 bit Registered Assigning Authority (RAA) 235 * 16 bit Hierarchical HIT Domain Authority (HDA) 237 4.3.1. The Registered Assigning Authority (RAA) 239 An RAA is a business or organization that manages a registry of HDAs. 240 For example, the Federal Aviation Authority (FAA) could be an RAA. 242 The RAA is a 16 bit field (65,536 RAAs) assigned by a numbers 243 management organization, perhaps ICANN's IANA service. An RAA must 244 provide a set of services to allocate HDAs to organizations. It must 245 have a public policy on what is necessary to obtain an HDA. The RAA 246 need not maintain any HIP related services. It must maintain a DNS 247 zone minimally for discovering HID RVS servers. 249 This DNS zone may be a PTR for its RAA. It may be a zone in a HHIT 250 specific DNS zone. Assume that the RAA is 100. The PTR record could 251 be constructed: 253 100.hhit.arpa IN PTR raa.bar.com. 255 4.3.2. The Hierarchical HIT Domain Authority (HDA) 257 An HDA may be an ISP or any third party that takes on the business to 258 provide RVS and other needed services for HIP enabled devices. 260 The HDA is an 16 bit field (65,536 HDAs per RAA) assigned by an RAA. 261 An HDA should maintain a set of RVS servers that its client HIP- 262 enabled customers use. How this is done and scales to the 263 potentially millions of customers is outside the scope of this 264 document. This service should be discoverable through the DNS zone 265 maintained by the HDA's RAA. 267 An RAA may assign a block of values to an individual organization. 268 This is completely up to the individual RAA's published policy for 269 delegation. 271 4.3.3. Example of the HID DNS 273 HID related services should be discoverable via DNS. For example the 274 RVS for a HID could be found via the following. Assume that the RAA 275 is 100 and the HDA is 50. The PTR record is constructed as: 277 50.100.hhit.arpa IN PTR rvs.foo.com. 279 The RAA is running its zone, 100.hhit.arpa under the hhit.arpa zone. 281 4.3.4. HHIT DNS Retrieval 283 The HDA SHOULD provide DNS retrieval per [RFC8005]. Assume that the 284 Host_ID suite of EdDSA25519 (5), RAA of 10 and the HDA of 20 and the 285 HHIT example is: 287 2001:5:a:14:a3ad:1952:ad0:a69e 289 The HHIT FQDN is: 291 2001:0005:a:14:a3ad:1952:0ad0:a69e.20.10.hhit.arpa. 293 The NS record for the HDA zone is constructed as: 295 20.10.hhit.arpa IN NS registry.foo.com. 297 registry.foo.com returns a HIP RR with the HHIT and matching HI. The 298 HDA sets its policy on TTL for caching the HIP RR. Optionally, the 299 HDA may include RVS information. Including RVS in the HIP RR may 300 impact the TTL for the response. 302 4.3.5. Changes to ORCHIDv2 to support Hierarchical HITs 304 A new format for ORCHIDs to support Hierarchical HITs is defined in 305 "Using cSHAKE in ORCHIDs" [new-orchid]. For this use the following 306 values apply: 308 Prefix := HHIT Prefix 309 Note: per section 4.1, this should be different 310 than the Prefix for RFC 7401 311 OGA ID := 4-bit Orchid Generation Algorithm identifier 312 The HHIT Suite ID 313 Context ID := 0x00B5 A69C 795D F5D5 F008 7F56 843F 2C40 314 Info (n) := 32 bit HID (Hierarchy ID) 315 Hash := Hash_function specified in OGA ID 316 If hash is not a variable length output hash, 317 then en Encode_m, similar to ORCHID Encode_96 318 is used 319 m := 64 321 4.3.6. Collision risks with Hierarchical HITs 323 The 64 bit hash size does have an increased risk of collisions over 324 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 325 probability of a collision in a population of 66 million. The 326 probability goes up to 1% for a population of 663 million. See 327 Appendix A for the collision probability formula. 329 However, this risk of collision is within a single HDA. Further, all 330 HDAs are expected to provide a registration process for reverse 331 lookup validation. This registration process would reject a 332 collision, forcing the client to generate a new HI and thus 333 hierarchical HIT and reapplying to the registration process. 335 5. IANA Considerations 337 Because HHIT use of ORCHIDv2 format is not compatible with [RFC7343], 338 IANA is requested to allocated a new 28-bit prefix out of the IANA 339 IPv6 Special Purpose Address Block, namely 2001:0000::/23, as per 340 [RFC6890]. 342 6. Security Considerations 344 A 64 bit hash space presents a real risk of second pre-image attacks. 345 The HHIT Registry services effectively block attempts to "take over" 346 a HHIT. It does not stop a rogue attempting to impersonate a known 347 HHIT. This attack can be mitigated by the Responder using DNS to 348 find the HI for the HHIT or the RVS for the HHIT that then provides 349 the registered HI. 351 Another mitigation of HHIT hijacking is if the HI owner supplies an 352 object containing the HHIT and signed by the HI private key of the 353 HDA. 355 The two risks with hierarchical HITs are the use of an invalid HID 356 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 357 a strong protection against invalid HIDs. Querying an HDA's RVS for 358 a HIT under the HDA protects against talking to unregistered clients. 359 The Registry service has direct protection against forced or 360 accidental HIT hash collisions. 362 7. Acknowledgments 364 The RDA/HDA 16/16 bit split, replacing the original 14/18 split was 365 the result of discussions on lookup and implementation challenges of 366 byte boundaries over nibble boundaries. 368 The initial versions of this document were developed with the 369 assistance of Xiaohu Xu and Bingyang Liu of Huawei. 371 Sue Hares contributed to the clarity in this document. 373 8. References 375 8.1. Normative References 377 [new-orchid] 378 Moskowitz, R., Card, S., and A. Wiethuechter, "Using 379 cSHAKE in ORCHIDs", Work in Progress, Internet-Draft, 380 draft-moskowitz-orchid-cshake-00, 11 December 2019, 381 . 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 390 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 391 RFC 7401, DOI 10.17487/RFC7401, April 2015, 392 . 394 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 395 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 396 May 2017, . 398 8.2. Informative References 400 [draft.moskowitz-hip-arch-02] 401 Moskowitz, R., "Host Identity Payload", Superseded 402 Internet-Draft, draft-moskowitz-hip-arch-02, 22 February 403 2001. 405 [draft.zhang-hip-hierarchical-parameter-00] 406 Dacheng, Z. and X. Xiaohu, "Extensions of Host Identity 407 Protocol (HIP) with Hierarchical Information", Abandoned 408 Internet-Draft, draft-zhang-hip-hierarchical-parameter-00, 409 27 May 2009. 411 [hhit-registries] 412 Moskowitz, R., Card, S., and A. Wiethuechter, 413 "Hierarchical HIT Registries", Work in Progress, Internet- 414 Draft, draft-moskowitz-hip-hhit-registries-02, 9 March 415 2020, . 418 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 419 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 420 2012, . 422 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 423 "Special-Purpose IP Address Registries", BCP 153, 424 RFC 6890, DOI 10.17487/RFC6890, April 2013, 425 . 427 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 428 Routable Cryptographic Hash Identifiers Version 2 429 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 430 2014, . 432 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 433 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 434 October 2016, . 436 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 437 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 438 October 2016, . 440 [WeakKeys] Heninger, N.H., Durumeric, Z.D., Wustrow, E.W., and J.A.H. 441 Halderman, "Detection of Widespread Weak Keys in Network 442 Devices", August 2012, 443 . 445 Appendix A. Calculating Collision Probabilities 447 The accepted formula for calculating the probability of a collision 448 is: 450 p = 1 - e^{-k^2/(2n)} 452 P Collision Probability 453 n Total possible population 454 k Actual population 456 Authors' Addresses 458 Robert Moskowitz 459 HTT Consulting 460 Oak Park, MI 48237 461 United States of America 463 Email: rgm@labs.htt-consult.com 465 Stuart W. Card 466 AX Enterprize 467 4947 Commercial Drive 468 Yorkville, NY 13495 469 United States of America 471 Email: stu.card@axenterprize.com 473 Adam Wiethuechter 474 AX Enterprize 475 4947 Commercial Drive 476 Yorkville, NY 13495 477 United States of America 479 Email: adam.wiethuechter@axenterprize.com