Subject: [provreg] Implementation of EPP AuthInfo

From: Vlad Dinculescu <[email-masked]>
Date: Tue, 7 May 2013 08:23:37 +0200

All,

Please share your thoughts regarding the implementation of the Contact AuthInfo for the approval of initiated contact updates.

Our current process looks to have the registrant provide the code as an indication of approval regarding the update of their information, completing the update instantly. Updates that are not provided with the code will not execute.

Further to this, we are looking to implement the Domain AuthInfo code as a definite measure for approving registrant changes to a linked domain. In this instance the current registrant must provide the Domain AuthInfo code as approval of the registrant change.

Regards,
Vlad Dinculescu
--------------------------------
Domain Name Services

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 6 May 2013 23:33:18 -0700

Hi Vlad,

What are the problems you're trying to address with these measures?

Some thoughts below:

> Our current process looks to have the registrant provide the code as an indication of approval regarding the update of their information, completing the update instantly. Updates that are not provi…

Do you want to accept an update from a non-sponsoring registrar?

If that's not the case, the AuthInfo will be available to the sponsoring registrar anyway.

> Further to this, we are looking to implement the Domain AuthInfo code as a definite measure for approving registrant changes to a linked domain. In this instance the current registrant must provide…

Same as above, but in addition, a contact object can be independently updated regardless if its used in a domain name or not, so the restriction will only have effect if you 'replace' the registrant with other ID, but not if you change the contact underlying data.

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Vlad Dinculescu <[email-masked]>
Date: Tue, 7 May 2013 08:51:55 +0200

Hi Francisco,

Thanks for the reply, please see responses inline below.

> What are the problems you're trying to address with these measures?

Simply put, we are attempting to avoid registrars performing updates on Contact information that are not authorised or requested by the Contact.
We have found that "bringing out the big stick" doesn't work effectively, so now we are attempting to put the decision making where it belongs, in the hands of the registrant.

> If that's not the case, the AuthInfo will be available to the sponsoring registrar anyway.

We did identify this issue as well, knowing that the sponsoring registrar would have access to the code. 
Does an implementation exist where the AuthInfo is used as an out-of-band means of authorisation from the registrant.

> Same as above, but in addition, a contact object can be independently updated regardless if its used in a domain name or not, so the restriction will only have effect if you 'replace' the registran…

In this instance we are looking at the replacement of the associated domain registrant ID with a different one. This is a domain update where the current registrant can use the associated domain AuthInfo to approve the change of the registrant ID to a different one.

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 7 May 2013 08:44:35 +0000

> We have found that "bringing out the big stick" doesn't work effectively, so now we are attempting to put the decision making where it belongs, in the hands of the registrant.

If you're having issues with some of your registrars then you need to address that via the contract you have with them
Penalising all registrars by creating more work for them and their developers doesn't seem rational to me

>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains
ICANN Accredited Registrar
http://www.blacknight.co
http://blog.blacknight.com/
Intl. +353 (0) 59  9183072
US: 213-233-1612 
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: Vlad Dinculescu <[email-masked]>
Date: Tue, 7 May 2013 11:04:38 +0200

Hi Michele,

Thanks for the response. I completely agree with your statement. We were just looking to see if there was perhaps some way of implementing it. It seems that there isn't without inconveniencing so many others and increasing the workload for everyone; something which we do not want to do.

Thank you All for the feedback.

> Twitter: http://twitter.com/mneylon

Kind Regards,
Vlad Dinculescu
-------------------------
Domain Name Services

---

From: InterNetX - Volker Janzen <[email-masked]>
Date: Tue, 07 May 2013 11:10:22 +0200

Hi,

> Penalising all registrars by creating more work for them and their developers doesn't seem rational to me

I agree with this. I don't know any example where a contact:update has
to be performed with a password and the registrar is not allowed to
store it in its own database and has to fetch it from the domain owner
every time.

I know some registries that are sending out email notifications if
contact data has changed. This enables the registrant to complain, if
there are changes he or she did not want.

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142

GPG-Key: 0x186C5F77
GPG-Fingerprint: 392E 8730 FE23 DCE8 8878 8524 5361 BCCC 186C 5F77

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 7 May 2013 09:35:15 +0000

Volker

