Home / Blogs

We Need You: Industry Collaboration to Improve Registration Data Services

Scott Hollenbeck

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:

  1. It allows clients to use one credential to access a multitude of services.
  2. It allows server operators to provide access to clients without having to issue or maintain credentials for every individual user.
  3. This type of service exists today and is being used to provide privileged client access to websites.
  4. RDAP is itself a web-service protocol that can be extended to use federated authentication services successfully.

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.

  • You'll receive a very limited amount of data in response to an unauthenticated query.
  • You'll receive more data if you provide your access credentials.

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:

  • The ability to use existing open source software to implement the features of OpenID Connect.
  • Implemented our own identity provider (again using existing open source software) to demonstrate how clients can share information about themselves with server operators.
  • Successfully integrated an identity provider developed by another ccTLD operator, and we're currently working with Regional Internet Registry (RIR) operators to participate in the experiment and explore how these services can benefit address registry users and operators.

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.

By Scott Hollenbeck, Senior Director of the Verisign Registry Services Lab
Follow CircleID on
Related topics: Cybersecurity, DNS, Privacy, New TLDs, Whois
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

Question Greg Aaron  –  May 25, 2016 7:44 AM PDT

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 Scott Hollenbeck  –  May 27, 2016 7:26 AM PDT

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.

Wow, it works! Alessandro Vesely  –  May 26, 2016 4:40 AM PDT

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 Scott Hollenbeck  –  May 27, 2016 7:26 AM PDT

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.

To post comments, please login or create an account.

Related

Topics

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byAfilias

DNS Security

Sponsored byAfilias

IP Addressing

Sponsored byAvenue4 LLC

Cybersecurity

Sponsored byVerisign