Subject: [provreg] Registry lock - two-factor or intervention

From: Jay Daley <[email-masked]>
Date: Fri, 13 Sep 2013 11:36:48 +1200

I have some questions for you. 

I'm aware of two separate approaches to registry locking

1.  Two-factor authentication of change requests, where the registrant is expected to hold one factor and the registrar pass it through.  Using something like SecureID.

2.  Intervention, where the registry is expected to verify a change request out-of-band (or the registrar pre-empts this with a out-of-band unlock request).

My questions are:

Q1:  Does anyone have an EPP extension for handling 1 above that they would be willing to put forward for wider use?
Q2:  Is there any role for EPP in 2 above?

thanks in advance for anyone taking the time to reply!

cheers
Jay

-- 
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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Sep 2013 11:35:03 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jay Daley
> Sent: Thursday, September 12, 2013 7:37 PM
> To: [email-masked]
> Subject: [provreg] Registry lock - two-factor or intervention
> 
> 1.  Two-factor authentication of change requests, where the registrant
> is expected to hold one factor and the registrar pass it through.
> Using something like SecureID.
> 
> 2.  Intervention, where the registry is expected to verify a change
> request out-of-band (or the registrar pre-empts this with a out-of-band
> unlock request).
> 
> My questions are:
> 
> Q1:  Does anyone have an EPP extension for handling 1 above that they
> would be willing to put forward for wider use?

I'm not aware of an extension for 1 or an EPP role for 2, Jay.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 13 Sep 2013 15:04:40 +0200

Jay Daley <[email-masked]> 2013-09-13 01:38
> Q1:  Does anyone have an EPP extension for handling 1 above that they would be willing to put forward for wider use?

FWIW I've implemented a VeriSign "Two Factor Auth" extension that
unfortunately I do not find now anymore on
http://www.verisigninc.com/en_US/products-and-services/domain-name-services/registry-products/epp-sdk/index.xhtml
so you have the source instead:
https://metacpan.org/source/PMEVZEK/Net-DRI-0.96_05/lib/Net/DRI/Protocol/EPP/Extensions/VeriSign/TwoFactorAuth.pm

It covers two-factor auth, but maybe more for registrar two-factor
auth instead of registrant two-factor auth.

This seems however to be covered by a patent:
http://www.faqs.org/patents/app/20120174198

HTH,

-- 
Patrick Mevzek

---

From: Jacques Latour <[email-masked]>
Date: Wed, 18 Sep 2013 17:28:38 +0000

Hi Jay,

This is timely, we're also looking at doing registry lock.  We're looking at different mechanisms to setup the lock and also to procure the lock (the $$$) possibly via EPP, but it should be a generic interface usable for any additional value add services that we might offer in the future, not just hard coded for registry lock. {I think}

We would be interested in working with you to build something.

Also, this in an introduction of Stu, our development manager here at CIRA.

Should we have an industry standard way of doing registry lock? { registrant <--> registrar <--> registry }

Jack

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jay Daley
> Sent: September-12-13 7:37 PM
> To: [email-masked]
> 1.  Two-factor authentication of change requests, where the registrant is
> expected to hold one factor and the registrar pass it through.  Using something
> like SecureID.
> 
> 2.  Intervention, where the registry is expected to verify a change request out-
> of-band (or the registrar pre-empts this with a out-of-band unlock request).
> 
> My questions are:
> 

No

> Q2:  Is there any role for EPP in 2 above?

Yes, for locking the domain and also the financial aspect.

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Sep 2013 17:56:41 +0000

> Behalf Of Jacques Latour
> Sent: Wednesday, September 18, 2013 1:29 PM
> To: [email-masked]; Stuart Olmstead-Wilcox
> Subject: Re: [provreg] Registry lock - two-factor or intervention

[snip]

> Should we have an industry standard way of doing registry lock? {
> registrant <--> registrar <--> registry }

I'm more than a little concerned that something that flows through the registrar can be called a *registry* lock. Locks that flow through and can be set or unset by the registrar more appropriately affect the client*Prohibited status values.

Scott

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Wed, 18 Sep 2013 18:03:44 +0000

Scott

It depends on how it's implemented surely?

As a registrar I *might* like the idea of being able to "flag" with the registry that we want to add or remove a registry lock

But I'd be wary of my EPP commands / connection being able to set or unset it, as I'd see that as undermining the very nature of a highly secure registry lock. 

My understanding of the "registry lock" services being offered by several registries and being requested by registrants (see the thread from late last year from Warren) is that the "attraction" or "selling point" is that the lock status has to be set (and removed) using "out of bounds" methods.

Of course I could be completely misunderstanding.

Regards

