> On 23 Apr 2019, at 05:12, Michael Bauland <[email protected]> wrote: > > Hi Rubens, Jim (btw is it now Jim or James?), and Quoc, > > thanks for you responses. > > On 19.04.2019 15:55, Gould, James wrote: >> 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? > > 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.
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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
