Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer
draft-ietf-regext-secure-authinfo-transfer-07

[Ballot comment]
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  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  vs empty  for
unset/set, leaving "element is absent" for the deliberately ambiguous
case?

[Ballot discuss]
(1) RFC 4086 does not state that "a high-security password must have at
least 49 bits of randomness or entropy" as is claimed in Section 4.1 of
this document.  It merely says that so much entropy is needed to have a
one-in-a-billion chance of success for successfully guessing in the
model laid out, and makes no statement about (absolute) "high" security.
I don't think we need to spend as much time on what RFC 4086 says as we
currently do, and could probably get to the "use at least 128 bits of
entropy" advice much sooner.

(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  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  vs empty  for
unset/set, leaving "element is absent" for the deliberately ambiguous
case?

(3) We may also need to discuss the efficacy of the transition plan, per
my comments in Sections 6.1 and 6.3 -- my current understanding is that
the proposed plan will break some existing workflows.  I am not sure if
that is intended, desirable, and/or tolerable, and welcome further
insight.

[Ballot comment]
I think that the introduction would benefit from expanding on the
high-level motivation for this work (which I assume to include): the
current/original lifecycle for authorization information involves
long-term storage of encrypted (not hashed) passwords, which presents a
significant latent risk of password compromise and is not consistent
with current best practices.  The mechanisms in this document provide a
way to avoid long-term password storage entirely, and to only require
the storage of hashed (not retrievable) passwords instead of encrypted
passwords.  (Or, in a more colloquial language, "passwords suck, and we
want to get out of the business of handling them to the extent
possible".)  The third paragraph does talk about the "overall goal", but
doesn't say much about what we're moving *away* from (and why).

I think giving some explicit consideration of the lifecycle and protocol
interactions for the password 'salt' would be helpful.  (That is, that
it's picked at random by the registry per password when a password is
set and never goes on the wire, but is stored alongside the hashed
password.)

The treatment in the introduction of "[use] the existing features of the
EPP RFCs" made me wonder why this needed to be on the standards-track,
as opposed to being an informational description of how to use what's
already there.  The actual core of the spec, which includes changes to
the semantics of some XML elements (e.g., in the info response), is
clearly protocol work, though, so perhaps the abstract/introduction
could be revisited to clarify the scope of the work.

Section 1

  "Strong Random Authorization Information":  The EPP RFCs define the
      password-based authorization information value using an XML
      schema "normalizedString" type, so they don't restrict what can
      be used in any way.  This operational practice defines the

I suggest s/in any way/in any substantial way/ (not being able to use
CR/LF/TAB is in some sense a restriction).

  "Short-Lived Authorization Information":  The EPP RFCs don't
      [...]
      upon a successful transfer.  All of these features can be
      supported by the EPP RFCs.

They can be supported, sure, but what about in practice?  Can we rely on
such functionality being present?

Section 3

  namespace URI in the login and greeting extension services.  The
  namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-
  1.0" is used to signal support for the operational practice.  The

Written in this way this is codepoint squatting, assuming that the
requested XML namespace value will be assigned.  Given that Section 8
implies this stuff is deployed already, there really should have been an
early allocation made.

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

  1.  Support an empty authorization information value with a create
      command.
  [...]

It's interesting to compare this to RFC 5731, that says "Authorization
information as described in Section 2.6 is REQUIRED to create a domain
object.  [...]  Failure to protect authorization information from
inadvertent disclosure can result in unauthorized transfer operations
and unauthorized information release.  [...]"  In some sense we are
introducing a rather significant philosophical change in the nature of
authorization information, that might be called out more prominently.

  7.  Support automatically unsetting the authorization information
      upon a successful completion of transfer.

Just "support", or actually will in practice?
(Probably applies to some of the other enumerated points as well, for
both client and server, though I think not to all of them.)

Section 4

  with the  element).  Other EPP objects that support
  password-based authorization information for transfer can use the
  Secure Authorization Information defined in this document.  For the

This is phrased just as "can use" (not "will use"), but we are
supposedly defining an XML namespace used for capability negotiation in
the initial EPP exchange, which really ought to have well-specified
semantics.  *Must* the secure authorization information defined in this
document be used for any applicable transfer, when the XML namespace we
define is in effect for the capabilities to use?

Section 4.1

  The strength of the random authorization information is dependent on
  the actual entropy of the underlying random number generator.  For
  the random number generator, the practices defined in [RFC4086] and
  section 4.7.1 of the NIST Federal Information Processing Standards
  (FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to produce
  random values that will be resistant to attack.  A random number
  generator (RNG) is preferable over the use of a pseudorandom number
  generator (PRNG) to reduce the predictability of the authorization
  information.  The more predictable the random number generator is,
  the lower the true entropy, and the longer the required length for
  the authorization information.

This is not really the advice that I would be giving, myself.
For one, using a true RNG is not necessarily better than a PRNG, since a
good PRNG will have a lot of well-thought-out "whitening" functionality
that makes the output fairly uniform.  A true RNG can be a true RNG
while still sampling from a non-uniform distribution and leaving
patterns in the output.  But more importantly, implementors of EPP are
highly unlikely to need to care about the entropy gathering practices
specified by NIST SP 140-2 and RFC 4086 -- they can and should just use
/dev/urandom!  RFC 4086 was written in a time when /dev/urandom was not
as reliable as it is nowadays, but the advice of "to obtain randon
numbers under Linux, Solaris, [...] all an application has to do is open
either /dev/random or /dev/urandom and read the desired number of
bytes" is arguably the most important guidance in it.  (There's also a
corresponding Windows API.)  If we don't think people will want to
implement a 94-character alphabet themselves, we can suggest the widely
available base64 encoding and say something like "read 18 bytes from
/dev/random and base64 encode it, which will produce 24 characters of
encoded output" or give the ROUNDUP(128/log2 64) math.  (I use 18 bytes
because that avoids base64 padding characters.)

