Skip to main content

Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer
RFC 9154

Yes

Murray Kucherawy
(Barry Leiba)

No Objection

Alvaro Retana
Warren Kumari
Éric Vyncke
(Martin Vigoureux)

Abstain


Note: This ballot was opened for revision 06 and is now closed.

Murray Kucherawy
Yes
Alvaro Retana
No Objection
Erik Kline
No Objection
Comment (2021-04-19 for -06)
[[ questions ]]

[ section 4.1 ]

* How does "the age of [RFC4086]" factor in to the calculation that yielded
  the "at least 128 bits of entropy" determination?  Is there an update
  to RFC 4086 that should be underway?


[[ nits ]]

[ section 4.3 ]

* "an NULL": consider "a NULL", matching section 4.4
Francesca Palombini
No Objection
Comment (2021-04-20 for -06)
Thank you for the work on this document. Also thanks to the shepherd Jody Kolker for explaining in the shepherd write up why this has been brought forward as std track, and doing the necessary XML checks. I only have one minor comment below.

Francesca


1. -----

   For an update command, the registry MUST allow for the setting and
   unsetting of the authorization information.  The registrar sets the
   authorization information by first generating a strong, random
   authorization information value, based on Section 4.1, and setting it
   in the registry in the update command.

FP: Curious case of copy-paste of this entire paragraph in Section 5.2.
Lars Eggert
No Objection
Comment (2021-04-14 for -06)
There are quite a few places where I think RFC2119 terms could be used to
add clarity. I highlighted a few in the "nits" below, but it would be good
to do an editing pass with an eye towards that.

Section 1, paragraph 4, comment:
>    The overall goal is to have strong, random authorization information
>    values, that are short-lived, and that are either not stored or
>    stored as a cryptographic hash values by the non-responsible parties.

The previous paragraph said "not stored by the client, and that are stored by
the server using a cryptographic hash", which is slightly different? Can the
client store or not?

Section 1, paragraph 4, comment:
>        securely.  The operational practice will not require the client
>        to store the authorization information and will require the

Will it "not require the client to store" or will it "require the client not to
store"? This is again slightly different to what was said above.

Section 4.1, paragraph 2, comment:
>    For authorization information to be secure, it MUST be generated
>    using a secure random value.  The authorization information is

Section 4 says "must be generated using a strong random value and have a short
time-to-live (TTL)", which is slightly different? (And also doesn't use an
uppercase MUST.)

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3, paragraph 3, nit:
>    A client that receives the namespace URI in the server's Greeting
>    extension services, can expect the following supported behavior by
>    the server:

The term "client ... can expect" is odd, since it doesn't really map to RFC2119
conformance levels and is hence unclear. Would suggest to rephrase as "a server
sending ... MUST implement".

Section 3, paragraph 4, nit:
>    A server that receives the namespace URI in the client's <login>
>    Command extension services, can expect the following supported
>    behavior by the client:

As above, suggest to rephrase "can expect".

Section 5.2, paragraph 7, nit:
>    Example of removing the "clientTransferProhibited" status and setting
>    the authorization information in an [RFC5731] domain name update
>    command.

Not a complete sentence. (Similar issues in other "Example of" paragraphs
below.)

Section 1, paragraph 3, nit:
-    that are stored by the server using a cryptographic hash to provide,
-                                                                       -
-    for secure authorization information used for transfers.  This
-   ----
+    that are stored by the server using a cryptographic hash to provide
+    secure authorization information used for transfers.  This

Section 3, paragraph 3, nit:
-    extension services, can expect the following supported behavior by
-                      -
+    extension services can expect the following supported behavior by

Section 4, paragraph 2, nit:
-    authorization information to be secure it must be generated using a
+    authorization information to be secure, it must be generated using a
+                                          +

Section 4.2, paragraph 2, nit:
-    authorization information by the sponsoring registrar, then the
-                                                              -----
+    authorization information by the sponsoring registrar, the

Section 4.2, paragraph 2, nit:
-    client policy may be based on proprietary registrar-specific criteria
+    client policy may be based on proprietary registrar-specific criteria,
+                                                                         +

Section 4.3, paragraph 3, nit:
-        256-bit hash function such as SHA-256 [FIPS-180-4], and with a
+        256-bit hash function, such as SHA-256 [FIPS-180-4], and with a
+                             +

Section 4.3, paragraph 3, nit:
-        an NULL (undefined) value is dependent on the type of database
-         -
+        a NULL (undefined) value is dependent on the type of database

Section 5, paragraph 2, nit:
-    To make the transfer process secure using secure authorization
-       ^^^                      -------
+    To secure the transfer process using secure authorization
+       ^^^^^

Section 5.2, paragraph 4, nit:
-    Because of this, registries may validate the randomness of the
-                                ^^^
+    Because of this, registries MAY validate the randomness of the
+                                ^^^