Michele

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: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Sep 2013 18:21:46 +0000

> From: Michele Neylon - Blacknight [mailto:[email-masked]]
> Sent: Wednesday, September 18, 2013 2:04 PM
> To: Hollenbeck, Scott
> Cc: Jacques Latour; [email-masked]; Stuart Olmstead-Wilcox
> > I'm more than a little concerned that something that flows through
> the registrar can be called a *registry* lock. Locks that flow through
> and can be set or unset by the registrar more appropriately affect the
> client*Prohibited status values.
> 
> Scott
> 
> As a registrar I *might* like the idea of being able to "flag" with the
> registry that we want to add or remove a registry lock
> 
> But I'd be wary of my EPP commands / connection being able to set or
> unset it, as I'd see that as undermining the very nature of a highly
> secure registry lock.
> 
> My understanding of the "registry lock" services being offered by
> several registries and being requested by registrants (see the thread
> from late last year from Warren) is that the "attraction" or "selling
> point" is that the lock status has to be set (and removed) using "out
> of bounds" methods.

My original intention for the server*Prohibited status values was focused more on registry-initiated actions like dealing with a court order that didn't require initiation by a registrar. Their use in implementing an on-demand lock service was a serendipitous side effect.

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

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 18 Sep 2013 16:33:32 -0500

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.

2) Signal the registrar that a registry lock is in effect, which could be much more than the standard server* statuses.

> 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…

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

---

From: Jay Daley <[email-masked]>
Date: Thu, 19 Sep 2013 09:46:30 +1200

Hi Jacques 

We've been floating the idea with registrars and the overwhelming feedback is for the registry to offer the full service with as little development as necessary for the registrars.  Not only that but they also favour a manual service to begin, which can help establish demand and the need for future development.

So putting the two together it looks something like:

1. registrars send a lock request (presumably an extension to EPP, unless anyone has a better idea). 
2. when a change request comes in we queue it and seek manual confirmation that it should be processed.

Still not sure if 1. should be the billable transaction or each occurrence of 2.

how does that seem?

Jay

---

From: Jay Daley <[email-masked]>
Date: Thu, 19 Sep 2013 09:56:22 +1200

> 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 t…

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

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 18 Sep 2013 17:41:22 -0500

Hi Jay,

Let me give you another example,

A registrar mistakenly changes a record (even authorizes a change), without its client knowing about it, the domain name goes offline, or even worse, gets hijacked. 

My idea of a registry lock is to have a direct relationship with the registrant/name holder, so it can decide wether the domain name is allowed to be changed by the registrar.

Verisign offers a registry lock, so perhaps they can share a little bit on how they do it, and how they authenticate the request in cases where contact privacy is enabled.

Francisco Obispo 
email: [email-masked]

---

From: Mark Elkins <[email-masked]>
Date: Thu, 19 Sep 2013 00:36:54 +0200

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.

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

---

From: Luis Muñoz <[email-masked]>
Date: Wed, 18 Sep 2013 18:59:14 -0400

> 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…

I think a Registry <-> Registrant component is unavoidable for this type of service. The Registrant likely wants assurances that the Domain won't be changed in any way without her consent.

Best regards

-lem

---

From: Jay Daley <[email-masked]>
Date: Thu, 19 Sep 2013 11:29:30 +1200

Hi Francisco

> A registrar mistakenly changes a record (even authorizes a change), without its client knowing about it, the domain name goes offline, or even worse, gets hijacked. 

How exactly do you think a registrar can mistakenly authorise a change via an OOB mechanism?  

In my view, the threats and  realistic likelihood of those threats, are:

1.  The registrar is hacked and the miscreant sends a change request using the registrar credentials. [Likelihood = Possible]

2.  The registrar mistakenly requests a change. [Likelihood = Unlikely]

3.  The registrar mistakenly requests a change and then also mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

I would also suggest that the likelihood of 3 is exactly the same as the two following:

4.  The registrar mistakenly requests a change and then the *registrant* mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

5.  The *registrant* mistakenly requests a change and then also mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]

> My idea of a registry lock is to have a direct relationship with the registrant/name holder, so it can decide wether the domain name is allowed to be changed by the registrar.

The implications of that are significant.  Both for the registry and registrar.  Those implications include:

- how does the registry authenticate the registrant (compare delivering one secure token to each registrar with delivering one to each registrant)?
- the risk that the registry will use the relationship for something they shouldn't 
- potentially (depending on how it is set up) the need for the registry to have a customer support team and what happens if the registrant gets poor customer service from the registry?

I would be very careful at rushing into the idea that the registry must have a direct relationship with the registrar if I were you.  Doing it via the registrar is the path of least resistance and less risk.

