I think the draft is a good idea since the handling of AUTHINFO is a sensitive topic.
A Best Practice is certainly useful to help avoid blind spots regarding security regarding AUTHINFO implementing the EPP RFC's, or at least to be aware of the "state of the art" / benchmark regarding security dealing with AUTHINFO. So conscious decisions about following or not following it can be made. Martin On 29.07.19 22:59, Gould, James wrote: > > I will respond to Patrick’s full feedback separately, but I’ll address > the one item raised below in response to Jody’s feedback. From a > higher-level, draft-gould-regext-secure-authinfo is intended to > provide the starting point for discussion of how to secure the > authorization information for transfers. > > > > I pulled Patrick's original feedback on the authorization information > storage language of the draft below: > > > > I would also suggest or offer the idea that various points in the > draft (like "the authorization information .... MUST NOT be stored by > the registrar.") do not align (which means: will never happen) with > various registrars policies or architectures. > > That one for example shows itself in later parts: > > 5. Gaining registrar optionally verifies the authorization > > information with the info command to the registry, as > defined in > > Section 4.3. > > 6. Gaining registrar sends the transfer request with the > > authorization information to the registry, as defined in > > Section 4.4. > > > > This feedback is associated with the following sentence of the draft: > > > > To protect the disclosure of the authorization information, the > authorization information MUST be stored by the registry using a > strong one-way cryptographic hash and MUST NOT be stored by the registrar. > > > > The intent of the “MUST NOT be stored by the registrar” is for the > losing registrar and not the gaining registrar, since the losing > registrar should simply generate the authorization information and > provide it to the registry and the registrant. There is no reason for > the losing registrar to store the authorization information, since the > losing registrar can unset and set the authorization information at > any time. I can see architecturally where the gaining registrar may > need to store the authorization information as a “transient” value > (e.g., work queue item) to support the completion of the transfer > process. The registry will automatically unset the authorization > information upon a successful transfer, so the gaining registrar > storing the authorization information as a “durable” value (e.g., > beyond the transfer process) is not needed. > > > > How about changing the language in the draft to be more specific to > the intent, as in: > > > > To protect the disclosure of the authorization information, the > authorization information MUST be stored by the registry using a > strong one-way cryptographic hash, MUST NOT be stored by the losing > registrar, and MUST only be stored by the gaining registrar as a > “transient” value in support of the transfer process. > > > > Does this cover the use case presented? > > > > -- > > > > JG > > > > > > > > James Gould > > Distinguished Engineer > > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com <http://verisigninc.com/> > > > > On 7/26/19, 11:23 AM, "regext on behalf of Jody Kolker" > <regext-boun...@ietf.org on behalf of jkol...@godaddy.com> wrote: > > > > Regarding the drafts position of "the authorization information > .... MUST NOT be stored by the registrar." > > > > I agree that registrars will need the ability to store the > password for a request to transfer in a domain in some situations > (bulk transfers, network outages, registry maintence etc.). There > simply is no way around not storing the password to handle every > situation. > > > > As far as where this draft should be, I consider it only to be a > best practice draft, not anything that will significantly change EPP. > I would love to have some type of standard for transferring domains or > at least some type of communality between all of the TLDs, but I > believe that will be a pipe dream. Every TLD operator will believe > they have the "best" transfer implementation. > > > > If we could at least start with a discussion, maybe we could get > to similar transfer process for most TLDs. > > > > Would be curious to hear from other registrars and registrys on > this topic. > > > > Thanks, > > Jody Kolker > > > > -----Original Message----- > > From: regext <regext-boun...@ietf.org> On Behalf Of Patrick Mevzek > > Sent: Thursday, July 25, 2019 12:46 AM > > To: regext@ietf.org > > Subject: Re: [regext] FW: New Version Notification for > draft-gould-regext-secure-authinfo-transfer-00.txt > > > > Notice: This email is from an external sender. > > > > > > > > Hello James, > > > > On Mon, Jul 8, 2019, at 14:16, Gould, James wrote: > > > JG - The draft is a Best Current Practice (BCP) per RFC 2026, > and not > > > a standards track draft. The draft describes how to leverage the > > > existing EPP RFCs for addressing the security of the authorization > > > information value for transfers. EPP can have protocol extensions > > > defined as informational and standards track drafts, as well as > > > operational practices defined as BCP drafts. There are many > examples > > > of IETF BCPs. This topic is very applicable to the IETF and the > > > REGEXT working group in particular. > > > > I will remain in disagreement here (mandating how registries > should store passwords or choose them regarding length and complexity > is certainly a bigger issue than just EPP and has nothing to do > regarding how EPP works as an exchange protocol between 2 entities), > so I will only reply briefly as my contributions will not help > whatsoever building this draft and try to refrain from participating > in any future LC regarding this draft. > > > > I would also suggest or offer the idea that various points in the > draft (like "the authorization information .... MUST NOT be stored by > the registrar.") do not align (which means: will never happen) with > various registrars policies or architectures. > > That one for example shows itself in later parts: > > 5. Gaining registrar optionally verifies the authorization > > information with the info command to the registry, as > defined in > > Section 4.3. > > 6. Gaining registrar sends the transfer request with the > > authorization information to the registry, as defined in > > Section 4.4. > > > > Since both actions have no guarantee to happen back to back and > immediately (nor to be done by the same subsystems, from the same EPP > client, throught the same EPP connection), the registrar MUST store > the authorization somewhere. > > Think about connection issues or delayed payment (wish to check > authorization information even before taking the payment and starting > the transfer), etc. > > > > As is, this document will create interoperability problems in part > because it does not even define an extension visible at greeting. > > Without that, how could an EPP client know if the server follows > point 4.1 for example, which is even more troublesome because of its MAY? > > Without a clear indication, a client can continue sending a > password, and see its domain:create command be rejected, without even > knowing why (error reporting is not something sufficiently > standardized and stable across all registries for a client to base > itself on). > > > > > Things like that: > > > > > > > The operational practice will not require the client > > > > to store the authorization information and will > require the > > > > server to store the authorization information using a > > > > cryptographic hash. > > > > > > How the password is stored and handled at the registry is > completely > > > out of EPP scope. It could as well be symmetrically > encrypted, and I fail > > > to see even how this can be enforceable (how will you verify > remotely > > > how the registry stores the password?), as it is not > protocol related. > > > > > > JG - Why would the storage and handling of the authorization > > > information be out of EPP scope? > > > > Imagine a registry storing passwords as plain text and another > storing it encrypted through some clever mechanism deriving the key > from other registrars data (like its EPP password, that one never > being needed to echo back, so could be stored as an hash). > > > > What does that change for EPP? > > Absolutely nothing. > > > > > Do you agree that a cryptographic > > > hash is more secure than using an encrypted value? > > > > Irrelevant to EPP. The EPP schema clearly mandates for the > passwords (both login and authInfo) to be exchanged in clear text > (encapsulated in TLS of course). > > One can see now that things should be done differently, and I > could agree there. > > But this has no relationship with how the registry stores it. > > > > > JG - It's not meant to take into account all cases that exist today, > > > > That will then remain a big problem for me, as an implementer. > > > > > So in my views the current password based model per domain > has died, > > > and other solutions have to be searched for. Maybe there is > space to pursue > > > in solutions around OTP frameworks. > > > > > > JG - You may want to take a stab at defining an alternative > mechanism. > > > I believe that EPP does not need to be extended to make the > > > authorization information secure for transfers. > > > > Aside, remember that the current EPP schema already allows for > authorization to happen, not only by providing the domain authInfo but > instead the authInfo of a related contact (and its ROID to be able to > pinpoint it). > > > > And I seem to remember at least one registry to allow that. So > definitively rare but not 0 either. > > > > > Any ideas that you have to improve it would be greatly appreciated. > > > > Maybe, but for me this work is not a good fit inside this working > group or even the IETF. It may be a better fit for some ICANN groups, > in order to deliver some "consensus policies" document (but > remembering also at the same time that there is a world outside of > gTLDs....). In my view the whole process around transfers (and not > just talking here about the EPP transfer command) should be reviewed > and reworked. > > > > -- > > Patrick Mevzek > > p...@dotandco.com > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext -- --- SWITCH Martin Casanova, Domain Applications Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 55, direct +41 44 268 16 25 martin.casan...@switch.ch, www.switch.ch Working for a better digital world
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
