idnits 2.17.1 draft-moskowitz-hip-hhit-registries-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 280 has weird spacing: '...rmation req...' -- The document date (9 March 2020) is 1510 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 276, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-hip-dex-13 == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-hierarchical-hit-04 Summary: 0 errors (**), 0 flaws (~~), 5 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: 10 September 2020 A. Wiethuechter 6 AX Enterprize 7 9 March 2020 9 Hierarchical HIT Registries 10 draft-moskowitz-hip-hhit-registries-02 12 Abstract 14 This document describes using the registration protocol and 15 registries to support hierarchical HITs (HHITs). New and existing 16 HIP parameters are used to communicate Registry Policies and data 17 about the HHIT device and the Registries. Further Registries are 18 expected to provide RVS services for registered HHIT devices. 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 10 September 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. Desire for administrative control of HHITs . . . . . . . 4 59 3.2. Desire for administrative control by RVS providers . . . 4 60 3.3. Defense against fraudulent HITs . . . . . . . . . . . . . 4 61 4. HHIT Registry services to support hierarchical HITs . . . . . 4 62 4.1. Hierarchical HIT Registration using X.509 Certificates . 5 63 4.2. Hierarchical HIT Registration using a PSK . . . . . . . . 5 64 4.3. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 5 65 4.3.1. CERT Parameter . . . . . . . . . . . . . . . . . . . 6 66 4.3.2. Hierarchical HIT Registration Type . . . . . . . . . 6 67 4.3.3. Hierarchical HIT Registration Failure Type . . . . . 6 68 4.3.4. CLIENT_INFO . . . . . . . . . . . . . . . . . . . . . 6 69 4.4. Registration failure behavior . . . . . . . . . . . . . . 7 70 4.4.1. Example of a simple HDA policy . . . . . . . . . . . 7 71 4.5. Example of a simple HDA policy . . . . . . . . . . . . . 7 72 4.6. HHIT DNS Retrieval Service . . . . . . . . . . . . . . . 8 73 5. Using hierarchical HITs . . . . . . . . . . . . . . . . . . . 8 74 5.1. Contacting a HIP client . . . . . . . . . . . . . . . . . 8 75 5.2. Defense against fraudulent HITs . . . . . . . . . . . . . 9 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 7. RAA Management Organization Considerations . . . . . . . . . 9 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8.1. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 10 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. Calculating Collision Probabilities . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 This document expands on Hierarchical HITs 90 [I-D.moskowitz-hip-hierarchical-hit], defining HIP registration 91 protocol enhancements, the Registry services to support hierarchical 92 HITs (HHITs), and given a HHIT, how to get additional information 93 about the device. 95 Registries will tend to be organized regionally and by nature of 96 their clients. For example, an RAA may be US centric and only have 97 HDAs that are US-based. 99 Registries will need to work in a federation. Devices that are 100 clients of one HDA/RAA will be needing information and connectivity 101 to devices that are clients of other HDA/RAA. The policies for 102 establishing such federations are outside the scope of this document. 104 Access to information at a Registry about a device may require 105 authorization. The nature and process of such an authorization is 106 outside the scope of this document. 108 2. Terms and Definitions 110 2.1. Requirements Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 2.2. Definitions 120 CSR (Certificate Signing Request): Request to a Certificate 121 Authority to create an X.509 certificate with the provided 122 information. 124 HDA (Hierarchical HIT Domain Authority): The 14 bit field 125 identifying the HIT Domain Authority under a RAA. 127 HID (Hierarchy ID): The 32 bit field providing the HIT Hierarchy ID. 129 RAA (Registered Assigning Authority): The 18 bit field identifying 130 the Hierarchical HIT Assigning Authority. 132 RVS (Rendezvous Server): The HIP Rendezvous Server for enabling 133 mobility, as defined in [RFC8004]. 135 3. Problem Space 136 3.1. Desire for administrative control of HHITs 138 For HHITs to be effectively used, the HHIT Domain Authorities (HDAs) 139 need to provide information on the HHIT devices. Minimally this 140 would be the corresponding HI, information on the device owner (only 141 to authorized requesters), and where in the network the device has 142 last reported from. 144 The HHIT space creates a type of a business labeling for the HDAs. 145 "These are my customers." 147 3.2. Desire for administrative control by RVS providers 149 An RVS [RFC8004] provider may only be willing to provide discovery 150 (RVS) services to HIP devices it knows and trusts. A flat HIT space 151 does not provide any intrinsic functionality to support this. A HHIT 152 space can be mapped to the RVS provider. DNS can effectively be used 153 to provide the HHIT to IP mapping without Distributed Hash 154 Table (DHT) [RFC6537]. 156 3.3. Defense against fraudulent HITs 158 How can a host protect against a fraudulent HIT? That is, a second 159 pre-image attack on the HI hash that produces the HIT. A strong 160 defense would require every HIT/HI registered and openly verifiable. 161 With HHITs, the HDAs can provide the HI and proof of registration 162 (e.g. X.509 certificate including HHIT). 164 This would best be done as either part of the R1 and I2 validation, 165 or anytime a HHIT is presented. 167 4. HHIT Registry services to support hierarchical HITs 169 Hierarchical HIT registration SHOULD be performed using the HIP 170 Registration Extension [RFC8003]. The client either uses an X.509 171 certificate [RFC8002], or use a PSK, as defined in Appendix A of HIP- 172 DEX [I-D.ietf-hip-dex], to validate the registration. 174 The Registration should include additional client information. This 175 information may be contained within the X.509 certificate (CERT 176 parameter) and/or is carried in the CLIENT_INFO parameter, see 177 Section 4.3.4. The Registrar can include its requirements in the R1 178 packet, and the client provide its information in the I2 packet. 179 This parameter may be encrypted within the ENCRYPTED parameter. If 180 the CLIENT_INFO contains Personal Identifying Information (PII), then 181 it MUST be placed into the ENCRYPTED parameter. 183 The content and internal format of the CLIENT_INFO parameter is set 184 by the HDA"s policy and is outside the scope of this document. 185 Examples of client information can by phone number, IMEI, and ICCID. 187 4.1. Hierarchical HIT Registration using X.509 Certificates 189 This requires the HIP client to possess a client certificate trusted 190 by the HDA/Registrar. Registration will either succeed or fail. 192 Certificate registration can be a "chicken and egg" problem: where 193 did the device get its certificate? Thus this is more likely used in 194 a re-registration situation with updated information. 196 4.2. Hierarchical HIT Registration using a PSK 198 This requires the HIP client and the HDA/Registrar to share a PSK. 199 The PSK is carried in the ENCRYPTED_KEY parameter [I-D.ietf-hip-dex]. 200 The PSK may already exist prior to starting the registration and just 201 be used within the registration. A PSK out-of-band exchange may be 202 triggered by performing the registration without any authentication. 204 If no client authentication is included in the I2 packet, the 205 registration fails with "No Authentication provided". If the I2 206 packet included the proper HDA required client information, the HDA 207 can use it to set up a side channel for an out-of-band delivery of a 208 PSK. And example of this would be to send an SMS message with the 209 PSK. Once the client possesses the PSK, it can rerun the 210 registration at which point the HI and HIT duplicate checks are 211 performed. 213 The I2 packet may contain a CERT parameter containing a CSR, and the 214 R2 would return the X.509 certificate for later use. 216 4.3. HIP Parameters 218 The HIP parameters carry information that is necessary for 219 establishing and maintaining a HIP association. For example, the 220 device's public keys as well as the signaling for negotiating ciphers 221 and payload handling are encapsulated in HIP parameters. Additional 222 information, meaningful for end hosts or middleboxes, may also be 223 included in HIP parameters. The specification of the HIP parameters 224 and their mapping to HIP packets and packet types is flexible to 225 allow HIP extensions to define new parameters and new protocol 226 behavior. 228 4.3.1. CERT Parameter 230 The CERT parameter, [RFC8002], is a container for certain types of 231 digital certificates. 233 A new CERT Type, CSR, is defined here. When CERT Type is CSR, CERT 234 ID is Zero. There is only ONE CSR in a CERT Parameter. 236 CERT format Type number RFC 237 ------------- ----------- ---- 238 PKCS#10 - CSR 9 2986 240 4.3.2. Hierarchical HIT Registration Type 242 The Registration Type used in the REG_REQUEST is: 244 Number Registration Type 245 ------ ----------------- 246 2 HHIT Registration 248 4.3.3. Hierarchical HIT Registration Failure Type 250 The Registration may fail. In fact, with PSK, this may be the 251 response to expect an SMS message with the PSK to use in a second 252 registration request. Failure Types used in the REG_FAIL are: 254 Failure Type Reason 255 ------------ ----------------------- 256 [TBD-IANA] Hierarchical HIT Already Registered 257 [TBD-IANA] HI Already Registered 258 [TBD-IANA] Previously Registered HI with different 259 device information 260 [TBD-IANA] No Authentication provided 261 [TBD-IANA] Invalid Authentication 262 [TBD-IANA] Invalid Authentication, new PSK sent via SMS 264 4.3.4. CLIENT_INFO 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 / Client Information / 271 / / 272 / +-------------------------------+ 273 / | Padding | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Type [TBD-IANA] 277 Length length in octets, excluding Type, Length, and 278 Padding 279 Client The information required by the HDA in the format 280 Information required by the HDA. 282 This parameter contains client information to include in the HIT 283 registration. The specific content and format is set by the HDA. 285 4.4. Registration failure behavior 287 If the failure type is "Hierarchical HIT Already Registered", the 288 client's HI is hashing to an existing HIT and must generate a new HI 289 and hierarchical HIT and re-register. If the failure is "HI Already 290 Registered", the client should assume it is registered. If the 291 failure is "Previously Registered HI with different device 292 information", either the client managed to generate a duplicate HI, 293 possibly indicating a weak key generation algorithm, or the client 294 was previously registered on a different device. Resolving this 295 conflict will be left to the HDA's policy. 297 4.4.1. Example of a simple HDA policy 299 A simple HDA policy would be to require the device to generate a new 300 HI and thus HHIT and try registration again. The HDA policy may also 301 provide a URL for "Previous Registration Resolution". This contact 302 is primarily to assist a device that was registered, but had some 303 local failure resulting in a new registration attempt. 305 4.5. Example of a simple HDA policy 307 A simple HDA policy would be to require the device to generate a new 308 HI and thus HHIT and try registration again. The HDA policy may also 309 provide a URL for "Previous Registration Resolution". This contact 310 is primarily to assist a device that was registered, but had some 311 local failure resulting in a new registration attempt. 313 4.6. HHIT DNS Retrieval Service 315 A Registry SHOULD provide DNS retrieval services for the HIP RR 316 [RFC8005] for HHITs as described in Hierarchical HITs 317 [I-D.moskowitz-hip-hierarchical-hit]. 319 This requires a Registry to act as a DNS zone Name Server to provide 320 minimally the HI for the HHIT in the DNS query. Registry policy will 321 determine if the response can be cached within DNS. If the Registry 322 also provides the HHIT and/or the RVS for the HHIT, this may result 323 in a different DNS caching policy by the Registry. 325 5. Using hierarchical HITs 327 All HIP clients with hierarchical HITs maintain an RVS connection 328 with their HDA's RVS server(s). How the HDA scales this service up 329 to a potential population in the millions is out of scope of this 330 document. Lifetime management of these connections is also out of 331 scope. 333 One approach an HDA can use to address the scaling challenge is to 334 add an internal level of hierarchy to assign a set number of devices 335 per RVS server. 337 Peering agreements between HDAs would allow for geographically close 338 RVS to a device. This may reduce the latency for use of a device's 339 current RVS. This is a subject of another document. 341 5.1. Contacting a HIP client 343 A service Initiator uses some service to discover the HIT of the 344 service Responder. The Initiator uses the hierarchical information 345 in the HIT to find the Responder's RVS. A trusted RVS discover 346 method could use the DNS PTR to RVS as shown in Hierarchical HITs 347 [I-D.moskowitz-hip-hierarchical-hit]. An I1 is sent to that RVS 348 which forwards it to the Responder. 350 The potential Responder uses the HIT in the I1 to query the 351 Initiator's RVS about the Initiator. The nature of information, and 352 method of communication are determined by the Initiator's HDA and the 353 Responder's (and or HDA"s) relationship with it. Based on the 354 Responder's local policy, this information will be used to determine 355 if the contact is to be accepted. If accepted, the Responder may 356 proceed sending an R1 to the Initiator. It may alternatively 357 initiate some non-HIP process. 359 It should be noted that this R1 may contain a REG_INFO list for the 360 Initiator to validate that the Responder does offer the desired 361 service. 363 5.2. Defense against fraudulent HITs 365 Both the Initiator and Responder MAY validate a peer host as a 366 defense against a second pre-image attack on the HHIT. This may 367 occur via a CERT [RFC8002] in R1 or I2. It may be through a back end 368 process associated with the R1 or I2 validation to look up the HHIT 369 and retrieve the registered HI. 371 6. IANA Considerations 373 IANA will need to make the following changes to the "Host Identity 374 Protocol (HIP) Parameters" registries: 376 CERT Type: This document defines the new CERT Type for the CERT 377 parameter "PKCS#10 - CSR" (see Section 4.3.1). 379 Reg Type: This document defines the new Registration Type for the 380 REG_REQUEST parameter "HIT Registration" (see Section 4.3.2). 382 Reg Fail: This document defines the new Failure Types for the 383 REG_FAIL parameter (see Section 4.3.3). 385 CLIENT_INFO: This document defines the new CLIENT_INFO parameter 386 (see Section 4.3.4). The parameter value will be assigned by 387 IANA. 389 7. RAA Management Organization Considerations 391 Introducing the RAA management organization may be the largest hurdle 392 for hierarchical HITs. Thus it would be best if this were adopted by 393 an organization already in the business of allocating numbers within 394 either the Internet or the Mobile, cellular, infrastructure. 396 One consideration would be to reserve the first N RAA values to map 397 to the existing DNS TLDs. For example, these TLDs can be organized 398 in an ascending order and numbered accordingly. Thus the 2 character 399 TLDs will be a lower number than the 3 character TLDs. After that, 400 it could be a first come, first numbered assignment process. 402 8. Security Considerations 404 There are potential risks with the hierarchical HIT, the Registry 405 service, and the discovery of potential peer hosts using its 406 hierarchical HIT. 408 A 64 bit hash space presents a real risk of second pre-image attacks. 409 The HHIT Registry services effectively block attempts to "take over" 410 a HHIT. It does not stop a rogue attempting to impersonate a known 411 HHIT. This attack can be mitigated by the Responder using DNS to 412 find the HI for the HHIT or the RVS for the HHIT that then provides 413 the registered HI. 415 The two risks with hierarchical HITs are the use of an invalid HID 416 and forced HIT collisions. The use of the "hhit.arpa." DNS zone is 417 a strong protection against invalid HIDs. Querying an HDA's RVS for 418 a HIT under the HDA protects against talking to unregistered clients. 419 The Registry service has direct protection against forced or 420 accidental HIT hash collisions. 422 By using the HIP Registration Extension, the Registry service is 423 protected from direct attacks. This service does rely on either the 424 integrity of a PKI service or an out-of-band PSK delivery process. 425 Thus the risk to the Registry service is highly related to the trust 426 in these authentication setup services. Further, the duplicate HI 427 resolution process may require human interaction with related social 428 engineering risks. 430 Finally the peer host discovery process relies on trusting the 431 finding the proper HDA for the host and its forwarding the I1 to the 432 proper Responder. A rogue RVS, impersonating the RVS for the HIT, 433 could redirect the I1 to a client that has forced a collision with 434 the HIT and the Initiator would be none the wiser. The only defense 435 against this is if the Initiator has some other source for the 436 Responder HI and validate the HI in the R1. 438 8.1. Privacy Concerns 440 Mobile-privacy-attack [I-D.moskowitz-mobile-privacy-attack] details 441 how Eve can follow a communication between two mobile peers using the 442 session Identifiers and deep knowledge about those Identifiers gained 443 by hacking servers that log PII related to the Identifiers. 445 Hierarchical HITs not only does not mitigate this attack, it can 446 actually aggravate it by supplying the HDA where the HHIT is 447 registered. 449 A HIP Privacy Enhanced Base Exchange, to be defined in a separate 450 draft, along with a Privacy Enhanced ESP tunnel, can be used to hide 451 all the HIP and ESP Identifiers from Eve. 453 9. Acknowledgments 455 Sue Hares of Huawei contributed to the clarity in this document. 457 10. References 459 10.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 467 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 468 May 2017, . 470 10.2. Informative References 472 [I-D.ietf-hip-dex] 473 Moskowitz, R., Hummen, R., and M. Komu, "HIP Diet EXchange 474 (DEX)", Work in Progress, Internet-Draft, draft-ietf-hip- 475 dex-13, 14 February 2020, 476 . 478 [I-D.moskowitz-hip-hierarchical-hit] 479 Moskowitz, R., Card, S., and A. Wiethuechter, 480 "Hierarchical HITs for HIPv2", Work in Progress, Internet- 481 Draft, draft-moskowitz-hip-hierarchical-hit-04, 3 March 482 2020, . 485 [I-D.moskowitz-mobile-privacy-attack] 486 Moskowitz, R., "An Attack on Privacy in Mobile Devices", 487 Work in Progress, Internet-Draft, draft-moskowitz-mobile- 488 privacy-attack-01, 13 November 2017, 489 . 492 [RFC6537] Ahrenholz, J., "Host Identity Protocol Distributed Hash 493 Table Interface", RFC 6537, DOI 10.17487/RFC6537, February 494 2012, . 496 [RFC8002] Heer, T. and S. Varjonen, "Host Identity Protocol 497 Certificates", RFC 8002, DOI 10.17487/RFC8002, October 498 2016, . 500 [RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 501 Registration Extension", RFC 8003, DOI 10.17487/RFC8003, 502 October 2016, . 504 [RFC8004] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 505 Rendezvous Extension", RFC 8004, DOI 10.17487/RFC8004, 506 October 2016, . 508 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 509 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 510 October 2016, . 512 Appendix A. Calculating Collision Probabilities 514 The accepted formula for calculating the probability of a collision 515 is: 517 p = 1 - e^{-k^2/(2n)} 519 P Collision Probability 520 n Total possible population 521 k Actual population 523 Authors' Addresses 525 Robert Moskowitz 526 HTT Consulting 527 Oak Park, MI 48237 528 United States of America 530 Email: rgm@labs.htt-consult.com 532 Stuart W. Card 533 AX Enterprize 534 4947 Commercial Drive 535 Yorkville, NY 13495 536 United States of America 538 Email: stu.card@axenterprize.com 540 Adam Wiethuechter 541 AX Enterprize 542 4947 Commercial Drive 543 Yorkville, NY 13495 544 United States of America 546 Email: adam.wiethuechter@axenterprize.com