> Verisign offers a registry lock, so perhaps they can share a little bit on how they do it, and how they authenticate the request in cases where contact privacy is enabled.

There are a number of registries that do it who are part of CENTR and gave presentations on it recently:

.dk
	• registrants have direct contact with registry
	• VID Service (Very Important Domain) - only 1000 VID out  of 1.2 million active domains
	• uses a snail mail approach to enact changes.  very robust, but slow which dies frustrate some people
	• charge 50 krona per annumn (5 pds Sterling)
.cz
	• registrant asks registry for change. Can lock two things
		• just transfer
		• lock all changes
	• done via letter which can be downloaded from website
	• offered as a free service
	• have about 5,000 out of 1 million
	• registrars have all locked their own domains
.nl
	• service called .nl control
	• lock all data, but not name servers
	• it is a manual process
	• sold for 50 Euros per annum
	• numbers sold are very low

Jay

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Wed, 18 Sep 2013 23:32:29 +0000

> I think a Registry <-> Registrant component is unavoidable for this type of service. The Registrant likely wants assurances that the Domain won't be changed in any way without her consent.

Luis

The registry has no contractual relationship with the registrant

The registrant has a contractual relationship with the registrar

The registrar has a contractual relationship with the registry

So - no.

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation
http://www.blacknight.co/
http://mneylon.tel/
Fax. +353 (0) 1 4811 763

---

From: Luis Muñoz <[email-masked]>
Date: Wed, 18 Sep 2013 19:37:25 -0400

> The registrar has a contractual relationship with the registry

Your description of the status quo is consistent with mine. That only means that the status quo is suboptimal to address a specific market need.

If you look at Jay's example, it's clear that 2 out of 3 examples show an explicit relationship between the registrant and the registry. In the .nl case it's not clear whether such relationship exists or not.

Best regards

-lem

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Thu, 19 Sep 2013 00:05:23 +0000

Luis

Jay's examples are from ccTLDs where there is tripartite contractual relationship in many cases.

In the gTLD space that does not exist and is highly unlikely to ever exist.

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Domains

________________________________________
From: Luis Muñoz [[email-masked]]
Sent: 19 September 2013 00:37
To: Michele Neylon - Blacknight
Cc: Jay Daley; <[email-masked]>
Subject: Re: [provreg] Registry lock - two-factor or intervention

Best regards

-lem

---

From: Jarle Greipsland <[email-masked]>
Date: Thu, 19 Sep 2013 08:36:57 +0200 (CEST)

Jay Daley <[email-masked]> writes:
[ ... ]
> 3.  The registrar mistakenly requests a change and then also mistakenly authorises the OOB challenge.  [Likelihood = Very Rare]
3b. The registrar deliberately, as a result of e.g. social
   engineering or blackmail, requests a change and then also
   deliberately authorises the OOB challenge.  [Likelihood = ??]

					-jarle

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 19 Sep 2013 10:35:03 +0200

> The registrar has a contractual relationship with the registry

Michele,

This is not the general case, so your statement is biased.
In .nl, there is a contractual relationship between registrant and
registry.
The role of the registrar is to offload administrative burden of the
registry, the registrar acts as an administrative agent for the
registrant. But technically there is always the parent-child
relationship between registry and registrar in the form of a DNS
delegation, so legally (at least in our jurisdiction) it cannot be
denied that a registry is offering a service to a registrant.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Thu, 19 Sep 2013 10:35:17 +0200

> 1.  The registrar is hacked and the miscreant sends a change request using the registrar credentials. [Likelihood = Possible]

That's an understatement. Sooner or later this will happen to some
registrar(s) We've had that experience with some of our registrars, so
have others (most of us probably remember the New York Times incident).

http://blog.fox-it.com/2013/08/05/dns-takeover-redirects-thousands-of-websites-to-malware/

> 	• lock all data, but not name servers

Locking of (in zone) name servers will be possible in due time with
'nl-Control'. After the incident above, we have speeded up the
development of that feature.

> 	• sold for 50 Euros per annum

That's is probably a retail price. Wholesale prices are considerably
lower (but upon request of our registrars we refrain from publishing
wholesale prices).

> 	• numbers sold are very low

Surprisingly low, given the risks involved.

--
Marco
SIDN

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 19 Sep 2013 10:41:02 +0200

Op 19-09-13 01:29, Jay Daley schreef:

> .nl • service called .nl control • lock all data, but not name
> servers • it is a manual process • sold for 50 Euros per annum •
> numbers sold are very low

To clarify, we are currently redesigning our .nl control service to
include name server changes, and possibly DNSSEC parameter changes.
We are also aiming to automate the service when we reach about 250 .nl
control domains. We would like to implement a common standard, so I'm
interested in this discussion.

