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
