doc: Add RFC documents

1 files changed, 1143 insertions, 0 deletions

diff --git a/doc/rfc/rfc9154.txt b/doc/rfc/rfc9154.txt
new file mode 100644
index 0000000..cbe5879
--- /dev/null
+++ b/doc/rfc/rfc9154.txt
@@ -0,0 +1,1143 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Gould
+Request for Comments: 9154                                    R. Wilhelm
+Category: Standards Track                                 Verisign, Inc.
+ISSN: 2070-1721                                            December 2021
+
+
+Extensible Provisioning Protocol (EPP) Secure Authorization Information
+                              for Transfer
+
+Abstract
+
+   The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use
+   of authorization information to authorize a transfer of an EPP
+   object, such as a domain name, between clients that are referred to
+   as "registrars".  Object-specific, password-based authorization
+   information (see RFCs 5731 and 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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9154.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Conventions Used in This Document
+   2.  Registrant, Registrar, Registry
+   3.  Signaling Client and Server Support
+   4.  Secure Authorization Information
+     4.1.  Secure Random Authorization Information
+     4.2.  Authorization Information Time To Live (TTL)
+     4.3.  Authorization Information Storage and Transport
+     4.4.  Authorization Information Matching
+   5.  Create, Transfer, and Secure Authorization Information
+     5.1.  <Create> Command
+     5.2.  <Update> Command
+     5.3.  <Info> Command and Response
+     5.4.  <Transfer> Request Command
+   6.  Transition Considerations
+     6.1.  Transition Phase 1 - Features
+     6.2.  Transition Phase 2 - Storage
+     6.3.  Transition Phase 3 - Enforcement
+   7.  IANA Considerations
+     7.1.  XML Namespace
+     7.2.  EPP Extension Registry
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Extensible Provisioning Protocol (EPP) [RFC5730] defines the use
+   of authorization information to authorize a transfer of an EPP
+   object, such as a domain name, between clients that are referred to
+   as "registrars".  The authorization information is object specific
+   and has been defined in "Extensible Provisioning Protocol (EPP)
+   Domain Name Mapping" [RFC5731] and "Extensible Provisioning Protocol
+   (EPP) Contact Mapping" [RFC5733] as password-based authorization
+   information.  Other authorization mechanisms can be used, but in
+   practice the password-based authorization information has been used
+   at the time of object creation, managed with the object update, and
+   used to authorize an object transfer request.  What has not been
+   considered is the security of the authorization information, which
+   includes the complexity of the authorization information, the Time To
+   Live (TTL) of the authorization information, and where and how the
+   authorization information is stored.
+
+   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.
+
+   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 to provide secure authorization
+   information used for transfers.  This operational practice can be
+   used to support transfers of any EPP object, where the domain name
+   object as defined in [RFC5731] is used in this document for
+   illustration purposes.  Elements of the practice may be used to
+   support the secure use of the authorization information for purposes
+   other than transfer, but any other purposes and the applicable
+   elements are out of scope for this document.
+
+   The overall goal is to have strong, random authorization information
+   values that are short lived and are either not stored or stored as
+   cryptographic hash values by the non-responsible parties.  In a
+   registrant, registrar, and registry model, the registrant registers
+   the object through the registrar to the registry.  The registrant is
+   the responsible party, and the registrar and the registry are the
+   non-responsible parties.  EPP is a protocol between the registrar and
+   the registry, where the registrar is referred to as the "client" and
+   the registry is referred to as the "server".  The following are the
+   elements of the operational practice and how the existing features of
+   the EPP RFCs can be leveraged to satisfy them:
+
+   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 substantial way.  This operational practice
+       defines the recommended mechanism for creating a strong random
+       authorization value that would be generated by the client.
+
+   Short-Lived Authorization Information:  The EPP RFCs don't explicitly
+       support short-lived authorization information or a TTL for
+       authorization information, but there are EPP RFC features that
+       can be leveraged to support short-lived authorization
+       information.  All of these features are compatible with the EPP
+       RFCs, though not mandatory to implement.  As stated in
+       Section 2.6 of [RFC5731], authorization information is assigned
+       when a domain object is created, which results in long-lived
+       authorization information.  This specification changes the nature
+       of the authorization information from long lived to short lived.
+       If authorization information is set only when a transfer is in
+       process, the server needs to support an empty authorization
+       information value on create, support setting and unsetting
+       authorization information, and support automatically unsetting
+       the authorization information upon a successful transfer.  All of
+       these features can be supported by the EPP RFCs.
+
+   Storing Authorization Information Securely:  The EPP RFCs don't
+       specify where and how the authorization information is stored in
+       the client or the server, so there are no restrictions on
+       defining an operational practice for storing the authorization
+       information securely.  The operational practice will require the
+       client to not store the authorization information and will
+       require the server to store the authorization information using a
+       cryptographic hash with at least a 256-bit hash function, such as
+       SHA-256 [FIPS-180-4], and with a per-authorization information
+       random salt with at least 128 bits.  Returning the authorization
+       information set in an EPP info response will not be supported.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   XML [W3C.REC-xml-20081126] is case sensitive.  Unless stated
+   otherwise, XML specifications and examples provided in this document
+   MUST be interpreted in the character case presented in order to
+   develop a conforming implementation.
+
+   In examples, "C:" represents lines sent by a protocol client and "S:"
+   represents lines returned by a protocol server.  Indentation and
+   empty space in examples are provided only to illustrate element
+   relationships and are not a required feature of this protocol.
+
+   The examples reference XML namespace prefixes that are used for the
+   associated XML namespaces.  Implementations MUST NOT depend on the
+   example XML namespaces and instead employ a proper namespace-aware
+   XML parser and serializer to interpret and output the XML documents.
+   The example namespace prefixes used and their associated XML
+   namespaces include the following:
+
+   domain:  urn:ietf:params:xml:ns:domain-1.0
+
+   contact:  urn:ietf:params:xml:ns:contact-1.0
+
+2.  Registrant, Registrar, Registry
+
+   The EPP RFCs refer to "client" and "server", but when it comes to
+   transfers, there are three types of actors that are involved.  This
+   document will refer to these actors as "registrant", "registrar", and
+   "registry".  [RFC8499] defines these terms formally for the Domain
+   Name System (DNS).  The terms are further described below to cover
+   their roles as actors using the authorization information in the
+   transfer process of any object in the registry, such as a domain name
+   or a contact:
+
+   Registrant:  [RFC8499] defines the registrant as "an individual or
+       organization on whose behalf a name in a zone is registered by
+       the registry."  The registrant can be the owner of any object in
+       the registry, such as a domain name or a contact.  The registrant
+       interfaces with the registrar for provisioning the objects.  A
+       transfer is coordinated by the registrant to transfer the
+       sponsorship of the object from one registrar to another.  The
+       authorization information is meant to authenticate the registrant
+       as the owner of the object to the non-sponsoring registrar and to
+       authorize the transfer.
+
+   Registrar:  [RFC8499] defines the registrar as "a service provider
+       that acts as a go-between for registrants and registries."  The
+       registrar interfaces with the registrant for the provisioning of
+       objects, such as domain names and contacts, and with the
+       registries to satisfy the registrant's provisioning requests.  A
+       registrar may (1) directly interface with the registrant or
+       (2) indirectly interface with the registrant, typically through
+       one or more resellers.  Implementing a transfer using secure
+       authorization information extends through the registrar's
+       reseller channel up to the direct interface with the registrant.
+       The registrar's interface with the registries uses EPP.  The
+       registrar's interface with its reseller channel or the registrant
+       is registrar specific.  In the EPP RFCs, the registrar is
+       referred to as the "client", since EPP is the protocol used
+       between the registrar and the registry.  The sponsoring registrar
+       is the authorized registrar to manage objects on behalf of the
+       registrant.  A non-sponsoring registrar is not authorized to
+       manage objects on behalf of the registrant.  A transfer of an
+       object's sponsorship is from one registrar, referred to as the
+       "losing registrar", to another registrar, referred to as the
+       "gaining registrar".
+
+   Registry:  [RFC8499] defines the registry as "the administrative
+       operation of a zone that allows registration of names within that
+       zone."  The registry typically interfaces with the registrars
+       over EPP and generally does not interact directly with the
+       registrant.  In the EPP RFCs, the registry is referred to as the
+       "server", since EPP is the protocol used between the registrar
+       and the registry.  The registry has a record of the sponsoring
+       registrar for each object and provides the mechanism (over EPP)
+       to coordinate a transfer of an object's sponsorship between
+       registrars.
+
+3.  Signaling Client and Server Support
+
+   This document does not define a new protocol; rather, it defines an
+   operational practice using existing EPP features, where the client
+   and the server can signal support for the operational practice using
+   a 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
+   client includes the namespace URI in an <svcExtension> <extURI>
+   element of the <login> command [RFC5730].  The server includes the
+   namespace URI in an <svcExtension> <extURI> element of the greeting
+   [RFC5730].
+
+   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 for an empty authorization information value with a
+       <create> command.
+
+   2.  Support for unsetting authorization information with an <update>
+       command.
+
+   3.  Support for validating authorization information with an <info>
+       command.
+
+   4.  Support for not returning an indication of whether the
+       authorization information is set or unset to the non-sponsoring
+       registrar.
+
+   5.  Support for returning an empty authorization information value to
+       the sponsoring registrar when the authorization information is
+       set in an info response.
+
+   6.  Support for allowing the passing of a matching non-empty
+       authorization information value to authorize a transfer.
+
+   7.  Support for automatically unsetting the authorization information
+       upon successful completion of a transfer.
+
+   A server that receives the namespace URI in the client's <login>
+   command extension services can expect the following supported
+   behavior by the client:
+
+   1.  Support for the generation of authorization information using a
+       secure random value.
+
+   2.  Support for only setting the authorization information when a
+       transfer is in process.
+
+4.  Secure Authorization Information
+
+   The EPP RFCs ([RFC5731] and [RFC5733]) use password-based
+   authorization information to support transfer with the <domain:pw>
+   element [RFC5731] and with the <contact:pw> element [RFC5733].  Other
+   EPP objects that support password-based authorization information for
+   transfer can use secure authorization information as defined in this
+   document.  For authorization information to be secure, it must be
+   generated using a strong random value and have a short TTL.  The
+   security of the authorization information is defined in the following
+   sections.
+
+4.1.  Secure Random Authorization Information
+
+   For authorization information to be secure, it MUST be generated
+   using a secure random value.  The authorization information is
+   treated as a password, and the required length L of a password,
+   rounded up to the largest whole number, is based on the size N of the
+   set of characters and the desired entropy H, in the equation L =
+   ROUNDUP(H / log_2 N).  Given a target entropy, the required length
+   can be calculated after deciding on the set of characters that will
+   be randomized.  In accordance with current best practices and noting
+   that the authorization information is a machine-generated value, the
+   implementation SHOULD use at least 128 bits of entropy as the value
+   of H.  The lengths below are calculated using that value.
+
+   Calculation of the required length with 128 bits of entropy and with
+   the set of all printable ASCII characters except space (0x20), which
+   consists of the 94 characters 0x21-0x7E:
+
+   ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20
+
+   Calculation of the required length with 128 bits of entropy and with
+   the set of case-insensitive alphanumeric characters, which consists
+   of 36 characters (a-z A-Z 0-9):
+
+   ROUNDUP(128 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
+
+   The strength of the random authorization information is dependent on
+   the random number generator.  Suitably strong random number
+   generators are available in a wide variety of implementation
+   environments, including the interfaces listed in Sections 7.1.2 and
+   7.1.3 of [RFC4086].  In environments that do not provide interfaces
+   to strong random number generators, the practices defined in
+   [RFC4086] and Section 4.7.1 of the NIST Federal Information
+   Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be
+   followed to produce random values that will be resistant to attack.
+   (Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3
+   does not contain information regarding random number generators.)
+
+4.2.  Authorization Information Time To Live (TTL)
+
+   The authorization information SHOULD only be set when a transfer is
+   in process.  This implies that the authorization information has a
+   TTL by which the authorization information is cleared when the TTL
+   expires.  The EPP RFCs do not provide definitions for TTL, but since
+   the server supports the setting and unsetting of the authorization
+   information by the sponsoring registrar, the sponsoring registrar can
+   apply a TTL based on client policy.  The TTL client policy may be
+   based on proprietary registrar-specific criteria, which provides for
+   a transfer-specific TTL tuned for the particular circumstances of the
+   transaction.  The sponsoring registrar will be aware of the TTL, and
+   the sponsoring registrar MUST inform the registrant of the TTL when
+   the authorization information is provided to the registrant.
+
+4.3.  Authorization Information Storage and Transport
+
+   To protect the disclosure of the authorization information, the
+   following requirements apply:
+
+   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 per-
+       authorization information random salt with at least 128 bits.
+
+   2.  An empty authorization information value MUST be stored as an
+       undefined value that is referred to as a "NULL" value.  The
+       representation of a NULL (undefined) value is dependent on the
+       type of database used.
+
+   3.  The authorization information MUST NOT be stored by the losing
+       registrar.
+
+   4.  The authorization information MUST only be stored by the gaining
+       registrar as a "transient" value in support of the transfer
+       process.
+
+   5.  The plain-text version of the authorization information MUST NOT
+       be written to any logs by a registrar or the registry, nor
+       otherwise recorded where it will persist beyond the transfer
+       process.
+
+   6.  All communication that includes the authorization information
+       MUST be over an encrypted channel (for example, see [RFC5734])
+       for EPP.
+
+   7.  The registrar's interface for communicating the authorization
+       information with the registrant MUST be over an authenticated and
+       encrypted channel.
+
+4.4.  Authorization Information Matching
+
+   To support the authorization information TTL, as described in
+   Section 4.2, the authorization information must have either a set or
+   unset state.  Authorization information that is unset is stored with
+   a NULL (undefined) value.  Based on the requirement to store the
+   authorization information using a strong one-way cryptographic hash,
+   as described in Section 4.3, authorization information that is set is
+   stored with a non-NULL hashed value.  The empty authorization
+   information value is used as input in both the <create> command
+   (Section 5.1) and the <update> command (Section 5.2) to define the
+   unset state.  The matching of the authorization information in the
+   <info> command (Section 5.3) and the <transfer> request command
+   (Section 5.4) is based on the following rules:
+
+   1.  Any input authorization information value MUST NOT match an unset
+       authorization information value.  For example, in [RFC5731] the
+       input <domain:pw>2fooBAR</domain:pw> must not match an unset
+       authorization information value that used <domain:null/> or
+       <domain:pw/>.
+
+   2.  An empty input authorization information value MUST NOT match any
+       set authorization information value.
+
+   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.
+
+5.  Create, Transfer, and Secure Authorization Information
+
+   To secure the transfer process using secure authorization information
+   as described in Section 4, the client and server need to implement
+   steps where the authorization information is set only when a transfer
+   is actively in process and ensure that the authorization information
+   is stored securely and transported only over secure channels.  The
+   steps for management of the authorization information for transfers
+   include the following:
+
+   1.  The registrant requests to register the object with the
+       registrar.  The registrar sends the <create> command with an
+       empty authorization information value to the registry, as
+       described in Section 5.1.
+
+   2.  The registrant requests from the losing registrar the
+       authorization information to provide to the gaining registrar.
+
+   3.  The losing registrar generates a secure random authorization
+       information value and sends it to the registry, as described in
+       Section 5.2, and then provides it to the registrant.
+
+   4.  The registrant provides the authorization information value to
+       the gaining registrar.
+
+   5.  The gaining registrar optionally verifies the authorization
+       information with the <info> command to the registry, as described
+       in Section 5.3.
+
+   6.  The gaining registrar sends the transfer request with the
+       authorization information to the registry, as described in
+       Section 5.4.
+
+   7.  If the transfer completes successfully, the registry
+       automatically unsets the authorization information; otherwise,
+       the losing registrar unsets the authorization information when
+       the TTL expires; see Section 5.2.
+
+   The following sections outline the practices of the EPP commands and
+   responses between the registrar and the registry that supports secure
+   authorization information for transfer.
+
+5.1.  <Create> Command
+
+   For a <create> command, the registry MUST allow the passing of an
+   empty authorization information value and MAY disallow the passing of
+   a non-empty authorization information value.  By having an empty
+   authorization information value on create, the object is initially
+   not involved in the transfer process.  Any EPP object extension that
+   supports setting the authorization information with an
+   "eppcom:pwAuthInfoType" element can pass an empty authorization
+   information value.  Examples of such extensions are found in
+   [RFC5731] and [RFC5733].
+
+   Example of passing an empty authorization information value in a
+   domain name <create> command [RFC5731]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <create>
+   C:      <domain:create
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:authInfo>
+   C:          <domain:pw/>
+   C:        </domain:authInfo>
+   C:      </domain:create>
+   C:    </create>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+   Example of passing an empty authorization information value in a
+   contact <create> command [RFC5733]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <create>
+   C:      <contact:create
+   C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
+   C:        <contact:id>sh8013</contact:id>
+   C:        <contact:postalInfo type="int">
+   C:          <contact:name>John Doe</contact:name>
+   C:          <contact:addr>
+   C:            <contact:city>Dulles</contact:city>
+   C:            <contact:cc>US</contact:cc>
+   C:          </contact:addr>
+   C:        </contact:postalInfo>
+   C:        <contact:email>jdoe@example.com</contact:email>
+   C:        <contact:authInfo>
+   C:          <contact:pw/>
+   C:        </contact:authInfo>
+   C:      </contact:create>
+   C:    </create>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+5.2.  <Update> Command
+
+   For an <update> command, the registry MUST allow 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 the information provided in
+   Section 4.1, and setting it in the registry in the <update> command.
+   The importance of generating strong authorization information values
+   cannot be overstated: secure transfers are very important to the
+   Internet to mitigate damage in the form of theft, fraud, and other
+   abuse.  It is critical that registrars only use strong, randomly
+   generated authorization information values.
+
+   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 that an
+   authorization value contains a combination of uppercase, lowercase,
+   and non-alphanumeric characters in an attempt to assess the strength
+   of the value and returning an EPP error result of 2202 ("Invalid
+   authorization information") [RFC5730] 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 and respond by generating a new value and
+   trying again, possibly more than once.
+
+   Often, the registrar has the "clientTransferProhibited" status set,
+   so to start the transfer process, the "clientTransferProhibited"
+   status needs to be removed, and the strong, random authorization
+   information value needs to be set.  The registrar MUST define a TTL,
+   as described in Section 4.2, and if the TTL expires, the registrar
+   will unset the authorization information.
+
+   Example of removing the "clientTransferProhibited" status and setting
+   the authorization information in a domain name <update> command
+   [RFC5731]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <update>
+   C:      <domain:update
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:rem>
+   C:          <domain:status s="clientTransferProhibited"/>
+   C:        </domain:rem>
+   C:        <domain:chg>
+   C:          <domain:authInfo>
+   C:            <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
+   C:            </domain:pw>
+   C:          </domain:authInfo>
+   C:        </domain:chg>
+   C:      </domain:update>
+   C:    </update>
+   C:    <clTRID>ABC-12345-XYZ</clTRID>
+   C:  </command>
+   C:</epp>
+
+   When the registrar-defined TTL expires, the sponsoring registrar MUST
+   cancel the transfer process by unsetting the authorization
+   information value and MAY add back statuses like the
+   "clientTransferProhibited" status.  Any EPP object extension that
+   supports setting the authorization information with an
+   "eppcom:pwAuthInfoType" element can pass an empty authorization
+   information value.  Examples of such extensions are found in
+   [RFC5731] and [RFC5733].  Setting an empty authorization information
+   value unsets the authorization information.  [RFC5731] supports an
+   explicit mechanism of unsetting the authorization information, by
+   passing the <domain:null> authorization information value.  The
+   registry MUST support unsetting the authorization information by
+   accepting an empty authorization information value and accepting an
+   explicit unset element if it is supported by the object extension.
+
+   Example of adding the "clientTransferProhibited" status and unsetting
+   the authorization information explicitly in a domain name <update>
+   command [RFC5731]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <update>
+   C:      <domain:update
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:add>
+   C:          <domain:status s="clientTransferProhibited"/>
+   C:        </domain:add>
+   C:        <domain:chg>
+   C:          <domain:authInfo>
+   C:            <domain:null/>
+   C:          </domain:authInfo>
+   C:        </domain:chg>
+   C:      </domain:update>
+   C:    </update>
+   C:    <clTRID>ABC-12345-XYZ</clTRID>
+   C:  </command>
+   C:</epp>
+
+   Example of unsetting the authorization information with an empty
+   authorization information value in a domain name <update> command
+   [RFC5731]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <update>
+   C:      <domain:update
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:add>
+   C:          <domain:status s="clientTransferProhibited"/>
+   C:        </domain:add>
+   C:        <domain:chg>
+   C:          <domain:authInfo>
+   C:            <domain:pw/>
+   C:          </domain:authInfo>
+   C:        </domain:chg>
+   C:      </domain:update>
+   C:    </update>
+   C:    <clTRID>ABC-12345-XYZ</clTRID>
+   C:  </command>
+   C:</epp>
+
+   Example of unsetting the authorization information with an empty
+   authorization information value in a contact <update> command
+   [RFC5733]:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <update>
+   C:      <contact:update
+   C:        xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
+   C:        <contact:id>sh8013</contact:id>
+   C:        <contact:chg>
+   C:          <contact:authInfo>
+   C:            <contact:pw/>
+   C:          </contact:authInfo>
+   C:        </contact:chg>
+   C:      </contact:update>
+   C:    </update>
+   C:    <clTRID>ABC-12345-XYZ</clTRID>
+   C:  </command>
+   C:</epp>
+
+5.3.  <Info> Command and Response
+
+   For an <info> command, the registry MUST allow the passing of a non-
+   empty authorization information value for verification.  The gaining
+   registrar can pre-verify the authorization information provided by
+   the registrant prior to submitting the transfer request with the use
+   of the <info> command.  The registry compares the hash of the passed
+   authorization information with the hashed authorization information
+   value stored for the object.  When the authorization information is
+   not set or the passed authorization information does not match the
+   previously set value, the registry MUST return an EPP error result
+   code of 2202 [RFC5730].
+
+   Example of passing a non-empty authorization information value in a
+   domain name <info> command [RFC5731] to verify the authorization
+   information value:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <info>
+   C:      <domain:info
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example.com</domain:name>
+   C:        <domain:authInfo>
+   C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
+   C:          </domain:pw>
+   C:        </domain:authInfo>
+   C:      </domain:info>
+   C:    </info>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+   The info response in object extensions, such as those defined in
+   [RFC5731] and [RFC5733], MUST NOT include the optional authorization
+   information element with a non-empty authorization value.  The
+   authorization information is stored as a hash in the registry, so
+   returning the plain-text authorization information is not possible,
+   unless valid plain-text authorization information is passed in the
+   <info> command.  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.
+
+   Example of returning an empty authorization information value in a
+   domain name info response [RFC5731] to indicate to the sponsoring
+   registrar that the authorization information is set:
+
+   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   S:  <response>
+   S:    <result code="1000">
+   S:      <msg>Command completed successfully</msg>
+   S:    </result>
+   S:    <resData>
+   S:      <domain:infData
+   S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   S:        <domain:name>example.com</domain:name>
+   S:        <domain:roid>EXAMPLE1-REP</domain:roid>
+   S:        <domain:status s="ok"/>
+   S:        <domain:clID>ClientX</domain:clID>
+   S:        <domain:authInfo>
+   S:          <domain:pw/>
+   S:        </domain:authInfo>
+   S:      </domain:infData>
+   S:    </resData>
+   S:    <trID>
+   S:      <clTRID>ABC-12345</clTRID>
+   S:      <svTRID>54322-XYZ</svTRID>
+   S:    </trID>
+   S:  </response>
+   S:</epp>
+
+5.4.  <Transfer> Request Command
+
+   For a <transfer> request command, the registry MUST allow the passing
+   of a non-empty authorization information value to authorize a
+   transfer.  The registry compares the hash of the passed authorization
+   information with the hashed authorization information value stored
+   for the object.  When the authorization information is not set or the
+   passed authorization information does not match the previously set
+   value, the registry MUST return an EPP error result code of 2202
+   [RFC5730].  Whether the transfer occurs immediately or is pending is
+   up to server policy.  When the transfer occurs immediately, the
+   registry MUST return the EPP success result code of 1000 ("Command
+   completed successfully") [RFC5730], and when the transfer is pending,
+   the registry MUST return the EPP success result code of 1001
+   ("Command completed successfully; action pending").  The losing
+   registrar MUST be informed of a successful transfer request using an
+   EPP <poll> message.
+
+   Example of passing a non-empty authorization information value in a
+   domain name <transfer> request command [RFC5731] to authorize the
+   transfer:
+
+   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
+   C:  <command>
+   C:    <transfer op="request">
+   C:      <domain:transfer
+   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
+   C:        <domain:name>example1.com</domain:name>
+   C:        <domain:authInfo>
+   C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
+   C:          </domain:pw>
+   C:        </domain:authInfo>
+   C:      </domain:transfer>
+   C:    </transfer>
+   C:    <clTRID>ABC-12345</clTRID>
+   C:  </command>
+   C:</epp>
+
+   Upon successful completion of the transfer, the registry MUST
+   automatically unset the authorization information.  If the transfer
+   request is not submitted within the TTL (Section 4.2) or the transfer
+   is canceled or rejected, the registrar MUST unset the authorization
+   information, as described in Section 5.2.
+
+6.  Transition Considerations
+
+   The goal of the transition considerations is to minimize the impact
+   to the registrars in supporting the Secure Authorization Information
+   Model defined in this document by supporting incremental transition
+   steps.  The transition steps are dependent on the starting point of
+   the registry.  Registries may have different starting points, since
+   some of the elements of the Secure Authorization Information Model
+   may have already been implemented.  The considerations assume a
+   starting point, referred to as the "Classic Authorization Information
+   Model", which incorporates the following steps for management of the
+   authorization information for transfers:
+
+   1.  The registrant requests to register the object with the
+       registrar.  The registrar sends the <create> command, with a non-
+       empty authorization information value, to the registry.  The
+       registry stores the authorization information as an encrypted
+       value and requires a non-empty authorization information value
+       for the life of the object.  The registrar may store the long-
+       lived authorization information.
+
+   2.  At the time of transfer, the registrant requests from the losing
+       registrar the authorization information to provide to the gaining
+       registrar.
+
+   3.  The losing registrar retrieves the locally stored authorization
+       information or queries the registry for authorization information
+       using the <info> command, and provides it to the registrant.  If
+       the registry is queried, the authorization information is
+       decrypted and the plain-text authorization information is
+       returned in the info response to the registrar.
+
+   4.  The registrant provides the authorization information value to
+       the gaining registrar.
+
+   5.  The gaining registrar optionally verifies the authorization
+       information with the <info> command to the registry, by passing
+       the authorization information in the <info> command to the
+       registry.
+
+   6.  The gaining registrar sends the transfer request with the
+       authorization information to the registry.  The registry will
+       decrypt the stored authorization information to compare to the
+       passed authorization information.
+
+   7.  If the transfer completes successfully, the authorization
+       information is not touched by the registry and may be updated by
+       the gaining registrar using the <update> command.  If the
+       transfer is canceled or rejected, the losing registrar may reset
+       the authorization information using the <update> command.
+
+   The gaps between the Classic Authorization Information Model and the
+   Secure Authorization Information Model include the following:
+
+   1.  Registry requirement for a non-empty authorization information
+       value on create and for the life of the object versus the
+       authorization information not being set on create and only being
+       set when a transfer is in process.
+
+   2.  Registry not allowing the authorization information to be unset
+       versus providing support for unsetting the authorization
+       information in the <update> command.
+
+   3.  Registry storing the authorization information as an encrypted
+       value versus a hashed value.
+
+   4.  Registry support for returning the authorization information
+       versus not returning the authorization information in the info
+       response.
+
+   5.  Registry not touching the authorization information versus the
+       registry automatically unsetting the authorization information
+       upon a successful transfer.
+
+   6.  Registry possibly validating a shorter authorization information
+       value using password complexity rules versus validating the
+       randomness of a longer authorization information value that meets
+       the required bits of entropy.
+
+   The transition can be handled in the three phases defined in
+   Sections 6.1, 6.2, and 6.3.
+
+6.1.  Transition Phase 1 - Features
+
+   The goal of "Transition Phase 1 - Features" is to implement the
+   needed features in EPP so that the registrar can optionally implement
+   the Secure Authorization Information Model.  The features to
+   implement are broken out by the commands and responses below:
+
+   <Create> Command:  Change the <create> command to make the
+      authorization information optional, by allowing both a non-empty
+      value and an empty value.  This enables a registrar to optionally
+      create objects without an authorization information value, as
+      described in Section 5.1.
+
+   <Update> Command:  Change the <update> command to allow unsetting the
+      authorization information, as described in Section 5.2.  This
+      enables the registrar to optionally unset the authorization
+      information when the TTL expires or when the transfer is canceled
+      or rejected.
+
+   Transfer Approve Command and Transfer Auto-Approve:  Change the
+      transfer approve command and the transfer auto-approve to
+      automatically unset the authorization information.  This sets the
+      default state of the object to not have the authorization
+      information set.  The registrar implementing the Secure
+      Authorization Information Model will not set the authorization
+      information for an inbound transfer, and the registrar
+      implementing the Classic Authorization Information Model will set
+      the new authorization information upon a successful transfer.
+
+   Info Response:  Change the <info> command to not return the
+      authorization information in the info response, as described in
+      Section 5.3.  This sets up the implementation of "Transition Phase
+      2 - Storage" (Section 6.2), since the dependency on returning the
+      authorization information in the info response will be removed.
+      This feature is the only one that is not an optional change to the
+      registrar, and this change could potentially break the client, so
+      it's recommended that the registry provide notice of the change.
+
+   <Info> Command and Transfer Request:  Change the <info> command and
+      the transfer request to ensure that a registrar cannot get an
+      indication that the authorization information is set or not set by
+      returning the EPP error result code of 2202 when comparing a
+      passed authorization to a non-matching set authorization
+      information value or an unset value.
+
+6.2.  Transition Phase 2 - Storage
+
+   The goal of "Transition Phase 2 - Storage" is to transition the
+   registry to use hashed authorization information instead of encrypted
+   authorization information.  There is no direct impact on the
+   registrars, since the only visible indication that the authorization
+   information has been hashed is that the set authorization information
+   is not returned in the info response, as addressed in "Transition
+   Phase 1 - Features" (Section 6.1).  Transitioning the authorization
+   information storage includes the following three steps:
+
+   Hash New Authorization Information Values:  Change the <create>
+      command and the <update> command to hash rather than encrypt the
+      authorization information.
+
+   Support Comparison against Encrypted or 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 encrypted authorization information
+      value.  This requires that the stored values be self-identifying
+      as being in hashed or encrypted form.
+
+   Hash Existing Encrypted Authorization Information Values:  Convert
+      the encrypted authorization information values stored in the
+      registry database to hashed values.  This update will not be
+      visible to the registrar.  The conversion can be done over a
+      period of time, depending on registry policy.
+
+6.3.  Transition Phase 3 - Enforcement
+
+   The goal of "Transition Phase 3 - Enforcement" is to complete the
+   implementation of the Secure Authorization Information Model, by
+   enforcing the following:
+
+   Disallow Authorization Information on <Create> Command:  Change the
+      <create> command to not allow the passing of a non-empty
+      authorization information value.  This behavior could potentially
+      break the client, so it's recommended that the registry provide
+      notice of this change.
+
+   Validate the Strong Random Authorization Information:  Change the
+      validation of the authorization information in the <update>
+      command to ensure at least 128 bits of entropy.
+
+7.  IANA Considerations
+
+7.1.  XML Namespace
+
+   This document uses URNs to describe XML namespaces conforming to the
+   registry mechanism described in [RFC3688].  IANA has assigned the
+   following URI in the "ns" subregistry within the "IETF XML Registry"
+   for secure authorization information for the transfer namespace:
+
+   URI:  urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
+   Registrant Contact:  IESG
+   XML:  None.  Namespace URIs do not represent an XML specification.
+
+7.2.  EPP Extension Registry
+
+   IANA has registered the EPP operational practice described in this
+   document in the "Extensions for the Extensible Provisioning Protocol
+   (EPP)" registry as defined in [RFC7451].  The details of the
+   registration are as follows:
+
+   Name of Extension:  "Extensible Provisioning Protocol (EPP) Secure
+      Authorization Information for Transfer"
+   Document status:  Standards Track
+   Reference:  RFC 9154
+   Registrant Name and Email Address:  IESG (iesg@ietf.org)
+   TLDs:  Any
+   IPR Disclosure:  None
+   Status:  Active
+   Notes:  None
+
+8.  Security Considerations
+
+   Section 4.1 defines the use of a secure random value for the
+   generation of authorization information.  The client SHOULD choose a
+   length and set of characters that result in at least 128 bits of
+   entropy.
+
+   Section 4.2 defines the use of an authorization information TTL.  The
+   registrar SHOULD only set the authorization information during the
+   transfer process by setting the authorization information at the
+   start of the transfer process and unsetting the authorization
+   information at the end of the transfer process.  The TTL value is
+   left up to registrar policy, and the sponsoring registrar MUST inform
+   the registrant of the TTL when providing the authorization
+   information to the registrant.
+
+   Section 4.3 defines the storage and transport of authorization
+   information.  The losing registrar MUST NOT store the authorization
+   information and the gaining registrar MUST only store the
+   authorization information as a "transient" value during the transfer
+   process, where the authorization information MUST NOT be stored after
+   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 per-authorization information random salt
+   with at least 128 bits.  All communication that includes the
+   authorization information MUST be over an encrypted channel.  The
+   plain-text authorization information MUST NOT be written to any logs
+   by the registrar or the registry.
+
+   Section 4.4 defines the matching of the authorization information
+   values.  The registry stores an unset authorization information value
+   as a NULL (undefined) value to ensure that an empty input
+   authorization information value never matches it.  The method used to
+   define a NULL (undefined) value is database specific.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
+              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
+              <https://www.rfc-editor.org/info/rfc5730>.
+
+   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
+              Domain Name Mapping", STD 69, RFC 5731,
+              DOI 10.17487/RFC5731, August 2009,
+              <https://www.rfc-editor.org/info/rfc5731>.
+
+   [RFC5733]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
+              Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
+              August 2009, <https://www.rfc-editor.org/info/rfc5733>.
+
+   [RFC5734]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
+              Transport over TCP", STD 69, RFC 5734,
+              DOI 10.17487/RFC5734, August 2009,
+              <https://www.rfc-editor.org/info/rfc5734>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
+              January 2019, <https://www.rfc-editor.org/info/rfc8499>.
+
+   [W3C.REC-xml-20081126]
+              Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
+              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+              Edition)", World Wide Web Consortium Recommendation REC-
+              xml-20081126, November 2008,
+              <https://www.w3.org/TR/2008/REC-xml-20081126>.
+
+9.2.  Informative References
+
+   [FIPS-140-2]
+              National Institute of Standards and Technology, U.S.
+              Department of Commerce, "NIST Federal Information
+              Processing Standards (FIPS) Publication 140-2",
+              DOI 10.6028/NIST.FIPS.140-2, May 2001,
+              <https://csrc.nist.gov/publications/detail/fips/140/2/
+              final>.
+
+   [FIPS-180-4]
+              National Institute of Standards and Technology, U.S.
+              Department of Commerce, "Secure Hash Standard, NIST
+              Federal Information Processing Standards (FIPS)
+              Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August
+              2015,
+              <https://csrc.nist.gov/publications/detail/fips/180/4/
+              final>.
+
+   [RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
+              Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
+              February 2015, <https://www.rfc-editor.org/info/rfc7451>.
+
+Acknowledgements
+
+   The authors wish to thank the following persons for their feedback
+   and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
+   Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew
+   Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.
+
+Authors' Addresses
+
+   James Gould
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA 20190
+   United States of America
+
+   Email: jgould@verisign.com
+   URI:   https://www.verisign.com
+
+
+   Richard Wilhelm
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA 20190
+   United States of America
+
+   Email: 4rickwilhelm@gmail.com
+   URI:   https://www.verisign.com