- -- 
Antoin Verschuren

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 19 Sep 2013 10:45:22 +0200

Op 19-09-13 10:35, Antoin Verschuren schreef:
> This is not the general case, so your statement is biased. In .nl,
> there is a contractual relationship between registrant and 
> registry. The role of the registrar is to offload administrative
> burden of the registry, the registrar acts as an administrative
> agent for the registrant. But technically there is always the
> parent-child relationship between registry and registrar in the
> form of a DNS

Oops, this is a typo, I meant between registry and registrant.

> _______________________________________________ provreg mailing
> list [email-masked] 

- -- 
Antoin Verschuren

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Thu, 19 Sep 2013 09:22:36 +0000

On 19 Sep 2013, at 09:35, Antoin Verschuren <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

So is your reaction
:)

> In .nl, there is a contractual relationship between registrant and

Yes, but there is normally no contractual relationship between the registry and a registrant in gTLDs, which is what I was thinking about.

> registrant.

Wow! That's actually incredibly offensive to registrars.

So any time there are *any* issues with *any* domains of any kind I can just send all the registrants, users and $random 3rd parties directly to the registry?

Great.

I'll be able to lay off most of my staff

Regards

Michele

> But technically there is always the parent-child
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJSOrc3AAoJEDqHrM883AgnIdkIAKAz9IEtbUBm4sJS7TC2fgig
> bbf6nXfsyRhhhA32I3NHBMeRTegjC32US/VD6jpLPS+kP87Zus0EGQdVX8yEZqWM
> D8w6Dnlz2xfH+XtVtj8u8QuBCw1HVkVRsgAogpUF875PKSZNB8i38ILqBaM4D8kR
> Ev45LDMFXA2g4O0dyOSWDIBvbfoaqLHy28cCKnTnyBLQUbwgd2gEeuQW31XrbRI6
> VFPN64N+oLZO3XKrOuGvMdRqHZbFlN84GzGDk5nu2Xzg0dwgn1shZpBUajwWpMNQ
> zfcDyTxGfMfiKvQyDMasNzu3VbLW7BQ9RmZMS5zcSfp2FE/ZxiZOT7cc2jvHyxE=
> =87Hl
> -----END PGP SIGNATURE-----

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Domains

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 19 Sep 2013 14:34:55 +0200

Op 19-09-13 11:22, Michele Neylon - Blacknight schreef:

>> So is your reaction :)

Touche. :-).
Just wanted to state that ICANN gTLD's are not the only norm. This is
an IETF mailinglist. The IETF create standards, not ICANN contracts.

> The role of the registrar is to offload administrative burden of
> the registry, the registrar acts as an administrative agent for
> the registrant.
> 

Perhaps I'm just not a native speaker, and did not find a better term
than burden, where I meant distribute administrative tasks to market
players that are far better in communicating with end-customers.

>> So any time there are *any* issues with *any* domains of any kind
>> I can just send all the registrants, users and $random 3rd
>> parties directly to the registry?

I think it's the misunderstanding of the term "registrar" that has led
and still leads to these strong statements.
There are indeed a lot of entities that act as registrar in one of
their roles that do a lot more than just that. They also act as
dns-operator as a service to their customer, offer legal services, do
website hosting, are a CA, or offer much more service to their
customer, and do that well.
But these extra services are not part of the pure registrar role in
the model, as there are entities that act as registrar that do not
offer these services, and it's important to clearly separate these
roles when we need to come up with a clear model to base assumptions on.
These entities are service providers, and one of their roles is acting
as a registrar for those of their customers that are registrants.
(They may have other customers that are not registrants). Registrar
refers to the role, not to the entity.
By administrative agent, I mean a registrar is responsible for all
administrative, legal and financial communication and transactions
between registrant and registry regarding the registration of a
domain. The registrar represents the registry towards the registrant,
and represents the registrant towards the registry.

- -- 
Antoin Verschuren

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 19 Sep 2013 09:17:24 -0700

> 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…

Having only the poll method, how can the registrar discover the change
of state caused by an out-of-band (court to registry) communication?

Eric

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 19 Sep 2013 09:24:22 -0700

> In the gTLD space that does not exist and is highly unlikely to ever exist.

Agree. Additionally, a court order (in what territorial jurisdiction?)
creates an enforceable third-party right (in what territorial
jurisdiction?) sufficient to modify without notice to the existing
parties (in what territorial jurisdiction?) the pre-existing
contractual relationship?

Eric

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Sep 2013 16:24:42 +0000

