Patrick, I provide responses to your feedback below.
-- 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/25/19, 1:46 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: 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. JG - The authorization information is an important element of the EPP RFCs to securely transfer domain names (and contacts), so defining the operational practice for securing the authorization information using the existing EPP RFCs is very relevant. Your feedback is welcome and encouraged. 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. JG - I address this feedback in my response to Jody Kolker's message, so let me know whether the explanation and revised text does not handle the use case. 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). JG - The draft does not change what is currently supported by the EPP RFCs, but simply defines a best practice that servers can implement to secure the authorization information. I believe the policies of the server can best be described in the Registry Mapping (draft-gould-carney-regext-registry ) or a policy extension to the Registry Mapping. I will consider how draft-gould-regext-secure-authinfo-transfer can be described via the Registry Mapping. > 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. JG - The draft defines an operational practice. > 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 - Correct, EPP does define the passing of the authorization information in clear text over an encrypted channel. The storage of the authorization information is an important factor for its security. > 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. JG - It is meant to start the discussion of how to secure the authorization information, so if there are other cases or approaches to consider, they can be incorporated into the draft. > 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. JG - I have implemented support for the authorization information roid attribute to authorize as domain transfer using the registrant contact authorization information. The approach defined in draft-gould-carney-regext-registry is also applied to the authorization information of contacts, so there is no problem passing the plain text contact authorization information that would be hashed by the registry for comparison to the contact's hashed authorization information on a domain transfer. > 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. JG - The approach defined in draft-gould-carney-regext-registry can be applied to any TLD to secure the authorization information for a secure transfer. The entire transfer process (e.g., form of authorization, immediate transfer) is out of scope for draft-gould-carney-regext-registry, since its limited to the authorization information. -- 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
