Subject: [regext] 2nd factor for Login Security Extension for EPP

From: Michael Bauland <[email-masked]>
Date: Thu, 18 Apr 2019 14:23:50 +0200

Hi,

I was wondering if one could use the good idea to enhance the security
for EPP logins and take it one step further and add some additional
related feature: the introduction and support of 2-factor authentication.

While web-based logins are currently in the process of updating and
securing the login process by enforcing/allowing a second factor, this
is not really possible for EPP authentication. If you add an optional
field like "2fa" next to "pw" it could be used for a future 2nd factor.

What do you think about this? I am aware that 2fa is currently not in
use for automated processes (at least I'm not aware of this), but the
changes to the draft would be minimal now. The future possibility to
submit such a string during the log-in process on the other hand could
be of great benefit.

Best regards,

Michael

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeisser-Weg 9
                                 44227 Dortmund
                                 Germany

     Dipl.-Informatiker          Fon:    +49 231 9703-0
                                 Fax:    +49 231 9703-200
     Dr. Michael Bauland         SIP:    [email-masked]
     Software Development        E-mail: [email-masked]

                                 Register Court:
                                 Amtsgericht Dortmund, HRB 13728

                                 Chief Executive Officers:
                                 Dietmar Knipp, Elmar Knipp

---

From: Rubens Kuhl <[email-masked]>
Date: Thu, 18 Apr 2019 09:35:24 -0300

Do you mean 3rd or 4th, since most EPP systems already have two factors (password and certificate), and some of those also require IP whitelisting.

I believe we already have the tools for the job in this area. And if a registry wants to add some extra layer, the password field could be password12345678 where password is the shared secret and 12345678 is a time-varying part that the EPP clients need to fill according to that registry specification.

Rubens

> On 18 Apr 2019, at 09:23, Michael Bauland <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Fri, 19 Apr 2019 13:55:19 +0000

I mirror Rubens response, that there exists system-to-system multi-factor authentication for EPP with user name/password, client certificate, and client IP.  Does the definition of another second factor, such as TOTP in RFC 6238, applicable to EPP?  Michael, are you proposing the use of TOTP for EPP and do you have a concrete use case that you can share?   

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 4/18/19, 8:35 AM, "regext on behalf of Rubens Kuhl" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Rubens

---

From: "Pham, Quoc-Anh" <[email-masked]>
Date: Tue, 23 Apr 2019 01:48:22 +0000

Hi all,

I agree with James and Rubens. EPP is a machine to machine interface and not human to machine where a TOTP makes more sense. Whilst technically a registrar's EPP credentials can be compromised it would be less common that a registrar human's web login is compromised.

Regards,
Quoc

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Friday, April 19, 2019 11:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [regext] 2nd factor for Login Security Extension for EPP

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__verisigninc.com_&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=Cs3HUKoPRwjAS3hKFFmwQ9JIC9-ufbCKPoKP-3Ckaik&m=5PsDzFKeXsFD--SoQxJF8QdgE9sgWOJC7JwQmJxALPA&s=-AcLtfGWXgi68qMIRbMEjqLNH5u5sZnrqzmzRO7a8uY&e=> 

    

    
    Rubens

    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=Cs3HUKoPRwjAS3hKFFmwQ9JIC9-ufbCKPoKP-3Ckaik&m=5PsDzFKeXsFD--SoQxJF8QdgE9sgWOJC7JwQmJxALPA&s=ShG81TVhKIjGUvtBPxdkIyh74mwZCzUzalglknJ2ZvQ&e=

_______________________________________________
regext mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=Cs3HUKoPRwjAS3hKFFmwQ9JIC9-ufbCKPoKP-3Ckaik&m=5PsDzFKeXsFD--SoQxJF8QdgE9sgWOJC7JwQmJxALPA&s=ShG81TVhKIjGUvtBPxdkIyh74mwZCzUzalglknJ2ZvQ&e=

---

From: Michael Bauland <[email-masked]>
Date: Tue, 23 Apr 2019 10:12:24 +0200

Hi Rubens, Jim (btw is it now Jim or James?), and Quoc,

thanks for you responses.

> I mirror Rubens response, that there exists system-to-system multi-factor authentication for EPP with user name/password, client certificate, and client IP.  Does the definition of another second f…

I was not proposing any technique. I think the RFC should leave that to
the implementing registry. Nevertheless, yes I thought about TOTP when
writing my e-mail. I'm also aware that this does not fit EPP
out-of-the-box. As you say, it was designed having humans not machines
in mind. So there would have to be some adjustments to make that work.

However, you are all right, of course, that with IP whitelisting there
is already a good second factor of which I hadn't thought of.

Certificates on the other hand are not a secure factor as almost anybody
can obtain a valid certificate.

So, I concur that we already have a second factor and probably don't
need a third one in the new extension.

Best regards,

Michael

                                 Register Court:

---

From: Gavin Brown <[email-masked]>
Date: Tue, 23 Apr 2019 09:19:49 +0100

Hi Michael,

> can obtain a valid certificate.

A valid certificate provides a weak form of non-repudiation, so if an
attacker obtains (for example) a cert for example.com and uses it to do
bad stuff, then you can be reasonably certain that they have some
association with the owner or operator of that domain. One could imagine
that a server could require use of an EV cert to obtain a higher level
of assurance.

Server implementations can (and should) also tightly associate a cert
with a specific client identity, so a client that connects using a
certificate can only log in to a registrar account to which the
certificate has been associated. That's how CentralNic's implementation
works.

G.

--
Gavin Brown
Chief Innovation Officer
CentralNic Group plc (LSE:CNIC)
https://www.centralnicgroup.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 23 Apr 2019 07:02:36 -0300

> On 23 Apr 2019, at 05:12, Michael Bauland <[email-masked]> wrote:
> 

Certificates can be made as secure as one wants to. The two most common ways in the EPP ecosystem are:
1) Accept certificates from a number of established CAs, but tag an specific certificate as being authorised. So the authorisation does not rely only on the CN, but CN+specific public key.
2) Run your own private CA. This is what we do in both .br and our gTLD back-end, where we tailor the CN to be the registrar ID. BTW, it would be nice if ICANN run a CA that identified gTLD registrars in the gTLD space... but until they do, we have our own.

