RDAP Deployment Findings and Update
draft-blanchet-regext-rdap-deployfindings-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Marc Blanchet | ||
Last updated | 2019-06-04 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-blanchet-regext-rdap-deployfindings-01
Network Working Group M. Blanchet Internet-Draft Viagenie Intended status: Informational June 4, 2019 Expires: December 6, 2019 RDAP Deployment Findings and Update draft-blanchet-regext-rdap-deployfindings-01 Abstract Registration Access Data Protocol(RDAP) is being deployed in domain and IP address registries. This document describes issues and findings while interfacing with the known server implementations and deployments. It also provides recommendations for the specifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Blanchet Expires December 6, 2019 [Page 1] Internet-Draft RDAP Deployment Findings and Update June 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IANA RDAP Registries Related Issues . . . . . . . . . . . . . 2 2.1. Values not Registered or Similar . . . . . . . . . . . . 3 2.2. RDAP Extensions not Registered . . . . . . . . . . . . . 4 3. RDAP Responses . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Cross-origin resource sharing(CORS) . . . . . . . . . . . 5 3.2. Object Class Name empty . . . . . . . . . . . . . . . . . 5 3.3. Links Relation Values . . . . . . . . . . . . . . . . . . 5 3.4. Related link pointing to self causes infinite loop . . . 6 3.5. Registrant Entity Too Deep . . . . . . . . . . . . . . . 7 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. URL encoding of : . . . . . . . . . . . . . . . . . . . . 8 5. Domain Registrar RDAP Server Location . . . . . . . . . . . . 8 6. Issues related to RFC7482 . . . . . . . . . . . . . . . . . . 8 6.1. Search patterns that are not . . . . . . . . . . . . . . 8 7. IANA RDAP Bootstrap Registries Related Issues . . . . . . . . 9 7.1. Missing Trailing Char in Bootstrap Registries . . . . . . 9 7.2. Single target value . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction While developing various tools and software related to RDAP, issues have been found and are documented below. This document should help in writing future version of the specifications and provide better conformant deployment. It is split in various sections based on where the fix should be applied. Obviously, there are different levels of severity of the issues, including nits or very minor. The actual instances and organisations running the RDAP servers where the issues were found are not listed. 2. IANA RDAP Registries Related Issues This section describes issues related to the IANA non-Bootstrap registries as specified in [RFC7483]. Blanchet Expires December 6, 2019 [Page 2] Internet-Draft RDAP Deployment Findings and Update June 2019 2.1. Values not Registered or Similar The IANA RDAP JSON Values registry [1] contains various values expected in JSON responses. The following table shows values not registered in the registry but seen in the field. The second column shows the possible corresponding values already registered. Recommendation: implementations should replace their custom values with the registered ones, when one exist. Implementors should register their values when there is no corresponding registered one. Remarks Type +---------------------------------+---------------------------------+ | Unregistered Values | Possibly Corresponding | | | Registered Values | +---------------------------------+---------------------------------+ | object truncated due to server | object truncated due to | | policy | authorization | | Response truncated due to | object truncated due to | | authorization | authorization | | Object truncated due to | object truncated due to | | authorization | authorization | | object redacted due to | object truncated due to | | authorization | authorization | +---------------------------------+---------------------------------+ Event Action +-----------------------------+-------------------------------------+ | Unregistered Values | Possibly Corresponding Registered | | | Values | +-----------------------------+-------------------------------------+ | delegation check | | | last correct delegation | | | check | | | last update | last changed | +-----------------------------+-------------------------------------+ Blanchet Expires December 6, 2019 [Page 3] Internet-Draft RDAP Deployment Findings and Update June 2019 Status Value +--------------------------+----------------------------------------+ | Unregistered Values | Possibly Corresponding Registered | | | Values | +--------------------------+----------------------------------------+ | server deleted | server delete prohibited | | prohibited | | | ok | active | +--------------------------+----------------------------------------+ Role Value +---------------------+------------------------------------------+ | Unregistered Values | Possibly Corresponding Registered Values | +---------------------+------------------------------------------+ | owner | registrant | +---------------------+------------------------------------------+ 2.2. RDAP Extensions not Registered The IANA RDAP Extensions registry [2] contains various extensions values expected in RDAP JSON responses in the rdapCconformance member. The following table shows values not registered in the registry but seen in the field. The second column shows the possible corresponding values already registered. Recommendation: implementations should replace their custom values with the registered ones, when one exist. Implementors should register their values when there is no corresponding registered one. +---------------------------------------------+---------------------+ | Unregistered Values | Possibly | | | Corresponding | | | Registered Values | +---------------------------------------------+---------------------+ | rdap_objectTag_level_0 | rdap_objectTag | | rdap_openidc_level_0 | | | icann_rdap_technical_implementation_guide_0 | | | icann_rdap_response_profile_0 | | | itNic_level_0 | | | fred_version_0 | fred | | nicbr_level_0 | | | ur_domain_check_level_0 | | | history_version_0 | | | registrar_api_0 | | +---------------------------------------------+---------------------+ Blanchet Expires December 6, 2019 [Page 4] Internet-Draft RDAP Deployment Findings and Update June 2019 3. RDAP Responses This section discusses issues found related to RDAP responses, specified in [RFC7483]. 3.1. Cross-origin resource sharing(CORS) As specified in [RFC7480], the HTTP "Access-Control-Allow-Origin: *" header should be included in the responses, to enable Web clients to work properly. Some RDAP servers do not set this header. RFC7480 says "it is RECOMMENDED that servers". It should be updated to "for any public Internet deployment, servers MUST". 3.2. Object Class Name empty A non-conformant server sends the following answer, where the value of "objectClassName" is an empty string (as well as "handle" also empty). As per [RFC7483] section 4.9, this "objectClassName" value is required. Extract of the seen response: { entities: [ { "entities": [ { "objectClassName": "", "handle": "", } ], ], } 3.3. Links Relation Values The links relation values as specified in [RFC7483] section 4.3 refer to [RFC5988] which creates the IANA Link Relations registry [3]. This registry contains a large number of values where most of them do not apply to the RDAP deployment. As seen with other values above that are similar to registered ones but not used, we list here the ones we have seen. It would be appropriate to further describes the main ones in the RFC so implementors focus on ones that are expected instead of picking the wrong ones in the IANA registry or to define new ones and do not register them. Blanchet Expires December 6, 2019 [Page 5] Internet-Draft RDAP Deployment Findings and Update June 2019 Links Relation Values Seen +------------------+ | Values | +------------------+ | about | | alternate | | copyright | | describedBy | | help | | related | | self | | terms-of-service | | up | +------------------+ 3.4. Related link pointing to self causes infinite loop An RDAP server returns a link of "rel": "related" is pointing to itself, therefore causing the RDAP client to fetch the object again, then read the related link and then fetch again, creating an infinite loop. Extract of the seen response: { "links": [ { "title": "Self", "rel": "self", "type": "application/rdap+json", "href": "https://rdapserver.example.com/domain/example.net" }, { "title": "Registrar Data for this object", "rel": "related", "href": "https://rdapserver.example.com/domain/example.net", "type": "application/rdap+json" } ], } Recommendation: do not put related link same as self. RFC7483 section 4.2 should be updated to add the following text: "A link of "rel": "related" should not have the "href" value the same as the value of "href" of link of "rel": "self". Blanchet Expires December 6, 2019 [Page 6] Internet-Draft EAP-NOOB July 2019 use of a user-assisted out-of-band (OOB) channel. The device authentication relies on user having physical access to the device, and the of the key exchange security is based on the assumption that attackers are not able to observe or modify the messages conveyed through the OOB channel. We follow the common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel in order to prevent impersonation and man-in-the- middle (MitM) attacks. The solution presented here is intended for devices that have either an input or output interface, such as a camera, microphone, display screen, speakers or blinking LED light, which is able to send or receive dynamically generated messages of tens of bytes in length. Naturally, this solution may not be appropriate for very small sensors or actuators that have no user interface at all or for devices that are inaccessible to the user. We also assume that the OOB channel is at least partly automated (e.g. camera scanning a bar code) and, thus, there is no need to absolutely minimize the length of the data transferred through the OOB channel. This differs, for example, from Bluetooth simple pairing [BluetoothPairing], where it is critical to minimize the length of the manually transferred or compared codes. Since the OOB messages are dynamically generated, we do not support static printed registration codes. This also prevents attacks where a static secret code would be leaked. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition, this document frequently uses the following terms as they have been defined in [RFC5216]: authenticator The entity initiating EAP authentication. peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the supplicant. server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server. Aura & Sethi Expires January 4, 2020 [Page 4] Internet-Draft EAP-NOOB July 2019 3. EAP-NOOB protocol This section defines the EAP-NOOB protocol. The protocol is a generalized version of the original idea presented by Sethi et al. [Sethi14]. 3.1. Protocol overview One EAP-NOOB protocol execution spans multiple EAP conversations, called Exchanges. This is necessary to leave time for the OOB message to be delivered, as will be explained below. The overall protocol starts with the Initial Exchange, in which the server allocates an identifier to the peer, and the server and peer negotiate the protocol version and cryptosuite (i.e. cryptographic algorithm suite), exchange nonces and perform an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB Step then takes place. This step requires only one out-of-band message either from the peer to the server or from the server to the peer. While waiting for the OOB Step action, the peer MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB Step has already taken place, the probe leads to the Completion Exchange, which completes the mutual authentication and key confirmation. On the other hand, if the OOB Step has not yet taken place, the probe leads to the Waiting Exchange, and the peer will perform another probe after a server-defined minimum waiting time. The Initial Exchange and Waiting Exchange always end in EAP-Failure, while the Completion Exchange may result in EAP-Success. Once the peer and server have performed a successful Completion Exchange, both endpoints store the created association in persistent storage, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, ECDHE rekeying, and updates of cryptographic algorithms can be achieved with the Reconnect Exchange. Internet-Draft RDAP Deployment Findings and Update June 2019 3.5. Registrant Entity Too Deep An RDAP server returns the registrant entity in a subentity, which makes difficult to parse given the expectation is the registrant would be at the top level. Extract of the seen response: { entities: [ { "objectClassName": "entity", "handle": "HANDLE1", "roles": [ "abuse" ], "vcardArray": [ ... ], "entities": [ { "objectClassName": "entity", "handle": "HANDLE2", "roles": [ "registrant" ], "vcardArray": [ ... ], } ], ], Recommendation: put the registrant in the top-level entities as follows: { entities: [ { "objectClassName": "entity", "handle": "HANDLE1", "roles": [ "abuse" ], "vcardArray": [ ... ] }, { "objectClassName": "entity", "handle": "HANDLE2", "roles": [ "registrant" ], "vcardArray": [ ... ], } ], 4. Queries This section talks about support of RFC7482 queries and the RDAP server behaviors seen. Blanchet Expires December 6, 2019 [Page 7] Internet-Draft RDAP Deployment Findings and Update June 2019 4.1. URL encoding of : For RIR registries, the ip query may include an IPv6 address which then includes one or many ":". Clients may decide to do percent- encoding of the query. In one RDAP server, the server rejected the percent-encoded query of an IPv6 address. For example, https://rdapserver.example.com/ip/2001%3Adb8%3A0%3A%3A/48 is rejected, while https://rdapserver.example.com/ip/2001:db8:0::/48 is accepted. Recommendation: accept both percent-encoded queries or non-percent encoded queries. 5. Domain Registrar RDAP Server Location The ICANN RDAP Profile [4] section 3.2 requires the domain registries who do not have registrant information (so-called thin registries) to put a specific link of "rel": "related" pointing to the domain registrar responsible for the domain being queried, so that a client can get the registrant information using a second query to the related link. However, the semantics seems ambiguous as other RDAP servers may use the "rel": "related" for other related means, but not the specific semantic of finding the registrant data. Therefore, a possible mitigation is to define a new "rel" type of "registrantInfo" (mnemonic TBD) to carry the specific semantic of registrant info. 6. Issues related to RFC7482 6.1. Search patterns that are not Section 3.2.1 of [RFC7482] says: "domains?nsIp=ZZZZ. ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address.". Search pattern has been used throughout the document as something that can include '*', while here, it does not. The syntax statement is also misleading. Similarly, section 3.2.2 says: "nameservers?ip=YYYY YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address." Recommendation: in [RFC7482], replace: "ZZZZ is a search pattern representing an IPv4" by "ZZZZ is an IPv4", "Syntax: domains?nsIp=<domain search pattern>" by "Syntax: domains?nsIp=<nameserver IP address>", "YYYY is a search pattern representing an IPv4" by "YYYY is an IPv4", "Syntax: nameservers?ip=<nameserver search pattern>" by "Syntax: nameservers?ip=<nameserver IP address>" Blanchet Expires December 6, 2019 [Page 8] Internet-Draft RDAP Deployment Findings and Update June 2019 7. IANA RDAP Bootstrap Registries Related Issues This section describes issues related to the IANA Bootstrap registries as specified in [RFC7484]. 7.1. Missing Trailing Char in Bootstrap Registries [RFC7484] section 3 says: "Base RDAP URLs MUST have a trailing "/" character". However, some values in the various IANA Bootstrap registries do not have the trailing "/" character. These should be added to provide consistency. 7.2. Single target value [RFC7484] provides a way to list multiple RDAP servers for an entry. This flexibility was designed initially to support multiple URI types, such as http: and https, and to provide some level of redundancy. However, given that security deployment policy is to use https everywhere and redundancy can be accomplished in other ways, deployment has shown that all entries in all bootstrap registries have a single target RDAP URL value. Therefore, we can consider updating the RFC to provide only one target value. However, this should be done carefully to avoid breaking current deployed clients. 8. Security Considerations Proper conformance to specifications helps security. However, no security issues have been found in the context of this draft. 9. IANA Considerations This document request IANA to add the following values to this registry. TBD. 10. Acknowledgements Audric Schiltknecht, TBD have provided input and suggestions to this document. 11. References 11.1. Normative References [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>. Blanchet Expires December 6, 2019 [Page 9] Internet-Draft RDAP Deployment Findings and Update June 2019 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>. [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015, <https://www.rfc-editor.org/info/rfc7483>. [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 2015, <https://www.rfc-editor.org/info/rfc7484>. 11.2. Informative References [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, <https://www.rfc-editor.org/info/rfc5988>. 11.3. URIs [1] https://www.iana.org/assignments/rdap-json-values/rdap-json- values.xhtml [2] https://www.iana.org/assignments/rdap-extensions/rdap- extensions.xhtml [3] https://www.iana.org/assignments/link-relations/link- relations.xhtml [4] https://www.icann.org/en/system/files/files/rdap-technical- implementation-guide-15feb19-en.pdf Author's Address Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Email: marc.blanchet@viagenie.ca URI: http://viagenie.ca Blanchet Expires December 6, 2019 [Page 10]