Re: Registry lock - two-factor or intervention

Hi  Patrik

Some thoughts below:

> I see no problems what so ever to "turn on" via epp, and think that is what should be done.


The original use case for the "Registry Lock" service offering, at least at the gTLDs was to provide some backup restrictions in the event a registrar's credentials/systems were compromised.  Registrars can already "lock" a domain through Client prohibited statuses.  Early Registry Lock service offering required the Registrar to authenticate in an out of band mechanism from the EPP server, this typically meant calling into the Registry support desk and providing a personal authentication code/password/token, etc at which time the Registry staff would apply the lock.  Later some Registries talked about provided an out of band API separate from the Registry system to automate the same concept.

If this is still the business justification (protection against a compromised Registrar), then there is a problem with facilitating turning on the Registry Lock via the EPP server.  Although a separate system, with separate credentials that happens to use an EPP API would be fine.  Personally I think one should only use an EPP API where necessary, it's easier to use  Restful API over xml or json for non-core registry requests. 


> I think you absolutely must have a two-factor authentication in the form of two phone numbers, physical surface post or whatever. Something that is extremely hard to socially engineer. Require two persons to be involved or whatever.

Exactly the point to requiring them to contact customer service as past of the Registry Lock process, no actual direct machine interface method to apply or remove the lock and multiple steps.  You now need to have the personal credentials of an authorized Registrar employee versus the main login credentials for the registrar.  Of course, as always, the greatest exposure is the Registrar's and Registry's own staff.


MICHAEL YOUNG
[email protected]

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