> Behalf Of Eric Brunner-Williams
> Sent: Thursday, September 19, 2013 12:17 PM
> To: [email-masked]
> > My original intention for the server*Prohibited status values was
> focused more on registry-initiated actions like dealing with a court
> order that didn't require initiation by a registrar. Their use in
> implementing an on-demand lock service was a serendipitous side effect.
> >
> > 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.
> 

A polled message is the primary feedback mechanism, but out-of-band channels like email and telephone can also be used.

Scott

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 19 Sep 2013 10:17:01 -0700

> an IETF mailinglist. The IETF create standards, not ICANN contracts.

As one of the original cabal, I believe you are mistaken.

The contributors to the pre-IETF effort sought to create, without
liability under U.S. law (Sherman Act, anti-trust/competition policy
generally)

So, evaluating your lines quoted above:

1. The design constraints of the contributors to the specification
published as the work product(s) of the PROVREG Working Group did not
include registries other than those usually described as "generic" or
"sponsored".

I think most of those involved in provisioning and the consequences of
provisioning (see for example Dan York's note on DNSSEC uptake) share
a view that a single provisioning mechanism that is indifferent to
whether a registry is associated with a direct delegation from the
IANA root, or pre-exists the PROVREG WG work product, or even used a
"shared access" model (whether the "shared access" is implemented in
the "registrar" function or the "registry" function) is preferable,
absent extenuating circumstances, to two or more substantively
distinct specifications.

If there is a "norm" it is tolerance.

2. The [email-masked] is the continued-as-a-convenience vehicle for
communication of the implementers of the specifications published by
the concluded PROVREG Working Group, archived and possibly subject to
the same, and/or subsequent NOTE WELL conditions, of the mailing list
prior to the conclusion of the PROVREG Working Group.

The beneficiaries of the mailing list are not limited to the
contributors to the PROVREG Working Group work product. Others are
free to adopt, with or without modification, our specifications.

3. The purpose of the original contributors who formed the PROVREG
Working Group and who's work product has been repeatedly published by
the IETF, was to create a specification to be made
manditory-to-implement by parties entering into registry or registrar
contracts with ICANN, without incurring liabilities (supra).

Recall, at the period, the IETF formed part of the Protocol Supporting
Organization (PSO), an ICANN ByLaws entity.

Note also, use by competitors of "standards bodies" to publish
specifications without incurring liabilities under competition policy
laws is a broadly established practice.

I repeat, tolerance is useful, and as Michale pointed out, some
hundreds (eventually thousands) of EPP (client, or server, or both)
operators appear to lack, for the moment, a means to provide third
parties with {write|lock} access to the underlying data.

The problem is not likely to be solved, IMHO, by assertion that it
does not exist.

Eric

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 19 Sep 2013 10:27:47 -0700

> liability under U.S. law (Sherman Act, anti-trust/competition policy

Sigh. ... "specifications."

Eric

---

From: Maarten Bosteels <[email-masked]>
Date: Fri, 20 Sep 2013 09:41:33 +0200 (CEST)

Hi all, 

At DNS Belgium we are also planning to implement a Registry Lock for .be, so I am definitely interested in developing a common standard. 

Given the limited interest (by registrants and/or registrars ?) seen at other registries, we plan to start with a mechamism that requires little development for the registry and 
little to no development effort for the registrars. 

We recently discussed several options with our Registrar Forum and this is what we came up with for an initial version: 

* a registry lock on a domain name can only be requested by the sponsoring registrar and only via the web interface and will not be visible nor updatable via EPP 
* the adminsitrative part (signing agreements, passing around contact details, etc) will be handled manually (exact procedures are still work-in-progress) 
* the registrant chooses who should be contacted when registrar requests to unlock the domain name 
=> IMO this offers the most flexibility: a registrant can choose to let his registrar handle the whole process or he can choose to be involved in the unlocking process himself 
* once the administrative part is handled, someone at the registry flags the registration as 'registry locked' 
=> no updates possible to linked registrant nor to the host attributes (NS and A records) of the domain name nor to the DS records (to be investigated if we would allow emergency key roll-overs) 
* the registrar requests (via the web interface) to unlock a domain name 
=> the registry seeks confirmation using the previously specified contact details. Upon confirmation: registry unlocks the domain name (TBD: indefinitely or for a limited time) 
* price: to be decided 

We don't foresee a two-factor authentication mechanism, although one could consider the pre-specified phonenumber as something you have. 
(We do however plan to add two-factor authentication to the registrar extranet, covering all possible transaction types not just those related to registry lock.) 

A further simplification (to speed up the roll-out) could be to handle lock and unlock requests entirely via the customer support system (and not via the registrar extranet). 

In a later phase (when the feature has enough success) we will consider to facilitate lock and unlock requests via EPP and to send EPP poll messages to notify the registrar when the lock or unlock has been approved. All of this of course preferably using a standardized EPP extension. 

Best regards, 

Maarten Bosteels 
Head of Development 
DNS Belgium 
+32 16 28 49 70 
www.dnsbelgium.be 

----- Original Message -----

| From: "Antoin Verschuren" <[email-masked]>
| To: "Michele Neylon - Blacknight" <[email-masked]>
| Cc: "<[email-masked]>" <[email-masked]>
| Sent: Thursday, 19 September, 2013 2:34:55 PM
| Subject: Re: [provreg] Registry lock - two-factor or intervention

| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1

| Op 19-09-13 11:22, Michele Neylon - Blacknight schreef:

| > This is not the general case, so your statement is biased.
| >
| >> So is your reaction :)

| Touche. :-).
| Just wanted to state that ICANN gTLD's are not the only norm. This is
| an IETF mailinglist. The IETF create standards, not ICANN contracts.

