idnits 2.17.1 draft-moskowitz-hierarchical-hip-00.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 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 275 has weird spacing: '...rmation req...' -- The document date (August 3, 2016) is 2816 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) == Missing Reference: 'TBD-IANA' is mentioned on line 343, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-03 == Outdated reference: A later version (-11) exists of draft-ietf-hip-rfc5203-bis-10 == Outdated reference: A later version (-08) exists of draft-ietf-hip-rfc5204-bis-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP R. Moskowitz 3 Internet-Draft X. Xu 4 Intended status: Standards Track Huawei 5 Expires: February 4, 2017 August 3, 2016 7 Hierarchical HITs for HIPv2 8 draft-moskowitz-hierarchical-hip-00.txt 10 Abstract 12 This document describes using a hierarchical HIT to facilitate large 13 deployments in mobile networks. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 4, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 52 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Managing a large flat address space . . . . . . . . . . . 3 55 3.2. Desire for administrative control by RVS providers . . . 3 56 4. The Hierarchical Host Identity Tag (HIT) . . . . . . . . . . 3 57 4.1. The Hierarchy ID (HID) . . . . . . . . . . . . . . . . . 4 58 4.1.1. The Registered Assigning Authority (RAA) . . . . . . 4 59 4.1.2. The Hierarchical HIT Domain Authority (HDA) . . . . . 4 60 4.1.3. Example of the HID DNS . . . . . . . . . . . . . . . 5 61 4.1.4. Changes to ORCHIDv2 to support Hierarchical HITs . . 5 62 4.1.5. Collision risks with Hierarchical HITs . . . . . . . 5 63 5. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. CLIENT_INFO . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. HIT Registry services to support hierarchical HITs . . . . . 7 67 6.1. Hierarchical HIT Registration using X.509 Certificates . 7 68 6.2. Hierarchical HIT Registration using a PSK . . . . . . . . 7 69 6.3. Hierarchical HIT Registration Type . . . . . . . . . . . 7 70 6.4. Hierarchical HIT Registration Failure Type . . . . . . . 8 71 6.5. Registration failure behavior . . . . . . . . . . . . . . 8 72 7. Using hierarchical HITs . . . . . . . . . . . . . . . . . . . 8 73 7.1. Contacting a HIP client . . . . . . . . . . . . . . . . . 8 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 9. RAA Management Organization Considerations . . . . . . . . . 9 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Calculating Collision Probabilities . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 This document expands on HIPv2 [RFC7401] to describe the structure of 86 a hierarchical HIT, the Registry services to support this hierarchy, 87 and given a hierarchical HIT, how a peer is found in the network. 89 A separate document will further expand on the registry service and 90 how a device can advertise its availability and services provided. 92 2. Terms and Definitions 94 2.1. Requirements Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2.2. Definitions 102 HDA (Hierarchical HIT Domain Authority): The 14 bit field 103 identifying the HIT Domain Authority under a RAA. 105 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 107 RAA (Registered Assigning Authority): The 18 bit field identifying 108 the Hierarchical HIT Assigning Authority. 110 3. Problem Space 112 3.1. Managing a large flat address space 114 For HIP to be successfully used in mobile networks, it must support 115 an Identity per person, or upwards to 10 billion Identities. Perhaps 116 a Distributed Hash Table [I-D.irtf-hiprg-dht] can scale this large. 117 There is still the operational challenges in establishing such a 118 world-wide DHT implementation and how RVS [I-D.ietf-hip-rfc5204-bis] 119 works with such a large population. 121 Even though the probability of collisions with 7B HITs in a 96 bit 122 flat address space is 3.9E-10, it is still real. How are collisions 123 managed? It is also possible with weak key uniqueness, as has been 124 shown in deployed TLS certificates, results in a much greater 125 probability of collisions. Thus resolution of collisions needs to be 126 a feature in a globally mobile network. 128 3.2. Desire for administrative control by RVS providers 130 An RVS provider may only what to provide discovery services to HIP 131 clients it knows and trusts. A flat HIT space does not provide any 132 intrinsic functionality to support this. A hierarchical HIT space 133 can be mapped to the RVS provider. 135 4. The Hierarchical Host Identity Tag (HIT) 137 The Hierarchical HIT is a small but important enhancement over the 138 flat HIT space. It represents the HI in only a 64 bit hash and uses 139 the other 32 bits to create a hierarchical administration 140 organization for HIT domains. Hierarchical HITs are ORCHIDs 141 [RFC7343]. The change in construction rules are in Section 4.1.4. 143 A Hierarchical HIT is built from the following fields: 145 o 28 bit IANA prefix 147 o 4 bit HIT Suite ID 149 o 32 bit Hierarchy ID (HID) 151 o 64 bit ORCHID hash 153 4.1. The Hierarchy ID (HID) 155 The Hierarchy ID (HID) provides the structure to organize HITs into 156 administrative domains. HIDs are further divided into 2 fields: 158 o 14 bit Registered Assigning Authority (RAA) 160 o 18 bit Hierarchical HIT Domain Authority (HDA) 162 4.1.1. The Registered Assigning Authority (RAA) 164 The RAA is a 14 bit field (16,384 RAAs) assigned sequentially by a 165 numbers management organization, perhaps ICANN. An RAA must provide 166 a set of services to allocate HDAs to organizations. It must have a 167 public policy on what is necessary to obtain an HDA. The RAA need 168 not maintain any HIP related services. It must maintain a DNS zone 169 for discovering HID RVS servers. 171 This DNS zone may be a reverse PTR for its RAA. Assume that the RAA 172 is 100. The PTR record is constructed at a 2 bit grouping: 174 1.3.1.0.0.0.0.arpa IN PTR raa.bar.com. 176 4.1.2. The Hierarchical HIT Domain Authority (HDA) 178 The HDA is an 18 bit field (262,144 HDAs per RAA) assigned 179 sequentially by an RAA. An HDA should maintain a set of RVS servers 180 that its client HIP-enabled customers use. How this is done and 181 scales to the potentially millions of customers is outside the scope 182 of this document. This service should be discoverable through the 183 DNS zone maintained by the HDA's RAA. 185 An RAA may assign a block of values to an individual organization. 186 This is completely up to the individual RAA's published policy for 187 delegation. 189 4.1.3. Example of the HID DNS 191 HID related services should be discoverable via DNS. For example the 192 RVS for a HID could be found via the following. Assume that the RAA 193 is 100 and the HDA is 50. The PTR record is constructed at a 2 bit 194 grouping: 196 2.0.3.0.0.0.0.0.0.1.3.1.0.0.0.0.arpa IN PTR rvs.foo.com. 198 4.1.4. Changes to ORCHIDv2 to support Hierarchical HITs 200 ORCHIDv2 has a number of inputs including a context, some header 201 bits, the hash algorithm, and the public key. The output is a 96 bit 202 value. Hierarchical HIT makes the following changes. The HID is 203 added as part of the header bits and the output is a 64 bit value, 204 derived the same way as the 96 bit hash. 206 Hierarchical HIT uses the same context as all other HIPv2 HIT Suites 207 as they are clearly separated by the distinct HIT Suite ID. 209 4.1.5. Collision risks with Hierarchical HITs 211 The 64 bit hash size does have an increased risk of collisions over 212 the 96 bit hash size used for the other HIT Suites. There is a 0.01% 213 probability of a collision in a population of 66 million. The 214 probability goes up to 1% for a population of 663 million. See 215 Appendix A for the collision probability formula. 217 This risk, however, is within a single HDA. Further, all HDAs are 218 expected to provide a registration process for reverse lookup 219 validation. This registration process would reject a collision, 220 forcing the client to generate a new HI and thus hierarchical HIT and 221 reapplying to the registration process. 223 5. HIP Parameters 225 The HIP parameters carry information that is necessary for 226 establishing and maintaining a HIP association. For example, the 227 peer's public keys as well as the signaling for negotiating ciphers 228 and payload handling are encapsulated in HIP parameters. Additional 229 information, meaningful for end hosts or middleboxes, may also be 230 included in HIP parameters. The specification of the HIP parameters 231 and their mapping to HIP packets and packet types is flexible to 232 allow HIP extensions to define new parameters and new protocol 233 behavior. 235 5.1. HIT_SUITE_LIST 237 The HIT_SUITE_LIST parameter contains a list of the supported HIT 238 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 239 Initiator can determine which source HIT Suite IDs are supported by 240 the Responder. The HIT_SUITE_LIST parameter is defined in 241 Section 5.2.10 of [RFC7401]. 243 The following HIT Suite IDs are defined for Hierarchical HITs, and 244 the relationship between the four-bit ID value used in the OGA ID 245 field and the eight-bit encoding within the HIT_SUITE_LIST ID field 246 is clarified: 248 HIT Suite Four-bit ID Eight-bit encoding 250 ECDSA/hier/SHA-256 4 0x40 252 Note that the Hierarchical HIP HIT Suite ID allows the peers to use 253 the hierarchical RVS discovery and authentication services to 254 validate the peer and discover available services. The Responder 255 SHOULD respond with a HIP hierarchical HIT suite ID when the HIT of 256 the Initiator is a HIP hierarchical HIT. 258 5.2. CLIENT_INFO 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 / Client Information / 266 / / 267 / +-------------------------------+ 268 / | Padding | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Type [TBD-IANA] 272 Length length in octets, excluding Type, Length, and 273 Padding 274 Client The information required by the HDA in the format 275 Information required by the HDA. 277 This parameter contains client information to include in the HIT 278 registration. The specific content and format is set by the HDA. 280 6. HIT Registry services to support hierarchical HITs 282 Hierarchical HIT registration SHOULD be performed using the HIP 283 Registration Extension [I-D.ietf-hip-rfc5203-bis]. The client either 284 uses an X.509 certificate [I-D.ietf-hip-rfc6253-bis], or use a PSK, 285 as defined in Appendix A of HIP-DEX [I-D.ietf-hip-dex], to validate 286 the registration. 288 The Registration should include additional client information. This 289 information may be contained within the X.509 certificate and/or is 290 carried in the CLIENT_INFO parameter, see Section 5.2. The Registrar 291 can include its requirements in the R1 packet, and the client provide 292 its information in the I2 packet. This parameter may be encrypted 293 within the ENCRYPTED parameter. If the CLIENT_INFO contains Personal 294 Identifying Information (PII), then it MUST be placed into the 295 ENCRYPTED parameter. 297 The content and internal format of the CLIENT_INFO parameter is set 298 by the HDA's policy and is outside the scope of this document. 299 Examples of client information can by phone number, IMEI, and ICCID. 301 6.1. Hierarchical HIT Registration using X.509 Certificates 303 This requires the HIP client to possess a client certificate trusted 304 by the HDA/Registrar. Registration will either succeed or fail. 306 6.2. Hierarchical HIT Registration using a PSK 308 This requires the HIP client and the HDA/Registrar to share a PSK. 309 The PSK may already exist prior to starting the registration and just 310 be used within the registration. A PSK out-of-band exchange may be 311 triggered by performing the registration without any authentication. 313 If no client authentication is included in the I2 packet, the 314 registration fails with "No Authentication provided". If the I2 315 packet included the proper HDA required client information, the HDA 316 can use it to set up a side channel for an out-of-band delivery of a 317 PSK. And example of this would be to send an SMS message with the 318 PSK. Once the client possesses the PSK, it can rerun the 319 registration at which point the HI and HIT duplicate checks are 320 performed. 322 6.3. Hierarchical HIT Registration Type 324 The Registration Type used in the REG_REQUEST is: 326 Number Registration Type 327 ------ ----------------- 328 2 HIT Registration 330 6.4. Hierarchical HIT Registration Failure Type 332 The Registration may fail. In fact, with PSK, this may be the 333 response to expect an SMS message with the PSK to use in a second 334 registration request. Failure Types used in the REG_FAIL are: 336 Failure Type Reason 337 ------------ ----------------------- 338 [TBD-IANA] Hierarchical HIT Already Registered 339 [TBD-IANA] HI Already Registered 340 [TBD-IANA] Previously Registered HI with different device information 341 [TBD-IANA] No Authentication provided 342 [TBD-IANA] Invalid Authentication 343 [TBD-IANA] Invalid Authentication, new PSK sent via SMS 345 6.5. Registration failure behavior 347 If the failure type is "Hierarchical HIT Already Registered", the 348 client's HI is hashing to an existing HIT and must generate a new HI 349 and hierarchical HIT and reregister. If the failure is "HI Already 350 Registered", the client should assume it is registered. If the 351 failure is "Previously Registered HI with different device 352 information", either the client managed to generate a duplicate HI, 353 probably indicating a weak key generation algorithm, or the client 354 was previously registered on a different device. Resolving this 355 conflict will be left to the HDA's policy. 357 7. Using hierarchical HITs 359 All HIP clients with hierarchical HITs maintain an RVS connection 360 with their HDA's RVS server(s). How the HDA scales this service up 361 to a potential population in the millions is out of scope of this 362 document. Lifetime management of these connections is also out of 363 scope. 365 7.1. Contacting a HIP client 367 A service Initiator uses some service to discover the HIT of the 368 service Responder. The Initiator uses the hierarchical information 369 in the HIT to find the Responder's RVS. An I1 is sent to that RVS 370 which forwards it to the Responder. 372 The potential Responder uses the HIT in the I1 to query the 373 Initiator's RVS about the Initiator. The nature of information, and 374 method of communication are determined by the Initiator's HDA and the 375 Responder's (and or HDA's) relationship with it. Based on the 376 Responder's local policy, this information will be used to determine 377 if the contact is to be accepted. If accepted, the Responder may 378 proceed sending an R1 to the Initiator. It may alternatively 379 initiate some non-HIP process. 381 It should be noted that this R1 may contain a REG_INFO list for the 382 Initiator to validate that the Responder does offer the desired 383 service. 385 8. IANA Considerations 387 The following change to the "Host Identity Protocol (HIP) Parameters" 388 registries has been made: 390 HIT Suite ID: This document defines the new HIT Suite "Hierarchy 391 with ECDSA/SHA256" (see Section 5.1). 393 CLIENT_INFO: This document defines the new CLIENT_INFO parameter 394 (see Section 5.2). The parameter value will be assigned by IANA. 396 Reg Type: This document defines the new Registration Type for the 397 REG_REQUEST parameter "HIT Registration" (see Section 6.3). 399 Reg Fail: This document defines the new Failure Types for the 400 REG_FAIL parameter (see Section 6.4). 402 9. RAA Management Organization Considerations 404 Introducing the RAA management organization may be the largest hurdle 405 for hierarchical HITs. Thus it would be best if this were adopted by 406 an organization already in the business of allocating numbers within 407 either the Internet or the Mobile, cellular, infrastructure. 409 One consideration would be to reserve the first N RAA values to map 410 to the existing DNS TLDs. For example, these TLDs can be organized 411 in an ascending order and numbered accordingly. Thus the 2 character 412 TLDs will be a lower number than the 3 character TLDs. After that, 413 it could be a first come, first numbered assignment process. 415 10. Security Considerations 417 There are potential risks with the hierarchical HIT, the Registry 418 service, and the discovery of potential peer using its hierarchical 419 HIT. 421 The two risks with hierarchical HITs is the use of an invalid HID and 422 forced HIT collisions. Use of the hhit.arpa. DNS zone is a strong 423 protection against invalid HIDs. Querying an HDA's RVS for a HIT 424 under the HDA protects against talking to unregistered clients. The 425 Registry service has direct protection against forced or accidental 426 HIT hash collisions. 428 By using the HIP Registration Extension, the Registry service is 429 protected from direct attacks. This service does rely on either the 430 integrity of a PKI service or an out-of-band PSK delivery process. 431 Thus the risk to the Registry service is highly related to the trust 432 in these authentication setup services. Further, the duplicate HI 433 resolution process may require human interaction with related social 434 engineering risks. 436 Finally the peer discovery process relies on trusting the finding the 437 proper HDA for the peer and its forwarding the I1 to the proper 438 Responder. A rogue RVS, impersonating the RVS for the HIT, could 439 redirect the I1 to a client that has forced a collision with the HIT 440 and the Initiator would be none the wiser. The only defense against 441 this is if the Initiator has some other source for the Responder HI 442 and validate the HI in the R1. 444 11. References 446 11.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 11.2. Informative References 455 [I-D.ietf-hip-dex] 456 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 457 draft-ietf-hip-dex-03 (work in progress), June 2016. 459 [I-D.ietf-hip-rfc5203-bis] 460 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 461 Registration Extension", draft-ietf-hip-rfc5203-bis-10 462 (work in progress), January 2016. 464 [I-D.ietf-hip-rfc5204-bis] 465 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 466 Rendezvous Extension", draft-ietf-hip-rfc5204-bis-07 (work 467 in progress), December 2015. 469 [I-D.ietf-hip-rfc6253-bis] 470 Heer, T. and S. Varjonen, "Host Identity Protocol 471 Certificates", draft-ietf-hip-rfc6253-bis-09 (work in 472 progress), July 2016. 474 [I-D.irtf-hiprg-dht] 475 Ahrenholz, J., "Host Identity Protocol Distributed Hash 476 Table Interface", draft-irtf-hiprg-dht-05 (work in 477 progress), December 2011. 479 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 480 Routable Cryptographic Hash Identifiers Version 2 481 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 482 2014, . 484 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 485 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 486 RFC 7401, DOI 10.17487/RFC7401, April 2015, 487 . 489 Appendix A. Calculating Collision Probabilities 491 The accepted formula for calculating the probability of a collision 492 is: 494 p = 1 - e^{-k^2/(2n)} 496 P Collision Probability 497 n Total possible population 498 k Actual population 500 Authors' Addresses 502 Robert Moskowitz 503 Huawei 504 Oak Park, MI 48237 505 USA 507 Email: rgm@htt-consult.com 508 Xiaohu Xu 509 Huawei 510 Huawei Bld, No.156 Beiqing Rd. 511 Beijing, Hai-Dian District 100095 512 China 514 Email: xuxiaohu@huawei.com