Rubens

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 26 Apr 2019 11:10:43 -0400

On Tue, Apr 23, 2019, at 05:02, Rubens Kuhl wrote:
> 1) Accept certificates from a number of established CAs, but tag an 
> specific certificate as being authorised. So the authorisation does not 
> rely only on the CN, but CN+specific public key.
> 2) Run your own private CA. This is what we do in both .br and our gTLD 
> back-end, where we tailor the CN to be the registrar ID. BTW, it would 
> be nice if ICANN run a CA that identified gTLD registrars in the gTLD 
> space... but until they do, we have our own.

3) the registry accepts any certificate, even self-signed ones.

It is maybe not common, but as secure as the previous ones: the registry
whitelists certificates in advance and out of band, and they are
associated specifically per registrar.

Hence the certificate content, and specifically the issuer part
does not matter a lot.

In that case it leaves the registrar free to organize itself how
he wants, either by generating a local self-signed certificate (one for all,
one per registry but key for all or one per registry with separate key), or
using one from a well-known CA.
If all registries start to maintain their own PKI then again it is
a maintenance nightmare for registrars (those connecting to multiple
registries).

I am not sure a new CA would help tremendously here. At least it just adds
an additional case for all registrars not dealing with only one gTLD
(because even if it exists I doubt that one could mandate all gTLD registries
to accept this CA and only this CA as it is a matter of trust and transitive
trust, so why should any gTLD registry trust unconditionnaly this new CA?)

-- 
  Patrick Mevzek
  [email-masked]