| > The role of the registrar is to offload administrative burden of
| > the registry, the registrar acts as an administrative agent for
| > the registrant.
| >
| >> Wow! That's actually incredibly offensive to registrars.

| Perhaps I'm just not a native speaker, and did not find a better term
| than burden, where I meant distribute administrative tasks to market
| players that are far better in communicating with end-customers.

| >> So any time there are *any* issues with *any* domains of any kind
| >> I can just send all the registrants, users and $random 3rd
| >> parties directly to the registry?

| I think it's the misunderstanding of the term "registrar" that has led
| and still leads to these strong statements.
| There are indeed a lot of entities that act as registrar in one of
| their roles that do a lot more than just that. They also act as
| dns-operator as a service to their customer, offer legal services, do
| website hosting, are a CA, or offer much more service to their
| customer, and do that well.
| But these extra services are not part of the pure registrar role in
| the model, as there are entities that act as registrar that do not
| offer these services, and it's important to clearly separate these
| roles when we need to come up with a clear model to base assumptions on.
| These entities are service providers, and one of their roles is acting
| as a registrar for those of their customers that are registrants.
| (They may have other customers that are not registrants). Registrar
| refers to the role, not to the entity.
| By administrative agent, I mean a registrar is responsible for all
| administrative, legal and financial communication and transactions
| between registrant and registry regarding the registration of a
| domain. The registrar represents the registry towards the registrant,
| and represents the registrant towards the registry.

| - --
| Antoin Verschuren

| Technical Policy Advisor SIDN
| Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

| P: +31 26 3525500 M: +31 6 23368970
| Mailto: [email-masked]
| XMPP: [email-masked]
| HTTP://www.sidn.nl/
| -----BEGIN PGP SIGNATURE-----
| Version: GnuPG v1.4.11 (GNU/Linux)

| iQEcBAEBAgAGBQJSOu9vAAoJEDqHrM883AgneqcH/3L3prtNQxfn1YwPb4pCCUs0
| 2v57k6bOlhvZKEPk0wDN6YzG/DkyAH8y6E5yqGuUp6esi2r3PH/hitdJ1HnxdDo7
| 0CKCUci9QFnGu3cwn/tBivm9e2VJ9ExOD0TwNGuVLEhNKmjX+IyN4viE17m6obzw
| rz0c/1fIYZYmoKfCSrVd1FchG0aWb9c49lY3VKQMItdkRBjogjz5U9SAezpVyCsU
| BcD0HXwGlwqrnlGi6JGUHzz3PH3LXXSXVxf7gLWHOL7yF5ocK6p5XRH0gCS01ipB
| +8z3ombUQ7qoF4ymjAQDLSITrSHlRtXObxMkFE9xbsue/tzBzPidA9bhjvIq+Rw=
| =X4fI
| -----END PGP SIGNATURE-----
| _______________________________________________
| provreg mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/provreg

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 20 Sep 2013 11:47:41 +0200

> * a registry lock on a domain name can only be requested by the sponsoring registrar and only via the web interface and will not be visible nor updatable via EPP 

Do separate "turn on" and "turn off" the lock which are in turn separated from making changes while the lock is in place.

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

> * the adminsitrative part (signing agreements, passing around contact details, etc) will be handled manually (exact procedures are still work-in-progress) 

Administrative part of turning on or off or making changes while the lock is set?

> => IMO this offers the most flexibility: a registrant can choose to let his registrar handle the whole process or he can choose to be involved in the unlocking process himself 

It is important that we have clear terminology here. You say "registrant chooses" but above you say (which I think is correct) that the registrar is turning things on.

I think what you say is that "registrant chooses, and this choice is sent from the registrar to the registry when the lock is turned on". Is that correct understanding of what you wrote?

