Re: Registry lock - two-factor or intervention

On 19/09/2013, at 9:33 AM, Francisco Obispo <[email protected]> wrote:

> The only reason why I would use an extension to implement a registrar lock, is to:
> 
> 1) Collect real registrant information so it can be used to authenticate a request to activate at the registry using an out-of-band method. This include response/challenges, mobile number, etc so that multi-factor authentication can be used. This is specially useful when privacy services are used.

We came to the conclusion that a manual verification (or possibly another out-of-band verification) does not need to be to the registrant but works perfectly well to the registrar.  That of course is much better for those of us that need to maintain the registry->registrar->registrant model and not introduce a registry->registrant component.

An example:

The registrar locks via EPP.   The registrar is hacked and a change request is sent.  At the registry the change request goes into a verification queue.  Then either

a) the registry phones the registrar (ok for us with only 80 registrars) and checks the change request is valid; or
b) the registrar must enter a secure token, generated by something like SecureID/Google Authenticator on the registry web site; or


Of course we could just expect the token to come with the unlock, as Jacques was describing.  But in none of the above does the registrant have to hold the token, it is fine for the registrar to hold it so long as it is sufficiently compartmentalised from the registrar provisioning system.  I have yet to hear of a registrar hack that has included breaking into the registrar offices and physically accessing equipment.

cheers
Jay


> 
> 2) Signal the registrar that a registry lock is in effect, which could be much more than the standard server* statuses.
> 
> 
> 
> 
> On Sep 18, 2013, at 1:21 PM, "Hollenbeck, Scott" <[email protected]> wrote:
> 
>> Anyway, yes, if the idea is to communicate some sort of request to the registry to perform an out-of-band locking action it could be done via EPP. As you noted there would need to be an additional out-of-band mechanism in place to validate the request.
>> 
>> Scott
> 
> Francisco Obispo 
> email: [email protected]
> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
> PGP KeyID = B38DB1BE
> 
> 
> 
> 
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

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