Re: Implementation of EPP AuthInfo
Rubens Kuhl <[email protected]> Tue, 7 May 2013 10:37:41 -0300
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
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 Em 07/05/2013, às 10:00:000, Vlad Dinculescu escreveu: > 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. > > > On 07 May 2013, at 2:42 PM, "Gould, James" <[email protected]> wrote: > >> 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 protected] >> >> 703-948-3271 (Office) >> 12061 Bluemont Way >> Reston, VA 20190 >> VerisignInc.com >> >> >> >> >> >> On 5/7/13 2:23 AM, "Vlad Dinculescu" <[email protected]> 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 >>> -------------------------------- >>> Domain Name Services >>> _______________________________________________ >>> provreg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/provreg >> > > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg