Re: [regext] FW: New Version Notification for draft-gould-regext-secure-authinfo-transfer-00.txt

[Martin Casanova <[e-mail]>]

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
>
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>  
>
> 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"
> <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> On Behalf Of Patrick Mevzek
>
>     Sent: Thursday, July 25, 2019 12:46 AM
>
>     To: [e-mail]
>
>     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
>
>       [e-mail]
>
>    
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext
>
>    
>
>     _______________________________________________
>
>     regext mailing list
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/regext
>
>    
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone [phone], direct [phone]
[e-mail], www.switch.ch 
 
Working for a better digital world