Gtld transfer process
Hello All, Given the recent panix.com hijacking, I will give an outline of the current ICANN transfers process for gtlds. In the case of panix.com, evidence so far indicates that a third party that holds an account with a reseller of Melbourne IT, fraudulently initiated the transfer. The third party appears to have used stolen credit cards to establish this account and pay for the transfer. That reseller is analysing its logs and cooperating with law enforcement. There was an error in the checking process prior to initiating the transfer, and thus the transfer should never have been initiated. The loophole that led to this error has been closed. The transfer process has several checks and balances that are described below. It seems that in this case none of these worked. I can only comment on those from our end. Note also that panix.com was held in the .com registry, that does not use the new EPP protocol which incorporates the facility to store a separate password (called auth_info) for each domain name that must be checked before completing a transfer. Transfers process ================= (see http://www.icann.org/transfers/policy-12jul04.htm for full details) (1) A person initiates a transfer for a domain name via a reseller or registrar (1a) For registries (e.g org, biz, info, name) that use the EPP protocol, the person also needs a password that is held in the registry for each domain name (called auth_info in EPP protocol) (2) The gaining registrar is responsible for obtaining approval from the registrant (using the contact details available in the WHOIS of the losing registrar) using a standardised form (http://www.icann.org/transfers/foa-auth-12jul04.htm). In some cases registrars delegate the obtaining of the approval from a reseller that has direct contact with the registrant. A gaining registrar is not permitted by the policy to initiate a transfer without approval from the registrant. (3) The registrar initiates the transfer. (4) The registry checks to see if the name is on Registrar-LOCK, if so, the transfer request is rejected. Registrants may choose to put domain names on registrar-lock. Many registrars now put names on lock by default, and give the registrant the opportunity to remove a lock prior to transfer. (4a) For registries (e.g org, biz, info, name) that use the EPP protocol, the registry checks the auth_info supplied by the gaining registrar against the record in the registry. If there is no match, the transfer request is rejected. (5) The registry will send a message to the losing registrar confirming that a transfer has been initiated. (6) [OPTIONAL] A losing registrar may send a standard confirmation message (http://www.icann.org/transfers/foa-conf-12jul04.htm) to the registrant. A registrant may cancel a transfer at this point. A registrant may also immediately confirm a transfer at this point and the transfer will be immediately completed. (7) If the registry receives no response from the losing registrar after a 5 day period, the transfer will be completed. (8) A registrant may not further transfer a name for a period of 60 days (apart from back to the original registrar). (9) If the losing registrar believes that a transfer was unauthorised, the losing registrar may contact the gaining registrar for a copy of the authorisation in step 2 to arrange for the transfer to be reversed. (10) If the registrars cannot resolve a dispute, the losing registrar may initiate a dispute process with the registry operator. (11) If the registry operator cannot resolve a dispute, the losing registrar may initiate a dispute process with an external dispute resolution provider (http://www.icann.org/dndr/tdrp/approved-providers.htm). In the case of panix.com, the step (2) failed at the gaining registrar. I can't comment on steps taken by the losing registrar. The principle of the process, is that a registrant can move to another domain name provider (registrar or reseller) at any time, and can initiate a transfer from the new provider. This relies on the new provider authenticating the request. Losing registrars can incorporate registrar lock and transfer confirmation messages to minimise the risk in this process. The integrity of the process is greatly improved through the use of the auth_info password in the EPP protocol. This has been operating effectively in .org, .info., .biz and .name. The alternative to the process could be for the losing registrar to authenticate and initiate a transfer away. This may be more secure, but has a downside in that a losing registrar has an incentive to make this process as difficult and slow as possible. The current transfers policy was a result of over 2 years of work, but can always be improved. Thus ICANN is currently conducting a review of the policy http://www.icann.org/announcements/announcement-12jan05.htm. My personal view is that the current transfers policy WITH the use of auth_info and WITH the use of registrar-LOCK is a reasonable balance between security and allowing registrants to easily move their name. Areas for further improvement include having an expedited process for managing a fraudulent transfer - including the ability to quickly revert back to the previous DNS information while a dispute is investigated, and having mechanisms to ensure that 24/7 emergency contacts are available for all registrars at the registry. I am interested to hear what members of the NANOG list believe would be a better transfers process. Regards, Bruce Tonkin
Problem - you are talking about changing registrar, but in reality you describe changing of domain owner. Why (what for) is it allowed to transfer from one registrar to another with changing NS records and other owner information? Why don't separate this 2 events - changing registrar, and changing domain owner/information? Is it any need in reality changing registrar with simultaneous changing domain information? What should happen in normal situation: - someone requested transfer of domain (without real authorisation); - even if all checks pass and transfer was allowed, new registrar should maintain the same NS and other information as old one, so no real damage could happen; - domain owner received e-mail, see frauded transfer and disputed it (having domain in working condition on the new registrar); - new registrar OR old registrar OR VeriSign roll back transaction. ----- Original Message ----- From: "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au> To: <nanog@merit.edu> Sent: Monday, January 17, 2005 11:36 PM Subject: Gtld transfer process Hello All, Given the recent panix.com hijacking, I will give an outline of the current ICANN transfers process for gtlds. In the case of panix.com, evidence so far indicates that a third party that holds an account with a reseller of Melbourne IT, fraudulently initiated the transfer. The third party appears to have used stolen credit cards to establish this account and pay for the transfer. That reseller is analysing its logs and cooperating with law enforcement. There was an error in the checking process prior to initiating the transfer, and thus the transfer should never have been initiated. The loophole that led to this error has been closed. The transfer process has several checks and balances that are described below. It seems that in this case none of these worked. I can only comment on those from our end. Note also that panix.com was held in the .com registry, that does not use the new EPP protocol which incorporates the facility to store a separate password (called auth_info) for each domain name that must be checked before completing a transfer. Transfers process ================= (see http://www.icann.org/transfers/policy-12jul04.htm for full details) (1) A person initiates a transfer for a domain name via a reseller or registrar (1a) For registries (e.g org, biz, info, name) that use the EPP protocol, the person also needs a password that is held in the registry for each domain name (called auth_info in EPP protocol) (2) The gaining registrar is responsible for obtaining approval from the registrant (using the contact details available in the WHOIS of the losing registrar) using a standardised form (http://www.icann.org/transfers/foa-auth-12jul04.htm). In some cases registrars delegate the obtaining of the approval from a reseller that has direct contact with the registrant. A gaining registrar is not permitted by the policy to initiate a transfer without approval from the registrant. (3) The registrar initiates the transfer. (4) The registry checks to see if the name is on Registrar-LOCK, if so, the transfer request is rejected. Registrants may choose to put domain names on registrar-lock. Many registrars now put names on lock by default, and give the registrant the opportunity to remove a lock prior to transfer. (4a) For registries (e.g org, biz, info, name) that use the EPP protocol, the registry checks the auth_info supplied by the gaining registrar against the record in the registry. If there is no match, the transfer request is rejected. (5) The registry will send a message to the losing registrar confirming that a transfer has been initiated. (6) [OPTIONAL] A losing registrar may send a standard confirmation message (http://www.icann.org/transfers/foa-conf-12jul04.htm) to the registrant. A registrant may cancel a transfer at this point. A registrant may also immediately confirm a transfer at this point and the transfer will be immediately completed. (7) If the registry receives no response from the losing registrar after a 5 day period, the transfer will be completed. (8) A registrant may not further transfer a name for a period of 60 days (apart from back to the original registrar). (9) If the losing registrar believes that a transfer was unauthorised, the losing registrar may contact the gaining registrar for a copy of the authorisation in step 2 to arrange for the transfer to be reversed. (10) If the registrars cannot resolve a dispute, the losing registrar may initiate a dispute process with the registry operator. (11) If the registry operator cannot resolve a dispute, the losing registrar may initiate a dispute process with an external dispute resolution provider (http://www.icann.org/dndr/tdrp/approved-providers.htm). In the case of panix.com, the step (2) failed at the gaining registrar. I can't comment on steps taken by the losing registrar. The principle of the process, is that a registrant can move to another domain name provider (registrar or reseller) at any time, and can initiate a transfer from the new provider. This relies on the new provider authenticating the request. Losing registrars can incorporate registrar lock and transfer confirmation messages to minimise the risk in this process. The integrity of the process is greatly improved through the use of the auth_info password in the EPP protocol. This has been operating effectively in .org, .info., .biz and .name. The alternative to the process could be for the losing registrar to authenticate and initiate a transfer away. This may be more secure, but has a downside in that a losing registrar has an incentive to make this process as difficult and slow as possible. The current transfers policy was a result of over 2 years of work, but can always be improved. Thus ICANN is currently conducting a review of the policy http://www.icann.org/announcements/announcement-12jan05.htm. My personal view is that the current transfers policy WITH the use of auth_info and WITH the use of registrar-LOCK is a reasonable balance between security and allowing registrants to easily move their name. Areas for further improvement include having an expedited process for managing a fraudulent transfer - including the ability to quickly revert back to the previous DNS information while a dispute is investigated, and having mechanisms to ensure that 24/7 emergency contacts are available for all registrars at the registry. I am interested to hear what members of the NANOG list believe would be a better transfers process. Regards, Bruce Tonkin
----- Original Message ----- From: "Alexei Roudnev" <alex@relcom.net> To: "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au>; <nanog@merit.edu> Sent: Tuesday, January 18, 2005 3:45 AM Subject: Re: Gtld transfer process
Problem - you are talking about changing registrar, but in reality you describe changing of domain owner.
conceptually, you are correct.
Why (what for) is it allowed to transfer from one registrar to another with changing NS records and other owner information? Why don't separate this 2 events - changing registrar, and changing domain owner/information? Is it any need in reality changing registrar with simultaneous changing domain information?
yes, every day. a lot of people register their domain through their shared hosting company, so when they decide to switch to a competitor, they switch both. it is irrelevant whether the losing and gaining registrar reseller use the same registrar, in this case. -p --- paul galynin
On Tue, Jan 18, 2005 at 06:36:16PM +1100, Bruce Tonkin wrote:
(5) The registry will send a message to the losing registrar confirming that a transfer has been initiated.
Can you confirm or deny whether this actually happened in the case of the panix.com transfer? The other problem I see in this area is that the RRP specification (if that is in fact the protocol that was used) seems to claim that this message is out-of-band and thus beyond the scope of the protocol: so it does not (can not) specify an ACK. If an attacker found a way to prevent this message from being received, even if generated... A strictly enforced technical requirement for an ACK here might work wonders (perhaps it would have to be enforced by duping both the confirmation and the ACK to the "System", as RRP so quaintly calls it, and denying future transfers initiated by parties with too many outstanding ACKs). Not an approval, just an ACK. There seems to be a general lack of IETF design and review of protocols in this crucial area. Again not good. Thor
At 2:18 PM +0000 1/18/05, Thor Lancelot Simon wrote:
There seems to be a general lack of IETF design and review of protocols in this crucial area. Again not good.
Possible there is some confusion here. While there is an informational RFC describing RRP, it clearly says: VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 and Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. The work in the IETF has been on EPP, and it was done in the usual IETF open working group; it is currently at proposed standard. There is some discussion of taking it Draft Standard at this point, and if you know of problems with EPP that mean it should be changed and re-cycle at proposed, now would be a good time to bring them up. The original working group mailing list, ietf-provreg@cafax.se, is still open for discussions of this kind. regards, Ted Hardie
Speaking as a co-chair of the erstwhile PROVREG WG, which produced the EPP documents (http://www.ietf.org/html.charters/OLD/provreg-charter.html): At 2:18 PM +0000 1/18/05, someone wrote:
There seems to be a general lack of IETF design and review of protocols in this crucial area. Again not good.
Assuming "this crucial area" to mean registration protocols, including EPP, IRIS, and DNS, I'd say that there is ample opportunity for review, although what is done is still insufficient. (It will always be "insufficient" to some.) The IETG Working Group's for these protocols are - EPP - PROVREG WG closed, see above, but the mailing list still runs IRIS - CRISP WG http://www.ietf.org/html.charters/crisp-charter.html DNS - DNSEXT WG http://www.ietf.org/html.charters/dnsext-charter.html and - DNSOP WG http://www.ietf.org/html.charters/dnsop-charter.html WhoIs and RRP are not related to WG's so far as I can recall. These web pages mention mailing lists for the groups. That is how to provide "design and review" without the expense of travel. I know all about insufficient design and review. I've seen DNSSEC overhauled when the initial review process failed. As co-chair for PROVREG, trying to get wider review was the main job. (Early on, no one wanted to hear about it...) PS - If you can contribute "client-side" expertise to many of these protocols, you will be in high-demand. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar "A noble spirit embiggens the smallest man." - Jebediah Springfield
PS - If you can contribute "client-side" expertise to many of these protocols, you will be in high-demand. And as the other co-chair of the erstwhile PROVREG WG, I agree. jaap
Bruce,
I am interested to hear what members of the NANOG list believe would be a better transfers process.
<operator_hat="on"> Non-functional changes of operationally significant configuration data is avoided. My thumbs are as thick as the next person's. I'm quite happy to buy a decade's worth of name, even at $35/name/year, because other than changes to NS records, as renumberings come and go, and machines spontainiously combust, I don't want change. When I need change, I plan it, just like renumbering or new circuits or new network elements or new staff. The notion of "REGISTRAR LOCK" is simply too weak, it can be flipped in minutes. I want something that presents only limited windows of state change (other than NS) opportunity, which I can syncronize to corporate standard paperwork flag days, so it isn't when I hand the keys to the shop to a junior and take the kids on holiday. I want a "transfer process" that is inherently difficult, if not broken, for domain names that are business assets. I don't care about "competition" between registrars, or how much I get soaked for by the registrar and registry, or how evil and/or retarded one or both are. I actually don't care about how quickly domain names are added to a tld zone, in fact, my domain names that are business assets worked just fine when names were published 3 times a week from the SRI NIC. So, I want a "transfers process" that is not indifferent to my use of domain names. I don't care what the domain name industry does with vanity names, trademark names, speculation names, porn names, spam names, even ebusiness names that aren't in the ISP/NSP food chain. Heck, I'd be happy to pay two registrars $35/name/yr to make sure they both have to be gamed before my domain names tied to operational assets become vulnerable to unplanned and state change in the registry (3rd party acquisition). [I actually do this, with some names with one good competitior-registrar, and some self-registrared, but to spread risk.] <operator_hat="off"> <hosting_hat="on"> I do have hosting customers who more or less come and go synchronous with registrar transfer. In effect, these are month-to-month or year contracts, and I understand why new customers are wary of hosting providers who want to be in the control path for registry state change. But the "bread and butter" are multi-year hosting contracts, and for these customers registrar they want to be in the same small boat I want to be in. <hosting_hat="off"> I hope that is helpful. I'm sure everybody else is wicked happy with the system they have, which is why everyone has the same system. Cheers, Eric
Sorry about the subject line. I switched horses in mid-stream.
At 7:21 PM +0000 1/18/05, Eric Brunner-Williams in Portland Maine wrote:
From: "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au> ... I am interested to hear what members of the NANOG list believe would be a better transfers process.
The notion of "REGISTRAR LOCK" is simply too weak, it can be flipped in minutes. I want something that presents only limited windows of state change (other than NS) opportunity, which I can syncronize to corporate standard paperwork flag days, so it isn't when I hand the keys to the shop to a junior and take the kids on holiday.
It appears that "REGISTRAR LOCK" has interesting per-registrar implementation variations which do not always put the domain holder's interests first. While the registry does not, per se, have a direct business interest with the domain holder, it should be possible to have a lock state which is more oriented to the critical needs of some business domain holders. For a reasonable fee (and copious amount of documentation), it should be possible for any record holder to instruct the registry to lock the ownership of a domain down in such a way so as to require a similar amount of paperwork to release; thus effectively creating an "OWNER LOCK" state. /John
participants (10)
-
Alexei Roudnev -
Bruce Tonkin -
davidb＠panix.com -
Edward Lewis -
Eric Brunner-Williams in Portland Maine -
Jaap Akkerhuis -
John Curran -
Paul G -
Ted Hardie -
Thor Lancelot Simon