Section 4.2

I strongly suggest giving some guidance to registrars on how to set the
TTL (presumably a week or a few days is doable for common/generic domain
transfers?).  The requirements in §4.3 are not really aligned with
current best practices for password hashing for long term storage
(which, admittedly, are designed for human-selected passwords and not
random ones), so clamping down the TTL is going to be helpful for
putting bounds on some classes of attack.

Section 4.3

I note that draft-ietf-kitten-password-storage is underway to write
down best practices for password hashing and storage.  It is probably
not mature enough to be used as a definitive reference yet, but could be
useful information.


  1.  The authorization information MUST be stored by the registry
      using a strong one-way cryptographic hash, with at least a
      256-bit hash function such as SHA-256 [FIPS-180-4], and with a
      random salt.

Typical password-hashing recommendations these days are things like
Argon2 (winner of https://www.password-hashing.net/) or PBKDF2 (for
somewhat more legacy systems).  The iteration count (and other
parameters, for Argon2) can be tweaked depending on the systems in
question and the esteimated strength of the password, but nobody is
doing just a single-iteration of (salted) SHA256.  I note that we
recently approved draft-ietf-lamps-crmf-update-algs that leaves in place
a requirement that the iteration count MUST be at least 100 (and adds
"SHOULD be as large as server performance will allow, typically at least
10,000").  If the intent is to take advantage of the special
considerations here about the nature of the passwords in question, in
order to diverge from password-hashing best practice, we should be
explicit about the intentional divergence.

  5.  The plain text version of the authorization information MUST NOT
      be written to any logs by the registrar or the registry, nor

nit: "the registrar" is perhaps ambiguous in this scenario where we have
both losing and gaining registrars.

Section 4.4

  1.  Any input authorization information value MUST NOT match an unset
      authorization information value.

Does this only apply to non-empty input authorization information?

  3.  A non-empty input authorization information value MUST be hashed
      and matched against the set authorization information value,
      which is stored using the same hash algorithm.

It might be worth a few sentences (not necessarily here) about
password-hashing-algorithm agility and what an algorithm transition
would look like.

Section 5.2

  Because of this, registries may validate the randomness of the
  authorization information based on the length and character set
  required by the registry.  For example, validating an authorization
  value contains a combination of upper-case, lower-case, and non-
  alphanumeric characters, in an attempt to assess the strength of the
  value, and return an EPP error result of 2202 if the check fails.

  Such checks are, by their nature, heuristic and imperfect, and may
  identify well-chosen authorization information values as being not
  sufficiently strong.  Registrars, therefore, must be prepared for an
  error response of 2202, "Invalid authorization information", and
  respond by generating a new value and trying again, possibly more
  than once.

I note for the record that we had an earlier conversation about this
behavior, and I still believe that it does not reflect a best practice
for minimizing the use of weak passwords.  That said, it is a
non-normative example, and we basically already had our discussion on
this topic, so there is no need to rehash it again -- this is a
non-blocking comment.

Section 6

  3.  Losing registrar retrieves the stored authorization information
      locally or queries the registry for authorization information

nit: I think s/retrieves the stored authorization information
locally/retrieves the locally stored authorization information/ helps
readability.

Section 6.1

How do these features interact with the presence (or absence) of the
secure-authinfo-transfer XML namespace in the /greeting exchange?

It seems like at least the "don't return the authorization information
in the info response" change, if unilaterally implemented by the
registry, would break the classic workflow for registrars that do not
store the authorization information locally and require retrieving it
from the registry.  (Or are they required to implement the ability to
re-set the authorization information with an update, so that recovery is
possible?)

Section 6.2

  Hash New Authorization Information Values:  Change the create command
      and the update command to hash instead of encyrpting the

nit: s/encyrpting/encrypting/

  Supporting Comparing Against Encrypted and Hashed Authorization
  Information:  Change the info command and the transfer request
      command to be able to compare a passed authorization information
      value with either a hashed or encyrpted authorization information
      value.

This seems to leave it implicit that the stored values in the registry
include an indication of whether they are encrypted or hashed.  This is
probably trivial to ensure, just by virtue of being formatted
differently, but is an important enough property that I would suggest
mentioning it specifically.

Section 6.3

As for the case in Section 6.1, are these changes contingent on the
negotiation of the use of secure-authinfo-transfer?  Disallowing the
creation of entries with non-empty authorization information values
seems like it would break existing clients that do not implement
secure-authinfo-transfer.  Is there some mechanism in place that is
going to make secure-authinfo-transfer (e.g., contractually) required to
implement for registrars?

Section 9

  Section 4.1 defines the use a secure random value for the generation
  of the authorization information.  The server SHOULD define policy
  related to the length and set of characters that are included in the
  randomization to target the desired entropy level, with the
  recommendation of at least 128 bits for entropy.  The authorization
  information server policy is communicated to the client using an out-
  of-band process.  The client SHOULD choose a length and set of
  characters that results in entropy that meets or exceeds the server
  policy.  A random number generator (RNG) is preferable over the use
  of a pseudorandom number generator (PRNG) when creating the
  authorization information value.

[my comment from above about RNG vs PRNG applies here as well.]

I am a little uneasy about the "SHOULD define policy", which may just
reflect a misundersanding of the text.  If this is just an
administrative policy that is written and read by humans, that is
probably useful, but how it interacts with mechanical enforcement (per
my previous comments) could spill over into a regime of giving normative
recommendations to do things that I do not believe are best practice.

  Section 4.2 defines the use of an authorization information Time-To-
  Live (TTL).  The registrar SHOULD only set the authorization
  information during the transfer process by the server support for

I guess I don't understand why this is only a SHOULD (and this same
requirement seems to appear in Section 4.2 as well).  Given that we
propose for the registry to reject creation with non-empty authorization
information, it doesn't seem too big of a change to require that
registrars also comply with this workflow.

  the end of the transfer process.  The registry MUST store the
  authorization information using a one-way cryptographic hash of at
  least 256 bits and with a random salt.  All communication that

