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

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 02 Jul 2019 00:56:43 -0500

On Tue, Jun 25, 2019, at 07:29, Gould, James wrote:
> The Extensible Provisioning Protocol (EPP) Secure Authorization 
> Information for Transfer (draft-gould-regext-secure-authinfo-transfer) 
> was posted to define a BCP for securing the authorization information 
> using the existing EPP RFCs.  The overall goal is to have strong, 
> random authorization information values, that are short-lived, and that 
> are either not stored or stored as cryptographic hash values.  Review 
> and feedback is appreciated.  

I have read your draft and while I can obviously share your operational
experiences and goals to address many shortcomings of current situation
I really believe that such document as written is not a good fit for an RFC,
nor even for the IETF place in general.

Why? Because it only discuss policies, and not protocol matters.
The fact that it does not define  any new EPP commands/objects nor EPP XML namespace
seems to hint clearly that this is not an EPP extension, that it has nothing
to do with the protocol.

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.

Or:

> and the sponsoring registrar MUST inform the
>   registrant of the TTL when the authorization information is provided
>   to the registrant.

Registrars exist that do not let registrant choose passwords at creation
(which also hopefully deter bad passwords) and just give it when requested,
for an outgoing  transfer (since it is basically useless for anything else).
So the TTL information will have no meaning to registrants.

Also all your process regarding TTLs force registrars to maintain state
(when they set the password) and a machinery to change it after expiration.
This does not provide them any gain, so there is 0 incentive for them to do that,
and could be only controlled by the registry.

It also absolutely does not take into account all cases that exist today,
and I see absolutely no reason why the IETF would suddenly be the judge of some
registries policies.
One example: some registries do not let registrars choose/set authInfo.
When a transfer has to be done, the current registrar needs to use a specific EPP command
to request the registry to generate a new authInfo (which can be obtained through
a followup domain:info), which the registrant will then use at the new registrar.
This authInfo has even some time to live.

Another example: after a successful transfer, the registry automatically changes
the authInfo.

I am not claiming this is better. Or worse. I am just saying that there are
various policies, and I see no reason for the IETF to order them from bad to good.

On the opposite side I would be more happy to see attempts to extend the authInfo.
It has clearly been designed from the beginning at being extensible:

   <complexType name="authInfoType">
    <choice>
      <element name="pw" type="eppcom:pwAuthInfoType"/>
      <element name="ext" type="eppcom:extAuthInfoType"/>
    </choice>
   </complexType>

and

     <complexType name="extAuthInfoType">
       <sequence>
         <any namespace="##other"/>
       </sequence>
     </complexType>

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.

Any work in this area needs for me to take also into account at least the related issues:
- registry lock services
- the whole transfer process (since authInfo serves only there), taking into account
that there may be rules applied to all gTLDs by virtue of their common contracts,
but then there are all the other registries.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Gavin Brown <[email-masked]>
Date: Tue, 2 Jul 2019 12:57:25 +0100

It's worth noting that there are "operational practices" RFCs (6781 being the obvious example) that do not describe a protocol, and are published as Informational documents. This document seems more like those than a protocol specification.

G.

> On 2 Jul 2019, at 06:56, Patrick Mevzek <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 02 Jul 2019 10:19:19 -0500

On Tue, Jul 2, 2019, at 06:57, Gavin Brown wrote:
> It's worth noting that there are "operational practices" RFCs (6781 
> being the obvious example) 

Yes, but they do not force any kind of specific policies.
They give recommendations and points to be taken into account, for sane choices.

For RFC6781, note how the introduction explains that the document **discusses** various points
they do not define anything.
Contrary to the draft being discussed that starts by saying:
"This document defines an operational practice"

Note also how the document you cite tries to take into account all existing
cases in the wild, not a subset of them. I have tried to show that the draft presented
just forgets about existing cases, which could hinder its wide adoption.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Jul 2019 19:15:24 +0000

Patrick,

Thank you for reading the draft and providing feedback.  I provide answers to your question embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 7/2/19, 1:56 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> 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.  

    
    
JG - Why would the storage and handling of the authorization information be out of EPP scope?  Do you agree that a cryptographic hash is more secure than using an encrypted value?  Use of a cryptographic hash is certainly a best practice when it comes to passwords, so why would it not also be for EPP authorization information values?    I don't believe that an IETF draft requires a form of enforcement.  This is certainly an EPP protocol practice, since it addresses the security of a transfer.  

    

JG - The TTL does have meaning to the registrant, since they must use the provided authorization information prior to the expiration of the TTL.  The registrant would need to know how long they have to submit the authorization information to the gaining registrar.  It is the losing registrar's choice what TTL to set, so it is the losing registrar's responsibility to inform the registrant of it.  

JG - The gain is reducing the likelihood of the hijacking of domain names.  The draft defines a practice where the registrars can control the TTL, which can be based on registrar-specified factors.    

JG - It's not meant to take into account all cases that exist today, but is meant to define a practice that can secure the authorization information for transfers using existing EPP RFCs.  I would be interested in learning more about the mechanism used to trigger the server into generating a new authorization information value and how the TTL is handled.  I believe the registrar and not the registry should be the one to generate the authorization information values.  

JG - I view having long-lived authorization information values as being less secure to clearing the authorization information value upon a successful transfer.  The authorization information value should only be set during the transfer process, which minimizes its risk to compromise. 

    
    
    and

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.  

JG - I view draft-gould-regext-secure-authinfo-transfer as a starting point to discuss the operation practice that registrars and registries (any registry) can take to secure the transfer using the existing EPP authorization information.  Any ideas that you have to improve it would be greatly appreciated.

    -- 
      Patrick Mevzek
      [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Thu, 25 Jul 2019 00:46:29 -0500

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).
 
> 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.

> 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
  [email-masked]

---

From: Jody Kolker <[email-masked]>
Date: Fri, 26 Jul 2019 15:23:12 +0000

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 <[email-masked]> On Behalf Of Patrick Mevzek
Sent: Thursday, July 25, 2019 12:46 AM
To: [email-masked]
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 
> 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.

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).

> 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).

> 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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 29 Jul 2019 20:59:38 +0000

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:

           Section 4.3.

           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

[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 7/26/19, 11:23 AM, "regext on behalf of Jody Kolker" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks,

    Jody Kolker

    -----Original Message-----

    To: [email-masked]

    Hello James,

           Section 4.3.

           Section 4.4.

    Absolutely nothing.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

    regext mailing list

    [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 29 Jul 2019 21:01:24 +0000

Patrick,

I provide responses to your feedback below.

-- 
 
JG

James Gould
Distinguished Engineer

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

On 7/25/19, 1:46 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

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.     

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.

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.      

    

JG - The draft defines an operational practice.

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 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.  

    

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.      

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
      [email-masked]