|
For more than 30 years, the industry has used a service and protocol named WHOIS to access the data associated with domain name and internet address registration activities.
• Do you need to find out who has registered a particular domain name? Use WHOIS.
• Do you want to see who an Internet Protocol (IP) address has been allocated to? Use WHOIS.
WHOIS security concerns
The challenge with WHOIS is that it was designed for use at a time when the community of users and service operators was much smaller and there were fewer concerns about data privacy. Today it’s possible to use WHOIS to collect personally identifiable information (PII), such as physical residence addresses, telephone numbers, and email addresses associated with an individual’s domain name and IP address registration activity. This is a cause for concern in many places where people care about personal privacy, and unfortunately, there’s no easy way to address these concerns using WHOIS because it’s an “all data is available to everyone all the time” service. Thankfully we now have new tools available in the form of the Registration Data Access Protocol (RDAP), which was designed to address the many deficiencies of WHOIS—including the lack of security services needed to provide data privacy.
How do we scale up?
Like WHOIS, RDAP is a client-server protocol. Clients send a command (such as a query for domain name registration information) to an RDAP server, the server receives and processes the command, and if all is well, the server returns the result of processing the client’s command. Unlike WHOIS, RDAP gives servers the ability to vary the amount of information returned in a response based on the client’s identity and the amount of information they are authorized to see. The core RDAP security service protocol specified in RFC 7481 requires server operators to provide basic client identification and authentication services based on usernames and passwords, but this form of client access is unwieldy when clients have to maintain credentials for thousands of servers and server operators have to maintain credentials for millions of clients. A more scalable solution is needed, and can be obtained in the form of a federated authentication service.
Use one credential to access all services
What is federated authentication? It’s a form of authentication in which the parties involved in using and providing a service agree to form cooperating units with third-party identity providers to create, manage and use identification credentials. If you’re familiar with how single sign-on services work you already understand the basic idea. If not, imagine a world in which you can take a username and password issued by one service and use it to access another service because the second service uses and trusts the first service to validate your username and password. It’s a great way to reduce the number of usernames and passwords that you have to acquire and remember!
There are several benefits to using a federated authentication system that makes it an obvious candidate for extending the utility of RDAP, including:
Verisign Labs launched an experimental service in February 2016, to demonstrate the viability of a federated authentication system for RDAP based on a protocol called OpenID Connect. OpenID Connect is built on top of the OAuth 2.0 protocol. The approach Verisign is taking is documented in an Internet-Draft document titled, “Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect.” The experiment can be accessed from our website at https://rdap.verisignlabs.com/; click the “Help” link on the homepage for instructions.
Join the experiment
We currently support both authenticated and unauthenticated RDAP queries for domain registration data associated with the .cc and .tv country code top-level domains (ccTLDs). Feel free to try the service using a query for a domain like “nic.tv.” You can experiment with authenticated access using your Gmail or Hotmail username and password.
We don’t return any PII, but hopefully, you’ll see how it’s possible to return more or less information based on client identity. Knowing who the client is allows the server operator to make access-control decisions based on client identity and associated levels of authorization. This information can be used to prevent disclosure of PII to unauthorized clients.
We started our Verisign Labs experiment to demonstrate the viability of an approach, and so far the news has been good. Here are some of the strides Verisign has made to date:
I’m convinced that the technology we need is available to us. Now we need more experimental implementations to help us explore the policies associated with client authorization and access control. The real benefits of a federation can only be realized when a significant number of like-minded users and operators decide to work together. We will all reap the most benefit from RDAP if we find a way to make it easy to access and use our services across operational boundaries.
Get involved
It’s important to note that there is a relatively new ICANN working group that was “tasked with analyzing the purpose of collecting, maintaining and providing access to generic top-level domain (gTLD) registration data and considering safeguards for protecting that data; determining if and why a next-generation Registration Directory Service (RDS) is needed to replace WHOIS; and creating policies, and coexistence and implementation guidance to meet those needs.” While this group’s mandate is limited to the services provided by gTLD registrars and registries, there is a very good chance that the work will also provide benefits to the users and operators of ccTLD and RIR RDAP services.
It’s well worth your time to join the group as either an active participant or observer. Additional information can be found on a wiki maintained by the working group.
Sponsored byVerisign
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byCSC
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byVerisign
Dear Scott:
If you could clarify something, please. Your article stated that “The core RDAP security service protocol specified in RFC 7481 requires server operators to provide basic client identification and authentication services based on usernames and passwords”.
The context of that statement may be a bit unclear to some readers, and they may take it to mean that identification and authentication services based on usernames and passwords are required in any RDAP implementation. I think you were talking about a specific situation, in which the server operator wants to offer tiered or differentiated access.
My understanding is that RDAP can accommodate anonymous access, and does not require users to authenticate themselves with a username and password, unless the server operator desires to implement that kind of thing. I base my understanding in part on RFC 7481 Section 3.2, which “describes requirements for the implementations of clients and servers but does not dictate the policies of server operators. For example, a server operator with no policy regarding differentiated or tiered access to data will have no authorization mechanisms and will have no need for any type of authentication. A server operator with policies on differentiated access will have to construct an authorization scheme and will need to follow the specified authentication requirements.”
Thanks,
—Greg
Thanks for the comment, Greg. Yes, RDAP can accommodate unauthenticated access. The Verisign Labs experimental service demonstrates that very capability. The RFC key words for requirement specifications do not necessarily dictate operational requirements.
I think users who want to see registration details of a site they’re visiting can do it without authentication. Browsers don’t support WHOIS because it’s not so reliable, but users can see certification details with one click (if they use https). I expect browsers will sport a similar feature for RDAP, the day it works.
Authenticated access requires lots of scripting. That is appropriate for automated tasks. I had to enable Javascript just to test Verisignlab implementation. Today, only “status” is added to authorized replies. Additional data should depend on which task is authorized. The latter info is not part of the publicly available information on my Google+ profile, as far as I know…
Ale
Thanks for the comment, Ale. You’re correct in noting that we’ve added only status information to the responses for some authenticated queries. This is a limited demonstration of how RDAP can provide identification, authorization, and access control security services. We’re also working with other identity providers to test concepts associated with returning more information. RDAP does in fact support server operators returning more or less information based on the identity of the client and the information they are authorized to receive in accordance with local policy.