> => the registry seeks confirmation using the previously specified contact details. Upon confirmation: registry unlocks the domain name (TBD: indefinitely or for a limited time) 

See above.

> A further simplification (to speed up the roll-out) could be to handle lock and unlock requests entirely via the customer support system (and not via the registrar extranet). 

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.

> In a later phase (when the feature has enough success) we will consider to facilitate lock and unlock requests via EPP and to send EPP poll messages to notify the registrar when the lock or unlock…

   Patrik

---

From: MICHAEL YOUNG <[email-masked]>
Date: Fri, 20 Sep 2013 08:59:40 -0400

Hi  Patrik

> 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…

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-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 20 Sep 2013 15:52:30 +0200

On 20 sep 2013, at 14:59, MICHAEL YOUNG <[email-masked]> wrote:

> 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.

...which I think is still a good goal.

> Registrars can already "lock" a domain through Client prohibited statuses.

Not in all TLDs. Don't just talk about gTLDs... ;-)

> 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.

Well, I see that as a potential denial of service attack. But my only point was that we should see the "Turn ON", "Turn OFF", "Make changes" as separate operations as they MIGHT require different mechanisms.

> 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. 

If you have an automated system, why implementing something else than EPP?

> 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…

Correct. And that is why it is so important to look in detail on each operation and define what can be done to secure it.

I would say that we need two different communication mechanisms where at least one, if not two, humans are involved to do some changes that have to do with these locks.

   Patrik

---

From: MICHAEL YOUNG <[email-masked]>
Date: Fri, 20 Sep 2013 11:27:59 -0400

> If you have an automated system, why implementing something else than EPP?

Different reasons in different use cases, but really non EPP APIs (I think anyways) come into play when you are dealing with arm's length associated actions or decisions that in turn trigger a core EPP call.

For one example, some registries are heading towards stronger identity verification, where the registrant must be examined by a third party (to both the registry and registrar) before a registration is allowed to be finalized.  I use the word finalized carefully, because while that verification occurs, one could using a pending create or one could also combine a typical registration with all the server prohibited statuses applied.  When the verification process is successfully done, a core EPP command then results in the registration going to a "regular" state - whatever that happens to be for that particular registry.

Registry Lock really is a product that happens to entail more than just firing a core EPP command, there are elements of identity verification, two party involvement, etc, all of which really happen outside the registry.  The final result of all that activity is that a core EPP command is triggered to apply Server prohibited statuses or to remove them.  During most of the lead up process, I have no real need or desire to talk with an EPP server, just at the end of the decision making.

The actual functionality of an EPP Server is relatively straight-forward, when you think of comparative large systems, which a really good thing in an infrastructure system.  I think if we are to hope to successfully standardize extensions, we should be critical of which elements of proposed extension use cases really need to involve an EPP server, and which are better served as an external system.

That said, don't get me wrong, I'm all for standardization whenever we can achieve it.

MICHAEL YOUNG
[email-masked]

---

From: Stuart Olmstead-Wilcox <[email-masked]>
Date: Fri, 20 Sep 2013 15:41:38 -0400

Hi,

At CIRA we are also currently developing our business requirements and initial design of a Registry Lock service for .CA.  The question and discussion of a common epp extension / implementation approach not only for Registry Lock, but for the exposure of value-add or additional services per domain is something we are very interested in as well.

>From where we currently are in our analysis, I am also in agreement that is seems logical to leverage epp for the setting of the lock itself.

There does, however, look to be an intrinsic requirement for a separately authenticated step prior to the rar being allowed to set the server flags via epp - and also prior to removal of the flags to allow for domain modification.

The question of whether these separately authenticated steps should be automated (epp or other) or manual (person to person) is something we are quite focused on at the moment and would definitely invite feedback or real-world experience on either approach.

As I mentioned above, we are also looking at how best to generally expose services that can be applied / added onto domains - to rar's.  These services could be Registry Lock, or any other value added service.   If there any extensions out there that someone has put together for this purpose I would be very interested to learn more about them as well.

In either case, we are interested in participating in the discussion and development of standardized approaches as well.

Thanks,
Stu

STU OLMSTEAD-WILCOX. Development Manager
Canadian Internet Registration Authority (CIRA)
(613) 237-5335 x265

From: [email-masked] [mailto:[email-masked]] On Behalf Of MICHAEL YOUNG
Sent: September-20-13 11:28 AM
To: Patrik Fältström
Cc: Maarten Bosteels; provreg
Subject: Re: [provreg] Registry lock - two-factor or intervention

MICHAEL YOUNG
[email-masked]<mailto:[email-masked]>

