idnits 2.17.1 draft-ietf-regext-rdap-reverse-search-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 is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 October 2021) is 905 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDCC' ** Downref: Normative reference to an Informational RFC: RFC 6973 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Downref: Normative reference to an Informational RFC: RFC 8605 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions M. Loffredo 3 Internet-Draft M. Martinelli 4 Intended status: Standards Track IIT-CNR/Registro.it 5 Expires: 8 April 2022 5 October 2021 7 Registration Data Access Protocol (RDAP) Reverse search capabilities 8 draft-ietf-regext-rdap-reverse-search-07 10 Abstract 12 The Registration Data Access Protocol (RDAP) does not include query 13 capabilities to find the list of domains related to a set of entities 14 matching a given search pattern. In the RDAP context, an entity can 15 be associated to any defined object class. Therefore, a reverse 16 search can be applied to other use cases than the classic domain- 17 entity scenario. This document describes RDAP query extensions that 18 allow servers to provide a reverse search feature based on the 19 relationship between any searchable object and the related entities. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 8 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 56 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 4 57 3. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Implementation Considerations . . . . . . . . . . . . . . . . 6 59 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 60 5.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 10.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Paradigms to Enforce Access Control on Reverse Search 69 in RDAP . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Reverse Whois is a service provided by many web applications that 76 allow users to find domain names owned by an individual or a company 77 starting from the owner's details, such as name and email. Even if 78 it has been considered useful for some legal purposes (e.g. 79 uncovering trademark infringements, detecting cybercrime cases), its 80 availability as a standardized Whois capability has been objected for 81 two main reasons, which now don't seem to conflict with an RDAP 82 implementation. 84 The first objection has been caused by the potential risks of privacy 85 violation. However, TLDs community is considering a new generation 86 of Registration Directory Services [ICANN-RDS1] [ICANN-RDS2] 87 [ICANN-RA], which provide access to sensitive data under some 88 permissible purposes and according to adequate policies to enforce 89 the requestor accreditation, authentication, authorization, and terms 90 and conditions of data use. It is well known that such security 91 policies are not implemented in Whois [RFC3912], while they are in 92 RDAP [RFC7481]. Therefore, RDAP permits a reverse search 93 implementation complying with privacy protection principles. 95 Another objection to the implementation of a reverse search 96 capability has been connected with its impact on server processing. 97 Since RDAP supports search queries, the impact of both standard and 98 reverse searches is equivalent and can be mitigated by servers 99 adopting ad hoc strategies. Furthermore, the reverse search is 100 almost always performed by specifying an entity role (e.g. 101 registrant, technical contact) and this can contribute to restricting 102 the result set. 104 Reverse searches, such as finding the list of domain names associated 105 with contacts or nameservers may be useful to registrars as well. 106 Usually, registries adopt out-of-band solutions to provide results to 107 registrars asking for reverse searches on their domains. Possible 108 reasons for such requests are: 110 * the loss of synchronization between the registrar database and the 111 registry database; 112 * the need for such data to perform massive EPP [RFC5730] updates 113 (e.g. changing the contacts of a set of domains, etc.). 115 Currently, RDAP does not provide any way for a client to search for 116 the collection of domains associated with an entity [RFC9082]. A 117 query (lookup or search) on domains can return the array of entities 118 related to a domain with different roles (registrant, registrar, 119 administrative, technical, reseller, etc.), but the reverse operation 120 is not allowed. Only reverse searches to find the collection of 121 domains related to a nameserver (ldhName or ip) can be requested. 122 Since an entity can be in relationship with any RDAP object 123 [RFC9083], the availability of a reverse search can be common to all 124 resource type path segments defined for search. 126 The protocol described in this specification aims to extend the RDAP 127 query capabilities to enable the reverse search based on the 128 relationship between any object and the associated entities. The 129 extension is implemented by adding new path segments (i.e. search 130 paths) and using a RESTful web service [REST]. The service is 131 implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] 132 and the conventions described in [RFC7480]. 134 1.1. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 2. RDAP Path Segment Specification 144 The new search paths are OPTIONAL extensions of those defined in 145 [RFC9082]. A generic reverse search path is described by the syntax: 147 {resource-type}/reverse/{role}?{property}= 149 The path segments are defined as in the following: 151 * resource-type: it MUST be one of resource type path segments 152 defined in Section 3.2 of [RFC9082]: "domains", "nameservers" or 153 "entities"; 154 * role: it MUST be one of the roles described in Section 10.2.4 of 155 [RFC9083]. For role independent reverse searches, the value 156 "entity" MUST be used; 157 * property: it identifies the entity property to be used in matching 158 the search pattern. A pre-defined list of properties includes: 159 fn, handle, email, city, country, cc. The mapping between such 160 properties and the RDAP properties is shown in Table 1. Some of 161 the properties are related to jCard elements [RFC7095] but, being 162 jCard the JSON format for vCard [RFC6350], the corresponding 163 definitions are included in vCard specification. Servers MAY 164 implement additional properties to those defined in this document. 166 Partial string matching is allowed as defined in section 4.1 of 167 [RFC9082]. 169 +=========================+===============+==========+=======+======+ 170 | Reverse search property | RDAP property | RFC | RFC | RFC | 171 | | | 9083 | 6350 | 8605 | 172 +=========================+===============+==========+=======+======+ 173 | handle | handle | 5.1. | | | 174 +-------------------------+---------------+----------+-------+------+ 175 | fn | jCard fn | | 6.2.1 | | 176 +-------------------------+---------------+----------+-------+------+ 177 | email | jCard email | | 6.4.2 | | 178 +-------------------------+---------------+----------+-------+------+ 179 | city | locality in | | 6.3.1 | | 180 | | jCard adr | | | | 181 +-------------------------+---------------+----------+-------+------+ 182 | country | country name | | 6.3.1 | | 183 | | in jCard adr | | | | 184 +-------------------------+---------------+----------+-------+------+ 185 | cc | country code | | | 3.1 | 186 | | in jCard adr | | | | 187 +-------------------------+---------------+----------+-------+------+ 189 Table 1: Mapping between the reverse search properties and the 190 RDAP properties 192 https://example.com/rdap/domains/reverse/technical?handle=CID-40* 194 https://example.com/rdap/domains/reverse/registrant?fn=Bobby* 196 https://example.com/rdap/domains/reverse/registrant?cc=US 198 https://example.com/rdap/entites/reverse/registrar?handle=RegistrarX 200 Figure 1: Examples of reverse search queries 202 The "country" property can be used as an alternative to "cc" when 203 RDAP servers don't include the jCard "cc" parameter [RFC8605] in 204 their response. 206 3. RDAP Conformance 208 Servers complying with this specification MUST include the value 209 "reverse_search" in the rdapConformance property of the help response 210 [RFC9083]. The information needed to register this value in the 211 "RDAP Extensions" registry is described in Section 6. 213 4. Implementation Considerations 215 The implementation of the proposed extension is technically feasible. 216 Both handle and fn are used as standard path segments to search for 217 entities [RFC9082]. With regards to the other reverse search 218 properties, namely email, city and country code, the impact of their 219 usage on server processing is evaluated to be the same as other 220 existing query capabilities (e.g. wildcard prefixed search pattern) 221 so the risks to degrade the performance or to generate huge result 222 sets can be mitigated by adopting the same policies (e.g. restricting 223 the search functionality, limiting the rate of search requests 224 according to the user profile, truncating and paging the results, 225 returning partial responses). 227 5. Implementation Status 229 NOTE: Please remove this section and the reference to RFC 7942 prior 230 to publication as an RFC. 232 This section records the status of known implementations of the 233 protocol defined by this specification at the time of posting of this 234 Internet-Draft, and is based on a proposal described in [RFC7942]. 235 The description of implementations in this section is intended to 236 assist the IETF in its decision processes in progressing drafts to 237 RFCs. Please note that the listing of any individual implementation 238 here does not imply endorsement by the IETF. Furthermore, no effort 239 has been spent to verify the information presented here that was 240 supplied by IETF contributors. This is not intended as, and must not 241 be construed to be, a catalog of available implementations or their 242 features. Readers are advised to note that other implementations may 243 exist. 245 According to RFC 7942, "this will allow reviewers and working groups 246 to assign due consideration to documents that have the benefit of 247 running code, which may serve as evidence of valuable experimentation 248 and feedback that have made the implemented protocols more mature. 249 It is up to the individual working groups to use this information as 250 they see fit". 252 5.1. IIT-CNR/Registro.it 254 * Responsible Organization: Institute of Informatics and Telematics 255 of National Research Council (IIT-CNR)/Registro.it 256 * Location: https://rdap.pubtest.nic.it/ 257 * Description: This implementation includes support for RDAP queries 258 using data from the public test environment of .it ccTLD. 259 * Level of Maturity: This is an "alpha" test implementation. 261 * Coverage: This implementation includes all of the features 262 described in this specification. 263 * Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 265 6. IANA Considerations 267 IANA is requested to register the following value in the RDAP 268 Extensions Registry: 270 * Extension identifier: reverse_search 271 * Registry operator: Any 272 * Published specification: This document. 273 * Contact: IETF 274 * Intended usage: This extension describes reverse search query 275 patterns for RDAP. 277 7. Privacy Considerations 279 The use of the capability described in this document MUST be 280 compliant with the rules about privacy protection each RDAP provider 281 is subject to. Sensitive registration data MUST be protected and 282 accessible for permissible purposes only. This functionality SHOULD 283 be only accessible to authorized users and only for a specified use 284 case. 286 Already the request for this functionality could contain Personal 287 Identifiable Information and SHOULD therefore only be available over 288 HTTPS. 290 Providing reverse search in RDAP carries the following threats as 291 described in [RFC6973]: 293 * Correlation 294 * Disclosure 295 * Misuse of information 297 Therefore, RDAP providers are REQUIRED to mitigate the risk of those 298 threats by implementing appropriate measures supported by security 299 services (see Section 8). 301 8. Security Considerations 303 Security services required to provide controlled access to the 304 operations specified in this document are described in [RFC7481]. A 305 non exhaustive list of access control paradigms an RDAP provider can 306 implement is presented in Appendix A. 308 The specification of the entity role within the reverse search path 309 allows the RDAP servers to implement different authorization policies 310 on a per-role basis. 312 9. Acknowledgements 314 The authors would like to acknowledge the following individuals for 315 their contributions to this document: Tom Harrison, Scott Hollenbeck, 316 Francisco Arias, Gustavo Lozano, Eduardo Alvarez and Ulrich Wisser. 318 10. References 320 10.1. Normative References 322 [OIDCC] OpenID Foundation, "OpenID Connect Core incorporating 323 errata set 1", November 2014, 324 . 326 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 327 Requirement Levels", BCP 14, RFC 2119, 328 DOI 10.17487/RFC2119, March 1997, 329 . 331 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 332 DOI 10.17487/RFC3912, September 2004, 333 . 335 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 336 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 337 . 339 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 340 DOI 10.17487/RFC6350, August 2011, 341 . 343 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 344 Morris, J., Hansen, M., and R. Smith, "Privacy 345 Considerations for Internet Protocols", RFC 6973, 346 DOI 10.17487/RFC6973, July 2013, 347 . 349 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 350 DOI 10.17487/RFC7095, January 2014, 351 . 353 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 354 Protocol (HTTP/1.1): Message Syntax and Routing", 355 RFC 7230, DOI 10.17487/RFC7230, June 2014, 356 . 358 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 359 Registration Data Access Protocol (RDAP)", STD 95, 360 RFC 7480, DOI 10.17487/RFC7480, March 2015, 361 . 363 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 364 Registration Data Access Protocol (RDAP)", STD 95, 365 RFC 7481, DOI 10.17487/RFC7481, March 2015, 366 . 368 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 369 Code: The Implementation Status Section", BCP 205, 370 RFC 7942, DOI 10.17487/RFC7942, July 2016, 371 . 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 375 May 2017, . 377 [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: 378 ICANN Extensions for the Registration Data Access Protocol 379 (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, 380 . 382 [RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access 383 Protocol (RDAP) Query Format", STD 95, RFC 9082, 384 DOI 10.17487/RFC9082, June 2021, 385 . 387 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 388 Registration Data Access Protocol (RDAP)", STD 95, 389 RFC 9083, DOI 10.17487/RFC9083, June 2021, 390 . 392 10.2. Informative References 394 [draft-ietf-regext-rdap-openid] 395 Hollenbeck, S., "Federated Authentication for the 396 Registration Data Access Protocol (RDAP) using OpenID 397 Connect", . 400 [ICANN-RA] Internet Corporation For Assigned Names and Numbers, 401 "Registry Agreement", July 2017, 402 . 405 [ICANN-RDS1] 406 Internet Corporation For Assigned Names and Numbers, 407 "Final Report from the Expert Working Group on gTLD 408 Directory Services: A Next-Generation Registration 409 Directory Service (RDS)", June 2014, 410 . 413 [ICANN-RDS2] 414 Internet Corporation For Assigned Names and Numbers, 415 "Final Issue Report on a Next-Generation gTLD RDS to 416 Replace WHOIS", October 2015, 417 . 420 [REST] Fielding, R., "Architectural Styles and the Design of 421 Network-based Software Architectures", 2000, 422 . 425 Appendix A. Paradigms to Enforce Access Control on Reverse Search in 426 RDAP 428 Access control can be implemented according to different paradigms 429 introducing increasingly stringent rules. The paradigms reported 430 here in the following leverage the capabilities either supported 431 natively or provided as extensions by the OpenID Connect [OIDCC]: 433 * Role-Based Access Control: access rights are granted depending on 434 roles. Generally, this is done by grouping users into fixed 435 categories and assigning each category with static grants. A more 436 dynamic approach can be implemented by using the OpenID Connect 437 "scope" claim; 438 * Purpose-Based Access Control: access rules are based on the notion 439 of purpose which means the intended usage of some data by a user. 440 It can be implemented by tagging a request with the usage purpose 441 and making the RDAP server check the compliance between the given 442 purpose and the control rules applied to data to be returned. The 443 purpose can be stated within an out-of-band process by setting the 444 OpenID Connect RDAP specific "purpose" claim as defined in 445 [draft-ietf-regext-rdap-openid]; 447 * Attribute-Based Access Control: rules to manage access rights are 448 evaluated and applied according to specific attributes describing 449 the context within which data are requested. It can be 450 implemented by setting within an out-of-band process additional 451 OpenID Connect claims describing the request context and making 452 the RDAP server check the compliance between the given context and 453 the control rules applied to data to be returned; 454 * Time-Based Access Control: data access is allowed for limited time 455 only. It can be implemented by assigning the users with temporary 456 credentials linked to access grants whose scope is limited. 458 Appendix B. Change Log 460 00: Initial working group version ported from draft-loffredo-regext- 461 rdap-reverse-search-04 462 01: Updated "Privacy Considerations" section. 463 02: Revised the text. 464 03: Refactored the query model. 465 04: Keepalive refresh. 466 05: Reorganized "Abstract". Corrected "Conventions Used in This 467 Document" section. Added "RDAP Conformance" section. Changed 468 "IANA Considerations" section. Added references to RFC7095 and 469 RFC8174. Other minor edits. 470 06: Updated "Privacy Considerations", "Security Considerations" and 471 "Acknowledgements" sections. Added some normative and informative 472 references. Added Appendix A. 473 07: Updated normative refernces. 475 Authors' Addresses 477 Mario Loffredo 478 IIT-CNR/Registro.it 479 Via Moruzzi,1 480 56124 Pisa 481 Italy 483 Email: mario.loffredo@iit.cnr.it 484 URI: http://www.iit.cnr.it 486 Maurizio Martinelli 487 IIT-CNR/Registro.it 488 Via Moruzzi,1 489 56124 Pisa 490 Italy 492 Email: maurizio.martinelli@iit.cnr.it 493 URI: http://www.iit.cnr.it