[ga] Revised Transfer Policy Recommendations Requested

[Danny Younger <dannyyounger@xxxxxxxxx>]

http://www.merit.edu/mail.archives/nanog/msg04382.html

Gtld transfer process

    * From: Bruce Tonkin
    * Date: Tue Jan 18 02:37:41 2005 

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



















__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around 
http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com