Re: Registry lock - two-factor or intervention

I have the pleasure of being both involved with the Registry and
Registrar side of the business.


As a Registrar - I would see an extension similar to the existing "EPP
Prohibit Actions" the way to set such a lock and then when unlocking
such a lock, the need for the Registrar to use one of those key
generators that some Banks provide customers with for Internet Banking
(OTP - One Time Password generators).

Its an out of band (OOB) collaboration that the correct party is asking
for a change - and these OTP devices are not (MUST NOT be) physically
connected to the Registrar EPP systems. Not sure if one can do "replay"
type scenarios with these OTP devices - or how predictable they become.

Anyway - the primary expense is one OTP device per Registry/Registrar
relationship... so the extra security can be added for basically nothing
(cost-wise) and with no extra work for the Registry per unlock.

There would be some additional (minor) software development. Physical
management of the OTP devices, distribution etc - would have to be done
too.

Was wondering about scalability - Locked domains should usually stay
locked? Perhaps big batched changes (ie jobs like the same Nameserver
change for multiple domains) could be validated with one OOB OTP?

Just my rambling thoughts on the subject.

On Thu, 2013-09-19 at 09:56 +1200, Jay Daley wrote:
> 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
> 
> 

-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       [email protected]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

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