I *think* I've seen a couple of ccTLDs offer a sort of "self service" portal that allows registrants to do some maintenance using this kind of method, though the problem is that doing this means the data we (the registrar) hold is out of date.

We've also seen ccTLD registries allow domain holder (registrant) transfers without informing the registrar of record.
Very very annoying

Regards

Michele

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains

---

From: "Gould, James" <[email-masked]>
Date: Tue, 7 May 2013 12:42:39 +0000

Vlad,

The main question is what you're attempting to mitigate with requiring the
authinfo on an update for a contact or domain.  The first item is that the
sponsoring registrars can and do have the authinfo values, so there is no
guarantee and is unlikely that the registrant will be presented anything
by the sponsoring registrar.  Are you attempting to mitigate a compromised
registrant account or a compromised registrar?  In both cases, the
sponsoring registrar can pass the authinfo automatically without any
additional steps from the registrant, so requiring the authinfo on update
will not mitigate these vulnerabilities.  The authinfo works for actions
taken by non-sponsoring registrars like for an info or transfer, since the
registrant must pass the authinfo that was received by the sponsoring
registrar to authorize the action.  Use of the authinfo for actions by the
sponsoring registrar will add no additional security since the information
is available to the sponsoring registrar without any direct action from
the registrant.    

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 5/7/13 2:23 AM, "Vlad Dinculescu" <[email-masked]> wrote:

>All,
>
>Please share your thoughts regarding the implementation of the Contact
>AuthInfo for the approval of initiated contact updates.
>
>Our current process looks to have the registrant provide the code as an
>indication of approval regarding the update of their information,
>completing the update instantly. Updates that are not provided with the
>code will not execute.
>
>Further to this, we are looking to implement the Domain AuthInfo code as
>a definite measure for approving registrant changes to a linked domain.
>In this instance the current registrant must provide the Domain AuthInfo
>code as approval of the registrant change.
>
>Regards,
>Vlad Dinculescu

---

From: Vlad Dinculescu <[email-masked]>
Date: Tue, 7 May 2013 15:00:35 +0200

James,

I'm attempting to mitigate unwarranted or accidental updates from occurring.

I though this would be possible by implementation of an out-of-band process whereby, for example, a domain update is performed to change the associated registrant ID. This would create a queued timer on the registry side whereby its execution will depend on the current registrant providing the AuthInfo code through some online interface. By doing this, the registrant provides authorisation. If the code is not provided, the timer expires and the domain update is cancelled.

As Michele mentioned earlier this would be an extreme incorporation which will require a lot of work, hence we will be abandoning the idea and looking more towards a policy level to punish unwarranted actions.

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 7 May 2013 10:37:41 -0300

Vlad,

What you are trying to accomplish is a registry-registrant communications authorization channel. It can only be implemented outside EPP, because registrants do not "speak" EPP. We have one such mechanism in .br where registrants can ask for a password to manage their .br handles instead of their registrars, and it's implemented by web interface and e-mail. When that happens registrars are informed thru EPP Poll messages. 

Rubens

---

From: Keith Gaughan <[email-masked]>
Date: Thu, 9 May 2013 14:12:40 +0100

On Tue, May 07, 2013 at 08:51:55AM +0200, Vlad Dinculescu wrote:

> Simply put, we are attempting to avoid registrars performing updates
> on Contact information that are not authorised or requested by the
> Contact.  We have found that "bringing out the big stick" doesn't work
> effectively, so now we are attempting to put the decision making where
> it belongs, in the hands of the registrant.

As Michele wrote (albeit in different terms), that's a sociological
problem, not a technical problem. By necessity, the registrar has to be
a trusted intermediary between the registrant and the registry. If a
registrar is being that abusive, then the solution is to remove their
accreditation, not to place roadblocks in front of those registrars who
behave themselves.

An alternative might be this: allow registrars to submit whatever
updates they want, but if the changes trigger some heuristic, hold the
change for review and rather than responding with a 1000 response code,
respond with 1001, thus indicating that the change has been held for
review.

Later, assuming you implement the message queue, you can put a
<contact:panData> message on the message queue either confirming or
denying the update request (SS3.3 of RFC 5733).

That leaves it up to you how you implement the review process, which
could be done on your end or by contacting the existing contact to
confirm the request, or whatever.

Just a suggestion.

K.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845