[this text might have to change if the earlier comment about password
hashing techniques results in a textual change]

Section 11.1

(If my suggestion about RNG guidance is accepted, FIPS-140-2 will no
longer need to be a normative reference.)

I don't really understand why RFC 3688 is listed as normative but RFC
7451 is listed as informative -- on both cases they're only referenced
as the specification that created an IANA registry that we're getting
an allocation in.

[Ballot comment]
** 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.

[Ballot comment]
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.

[Ballot comment]
[[ 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

[Ballot comment]
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

[Ballot comment]
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
>    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
+                                        +

[Ballot comment]
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".

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-secure-authinfo-transfer-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registration space on the IETF XML registry located at:

https://www.iana.org/assignments/xml-registry/

a new registration is to be made as follows:

ID: epp:secure-authinfo-transfer-1.0
URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at:

https://www.iana.org/assignments/epp-extensions/

a new registration is to be made as follows:

Name of Extension: "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer"
Document status: Standards Track
Reference: [ RFC-to-be ]
Registrant Name and Email Address: IESG,
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-03-22):

From: The IESG
To: IETF-Announce
CC: Jody Kolker , barryleiba@gmail.com, draft-ietf-regext-secure-authinfo-transfer@ietf.org, jkolker@godaddy.com, regext-chairs@ietf.org, regext@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Extensible Provisioning
Protocol (EPP) Secure Authorization
  Information for Transfer'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-03-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
  use of authorization information to authorize a transfer.  Object-
  specific, password-based authorization information (see RFC 5731 and
  RFC 5733) is commonly used, but raises issues related to the
  security, complexity, storage, and lifetime of authentication
  information.  This document defines an operational practice, using
  the EPP RFCs, that leverages the use of strong random authorization
  information values that are short-lived, not stored by the client,
  and stored by the server using a cryptographic hash that provides for
  secure authorization information that can safely be used for object
  transfers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-secure-authinfo-transfer/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the requested type of RFC.  Discussions among the working group led us to agree that this RFC fit best in the "A Technical Specification is any description of a protocol, service, procedure, convention or format" described in Section 3.1 of RFC 2026.  It is included in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short-lived, that are not stored by the client, and that are stored using a cryptographic hash by the server to provide for secure authorization information used for transfers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document has been discussed within the regext working group with the authors addressing all comments by incorporating agreed upon changes into the document.  There was nothing worthy of noting during the WG Process. 


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

CentralNic has a working implementation in their production environment as well as two other gTLD registry systems, and two ccTLD registry systems.  Verisign has implemented a full client and server stub implementation.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shephard is Jody Kolker, jkolker@godaddy.com
Area Director is Barry Leiba, barryleiba@computer.org.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As document shepherd I have verified all XML examples against RFC 5730, RFC 5731 and RFC 5733.

All normative references have been verified.

No IPR disclosures have been submitted for this document.

I've reviewed the mailing lists for the regext working group and have found no remaining objections to this document.  I believe this document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Both authors have confirmed that all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It has been my observation that the WG as a whole understands and agrees with the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Document has been checked and corrected for all identified ID Nits. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Extensions for XML Namespace requested has been reviewed and verified that it is listed correctly in the document.
Extensions for the EPP Extension Registry has been reviewed and verified that it is listed correctly in the document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

I have performed validation on the XML schemas provided in the document using the publicly available XML validator available at https://github.com/james-f-gould/EPP-Unhandled-Namespaces/tree/master/xmlvalidator-1.1.0.0.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the requested type of RFC.  Discussions among the working group led us to agree that this RFC fit best in the "A Technical Specification is any description of a protocol, service, procedure, convention or format" described in Section 3.1 of RFC 2026.  It is included in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short-lived, that are not stored by the client, and that are stored using a cryptographic hash by the server to provide for secure authorization information used for transfers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document has been discussed within the regext working group with the authors addressing all comments by incorporating agreed upon changes into the document.  There was nothing worthy of noting during the WG Process. 


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

CentralNic has a working implementation in their production environment as well as two other gTLD registry systems, and two ccTLD registry systems.  Verisign has implemented a full client and server stub implementation.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shephard is Jody Kolker, jkolker@godaddy.com
Area Director is Barry Leiba, barryleiba@computer.org.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As document shepherd I have verified all XML examples against RFC 5730, RFC 5731 and RFC 5733.

All normative references have been verified.

No IPR disclosures have been submitted for this document.

I've reviewed the mailing lists for the regext working group and have found no remaining objections to this document.  I believe this document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Both authors have confirmed that all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It has been my observation that the WG as a whole understands and agrees with the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Document has been checked and corrected for all identified ID Nits. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Extensions for XML Namespace requested has been reviewed and verified that it is listed correctly in the document.
Extensions for the EPP Extension Registry has been reviewed and verified that it is listed correctly in the document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

I have performed validation on the XML schemas provided in the document using the publicly available XML validator available at https://github.com/james-f-gould/EPP-Unhandled-Namespaces/tree/master/xmlvalidator-1.1.0.0.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard is the requested type of RFC.  Discussions among the working group led us to agree that this RFC fit best in the "A Technical Specification is any description of a protocol, service, procedure, convention or format" described in Section 3.1 of RFC 2026.  It is included in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short-lived, that are not stored by the client, and that are stored using a cryptographic hash by the server to provide for secure authorization information used for transfers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The document has been discussed within the regext working group with the authors addressing all comments by incorporating agreed upon changes into the document.  There was nothing worthy of noting during the WG Process. 


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

CentralNic has a working implementation in their production environment as well as two other gTLD registry systems, and two ccTLD registry systems.  Verisign has implemented a full client and server stub implementation.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shephard is Jody Kolker, jkolker@godaddy.com
Area Director is Barry Leiba, barryleiba@computer.org.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

As document shepherd I have verified all XML examples against RFC 5730, RFC 5731 and RFC 5733.

All normative references have been verified.

No IPR disclosures have been submitted for this document.

I've reviewed the mailing lists for the regext working group and have found no remaining objections to this document.  I believe this document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

I have no specific concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Both authors have confirmed that all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It has been my observation that the WG as a whole understands and agrees with the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Document has been checked and corrected for all identified ID Nits. 

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

RFC 7451.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Extensions for XML Namespace requested has been reviewed and verified that it is listed correctly in the document.
Extensions for the EPP Extension Registry has been reviewed and verified that it is listed correctly in the document.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

I have performed validation on the XML schemas provided in the document using the publicly available XML validator available at https://github.com/james-f-gould/EPP-Unhandled-Namespaces/tree/master/xmlvalidator-1.1.0.0.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.

Technical Summary

This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short-lived, that are not stored by the client, and that are stored using a cryptographic hash by the server to provide for secure authorization information used for transfers.

Working Group Summary
draft-ietf-regext-secure-authinfo-transfer is on standards track.  This document defines operational practice for creation and storing of authorization information to be used for transfers of domains and contacts using existing RFCs.

Document Quality
The document has been discussed within the regext working group with the authors addressing all comments by incorporating agreed upon changes into the document.  After lengthy discussions, it was decided to submit the document as Standards Track instead of BCP.

CentralNic has a working implementation in their production environment as well as two other gTLD registry systems, and two ccTLD registry systems.  Verisign has implemented a full client and server stub implementation.

Personnel
Document Shephard is Jody Kolker, jkolker@godaddy.com
Area Director is Barry Leiba, barryleiba@computer.org.

Shepherd Comments
As document shepherd I have verified all XML examples against RFC 5730, RFC 5731 and RFC 5733.

All normative references have been verified.

No IPR disclosures have been submitted for this document.

I've reviewed the mailing lists for the regext working group and have found no remaining objections to this document.  I believe this document is ready for publication.