---

From: Jay Daley <[email-masked]>
Date: Sat, 21 Sep 2013 17:53:29 +1200

> Well, I see that as a potential denial of service attack. But my only point was that we should see the "Turn ON", "Turn OFF", "Make changes" as separate operations as they MIGHT require different m…

There's quite a big risk here that a hacker compromises a registrar, switches a domain name to a compromised site and then locks the record, which makes undoing the malicious change much harder when the registrar regains control of their systems.

Jay

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Sep 2013 08:14:21 +0200

> There's quite a big risk here that a hacker compromises a registrar, switches a domain name to a compromised site and then locks the record, which makes undoing the malicious change much harder whe…

Correct, what I would say a "denial of service attack". :-P

My point is still that the various operations should be investigated individually. Nothing more, nothing less.

   Patrik

---

From: Jan Saell <[email-masked]>
Date: Sat, 21 Sep 2013 08:22:59 +0200

Hi all,

Here at iis we are have the registry lock implemented as a manual option
(pricey) and is in the process of developing an automatic registry lock
function.

The lock is implemented using the ServerProhobited flags so it is
visible in EPP (info), and we are setting the flags so that no change
are able to be done over EPP except renew.

The lock can be set by a registrar by sending in a form (handled
manually) and can be removed by another form. To validate the unlock
request we are calling the registrar manually today.

The automatic system will use a strong login mechanism to a web based
system where changes (lock and unlock) can be set.

Our opinion currently is that the lock is there to avoid a registrant
system being hacked and therefore is using this OOB method.

We also think that its more unlikely that a registrar will do changes by
mistake if they have to do this OOB unlock method as it requires extra
step and hopefully will make them think twice before doing it.

Currently we are aiming the pricing to be free for all registrars when
we have it as a automatic procedure.

Best regards

Jan Saell

On 09/20/2013 09:41 AM, Maarten Bosteels wrote:
> Hi all,
> 
> At DNS Belgium we are also planning to implement a Registry Lock for
> .be, so I am definitely interested in developing a common standard.
> 
> Given the limited interest (by registrants and/or registrars ?) seen at
> other registries, we plan to start with a mechamism that requires little
> development for the registry and 
> We recently discussed several options with our Registrar Forum and this
> is what we came up with for an initial version:
> 
> * a registry lock on a domain name can only be requested by the
> sponsoring registrar and only via the web interface and will not be
> visible nor updatable via EPP
> * the adminsitrative part (signing agreements, passing around contact
> details, etc) will be handled manually  (exact procedures are still
> work-in-progress)
>   => IMO this offers the most flexibility:  a registrant can choose to
> let his registrar handle the whole process or he can choose to be
> involved in the unlocking process himself
>   => no updates possible to linked registrant nor to the host attributes
> (NS and A records) of the domain name nor to the DS records (to be
> investigated if we would allow emergency key roll-overs)
>    => the registry seeks confirmation using the previously specified
> contact details.  Upon confirmation:  registry unlocks the domain name
> (TBD:  indefinitely or for a limited time)
> * price:  to be decided
> 
> We don't foresee a two-factor authentication mechanism, although one
> could consider the pre-specified phonenumber as something you have.
> (We do however plan to add two-factor authentication to the registrar
> extranet, covering all possible transaction types not just those related
> to registry lock.)
> 
> A further simplification (to speed up the roll-out) could be to handle
> lock and unlock requests entirely via the customer support system (and
> not via the registrar extranet).
> 
> In a later phase (when the feature has enough success) we will consider
> to facilitate lock and unlock requests via EPP and to send EPP poll
> messages to notify the registrar when the lock or unlock has been
> approved. All of this of course preferably using a standardized EPP
> extension.
> 
> Best regards,
> 
> Maarten Bosteels
> Head of Development
> DNS Belgium
> +32 16 28 49 70 <tel:%2B32%2016%2028%2049%2070>
> *www.dnsbelgium.be <http://www.dnsbelgium.be/>*
> 

- -- 
+-------------------------------------------------------------------
! Irial / YASK AB
! Att: Jan Saell
! Box 59, S-692 21 KUMLA, SWEDEN
! Tel: 019-58 25 15     Int +46-19 58 25 15     Fax +46-19 58 38 05
! E-mail: [email-masked]
! PGP Fingerprint: E957 23C8 9F51 0958 B9AD  7F18 404A 5DA1 F944 A08B

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 21 Sep 2013 08:40:43 +0200

> system being hacked and therefore is using this OOB method.

Registrant system?

   paf

---

From: Jan Saell <[email-masked]>
Date: Sat, 21 Sep 2013 09:24:32 +0200

Sorry - registrar system

- --