Section 5.2, paragraph 5, nit:
-    sufficiently strong.  Registrars, therefore, must be prepared for an
-                                                 ^^^^
+    sufficiently strong.  Registrars, therefore, MUST be prepared for an
+                                                 ^^^^

Section 5.2, paragraph 5, nit:
-    respond by generating a new value and trying again, possibly more
+    MUST respond by generating a new value and trying again, possibly more
+   +++++

Section 5.2, paragraph 6, nit:
-    Often the registrar has the "clientTransferProhibited" status set, so
+    Often, the registrar has the "clientTransferProhibited" status set, so
+         +

Section 5.2, paragraph 9, nit:
-    cancels the transfer process by unsetting the authorization
-          -
-    information value and may add back statuses like the
-                          ^^^
+    MUST cancel the transfer process by unsetting the authorization
+   +++++
+    information value and MAY add back statuses like the
+                          ^^^

Section 5.2, paragraph 9, nit:
-    "eppcom:pwAuthInfoType" element, can have an empty authorization
-                                   -
+    "eppcom:pwAuthInfoType" element can have an empty authorization

Section 6, paragraph 2, nit:
-    incremental steps of adoption.  The transtion steps are dependent on
+    incremental steps of adoption.  The transition steps are dependent on
+                                             +

Section 6.2, paragraph 3, nit:
-       and the update command to hash instead of encyrpting the
-                                                     -
+       and the update command to hash instead of encrypting the
+                                                    +

Section 6.2, paragraph 3, nit:
-       value with either a hashed or encyrpted authorization information
-                                         -
+       value with either a hashed or encrypted authorization information
+                                        +
Martin Duke
No Objection
Comment (2021-04-09 for -06)
In the third paragraph of (5.3) there is a roundabout way of saying how the registry responds to a valid info request by saying that it MUST NOT send no authorization value, or a non-empty authorization value. It would be more straightforward to say something like

"the registry MUST respond to a valid info request by the non-sponsoring registrar with an empty authorization value".
Robert Wilton
No Objection
Comment (2021-04-19 for -06)
Hi,

Thanks for this document.

I found it hard to understand what is actually being transferred in the title/abstract.  Perhaps this could be expanded a little to help readers who are not familiar with EPP.

I don't feel particularly strongly on this point, but when reviewing this document, I was wondering whether this document wouldn't be better published as informational rather than stds track, given that it seems to describe an operational practice of how an existing protocol (EPP) should be used.

Regards,
Rob
Roman Danyliw
No Objection
Comment (2021-04-20 for -06)
** Per Section 4.3:

-- Fully understanding that registrars and registries will set their own policies, are there any bounds that can be placed on the TTLs?  Specifically, would there be a case that a registrar would have a policy where the TTL is measured in weeks or months? I ask because a best practice around storing password (credentials) at rest would be to use PBKDF2 (or other computational expensive hashes) rather than straight SHA-256 to prevent offline attack after compromise.

-- Section 4.1 was explicit in making suggestions about the bits of entropy in the authorization information.  Is there additional guidance to provide on the size of the recommended salt?

** Section 5.2.  Editorial. First paragraph (“For an update command, …”) is duplicated twice.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Barry Leiba Former IESG member
Yes
Yes (for -06)

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06)

                            
Benjamin Kaduk Former IESG member
(was Discuss) Abstain
Abstain (2021-07-18)
Thank you for all the updates in response to my previous ballot position.

In the interest of letting the document move forward, I am balloting Abstain
because the document still contains behavior that, while fully specified,
seems to require additional conditional behavior in client implementations
that results in unnecessary fragility of implementation.  The responsible
AD and WG chairs should confirm that the WG does indeed have consensus to
have made this decision, but I have no other grounds to block the document's
publication once that consensus is confirmed.

Copying the point from my previous discuss ballot in order to provide specifics
on the behavior that prompts my Abstain position:

(2) There's also some text in Section 5.3 that I'd like to discuss briefly:

   The registry MUST NOT return any indication of whether the
   authorization information is set or unset to the non-sponsoring
   registrar by not returning the authorization information element in
   the response.  The registry MAY return an indication to the
   sponsoring registrar that the authorization information is set by
   using an empty authorization information value.  The registry MAY
   return an indication to the sponsoring registrar that the
   authorization information is unset by not returning the authorization
   information element.

This seems to be assigning semantics to both absent-authinfo and
empty-authinfo in the <info> response, but is giving *different* semantics
to the response-to-sponsoring-registrar and
response-to-non-sponsoring-registrar cases.  Is there precedent for
changing the semantics of the response based on the identity of the
client like this (not just changing the content of the response)?  Can
we come up with a scheme that provides consistent semantics to all
clients, perhaps based on <domain:null> vs empty <domain:pw> for
unset/set, leaving "element is absent" for the deliberately ambiguous
case?