Domain name system vulnerable to slamming

The communications protocol that enables competitive domain-name registration has come under attack by the Internet engineering community for failing to provide adequate precautions against slamming.

Slamming is the unauthorised transfer of customers from one company to another that has plagued the telephone industry.

If domain-name slamming becomes common, companies risk losing ownership of their domain names during registration-oriented transactions, critics charge.

The Registry Registrar Protocol (RRP) lets accredited registrars record .com, .net and .org domain names in a central database operated by Network Solutions (NSI) under contract with the US Department of Commerce. NSI set up the RRP, which has been used to support domain name registrations since June, and insists that the protocol offers appropriate protections against slamming.

NSI has asked the Internet Engineering Task Force to publish the protocol as an informational document. Recently, however, IETF members have circulated dozens of e-mail messages criticising the design of the protocol as well as the process by which it was created.

"The protocol submitted by NSI for informal publication by the IETF is too flawed to be considered," says IETF member Ed Gerck, a security specialist who last year served on a panel that advised NSI on the design of a shared registration system protocol. "No one in the IETF [mailing] list supported the protocol as it is."

Patrik Faltstrom, co-director of the IETF's Applications Area and another member of NSI's advisory panel, says the protocol's design and security shortcomings are the result of having a single organisation develop it in a short time frame. "I don't think the business requirements [for competitive registration] were available when the protocol started to be designed, so some things, like the transfer of one domain from one registrar to another, were not nailed down properly before someone had to implement it," he says.

The RRP handles communications between registrars, which sell registration services to companies and individuals, and the central registry, which serves as the authoritative repository of information about reserved domain names. The protocol does not support communications between registrars and end users who purchase domain names. Based on the Transmission Control Protocol, the RRP was deployed in the Commerce Department's Shared Registry System test bed, which ran from April until November of last year.

NSI disagrees with the criticisms levelled against RRP.

"The shared registration system includes multiple levels of security that provide a combination of privacy and authentication services for interaction with licensed and accredited registrars," says Scott Hollenbeck, an NSI engineer who helped draft the protocol. "All of the security layers would have to be breached before an intruder could gain access to private registry systems.

"Slamming is prevented by providing notification of all requested transfers to the current sponsoring registrar," he adds. "Transfers do not take place immediately; the sponsoring registrar has up to five days to respond to the request and may explicitly approve or reject the request at any time within the five-day pending period."

However, IETF members say a flaw exists in the protocol's transfer command, which doesn't specify to which registrar the domain name is to be transferred. Instead, that communication is handled by a separate e-mail. Critics of the protocol say this security hole means that in the midst of transferring a domain name from one registrar to another, the owner could lose the domain name to a malicious registrar who then resells the name to someone else.

The IETF leadership is so concerned about the RRP's transfer command that it has asked NSI for additional information about how the technology works.

Certificates needed?

Another criticism of RRP is that it uses passwords to identify registrars instead of the more secure method of certificates. Of concern with this approach is that if the central registry is hacked, all the registrars' passwords could be identified and would need to be replaced.

"Digital certificates are required for connection to the RRP service, but user ID and passwords are required to initiate a session," explains Rick Wesson, an IETF member and a senior software engineer at Alice's Registry Tools. "Certificates should be used instead of User ID and passwords."

Internet engineers also complain that the RRP uses the Secure Sockets Layer protocol, which doesn't provide an audit trail for resolving domain-name disputes.

IETF members differ in their views on the impact of problems with the RRP.

"It's a very serious threat," says Jeffrey Williams, an IETF member and a spokesman for INEGroup, which represents 98,000 domain-name holders. "My two main concerns about it are that [firstly] there is a privacy exposure problem. Anybody can get in that database and get all kinds of information about the domain-name holder. The other concern is domain-name slamming. They just don't have any real good security on that protocol."

Wesson agrees that RRP does not prevent slamming, but he says registrars will have little economic incentive to switch customers without authorisation. "A transfer costs [the same as] a one-year renewal, so what incentive does a registrar have to slam if they are not receiving payment before the transfer?" he asks. "Slamming doesn't appear to be a big threat."

Companies concerned about the privacy and security of their domain names should consider becoming an accredited registrar, the IETF's Gerck recommends.

"This is the only way that they could be in control of their Internet identity and deal directly with the registry," he says.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about IETFInternet Engineering Task Force

Show Comments