<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes"?>
<!-- keep one blank line between list items -->
<?rfc comments="yes" ?>
<!-- show cref output -->
<?rfc inline="yes" ?>
<!-- inline cref output -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-regext-secure-authinfo-transfer-07" number="9154" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3" consensus="true">

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="secure-transfer-authinfo"> abbrev="EPP Secure AuthInfo for Transfer">
    Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-regext-secure-authinfo-transfer-07"/> name="RFC" value="9154"/>
    <author fullname="James Gould" surname="Gould">
      <organization>VeriSign,
      <organization>Verisign, Inc.</organization>
      <address>
        <postal>
          <street>12061 Bluemont Way</street>
          <city>Reston</city>
          <region>VA</region>
          <code>20190</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>jgould@verisign.com</email>
        <uri>http://www.verisign.com</uri>
        <uri>https://www.verisign.com</uri>
      </address>
    </author>
    <author fullname="Richard Wilhelm" surname="Wilhelm">
      <organization>VeriSign,
      <organization>Verisign, Inc.</organization>
      <address>
        <postal>
          <street>12061 Bluemont Way</street>
          <city>Reston</city>
          <region>VA</region>
          <code>20190</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>rwilhelm@verisign.com</email>
        <uri>http://www.verisign.com</uri>
        <email>4rickwilhelm@gmail.com</email>
        <uri>https://www.verisign.com</uri>
      </address>
    </author>

<date month="December" year="2021"/>

<keyword>EPP</keyword>
<keyword>authinfo</keyword>
<keyword>random</keyword>
<keyword>short-lived</keyword>
<keyword>strong</keyword>
<keyword>storing</keyword>
<keyword>securely</keyword>

    <abstract>
      <t>The Extensible Provisioning Protocol (EPP), in RFC 5730, (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. "registrars".
       Object-specific, password-based authorization information (see RFC RFCs 5731 and
       RFC
       5733) is commonly used, 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, 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.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Extensible Provisioning Protocol (EPP), in (EPP) <xref target="RFC5730" format="default"/>, format="default"/>
      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. "registrars".
      The authorization information is object-specific object specific and has been
      defined in the EPP Domain Name Mapping, in "<xref target="RFC5731" format="title"/>" <xref target="RFC5731" format="default"/>, format="default"/> and the
      EPP Contact Mapping, in "<xref target="RFC5733" format="title"/>" <xref target="RFC5733" format="default"/>, format="default"/> 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 create, 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 that
      information, which includes the complexity of the authorization information,
      the time-to-live Time To Live (TTL) of the authorization information,
      and where and how the authorization information is stored.</t>
      <t>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, entirely and to only require
        the storage of hashed (not retrievable) passwords instead of encrypted
        passwords.</t>
      <t>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 short lived, not stored by the client, and that are 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 <xref target="RFC5731" format="default"/> 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 out of scope for this document.</t>
      <t>The overall goal is to have strong, random authorization information values, values
      that are short-lived, short lived and that are either not stored or stored as a
      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 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 "client" and the registry is referred to as the server. "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:</t>
      <dl newline="false" spacing="compact" spacing="normal" indent="4">
        <dt>"Strong
        <dt>Strong Random Authorization Information":</dt> Information:</dt>
        <dd>
          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, value that would be generated by the client.
        </dd>
        <dt>"Short-Lived
        <dt>Short-Lived Authorization Information":</dt> Information:</dt>
        <dd>The EPP RFCs don't explicitly
        support short-lived authorization information or a time-to-live (TTL) 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.
        In section 2.6 of
        As stated in <xref target="RFC5731" format="default"/> it states that sectionFormat="of" section="2.6"/>,
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 be short-lived. short lived.
        If authorization information is set only when there is 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.
        </dd>
        <dt>"Storing
        <dt>Storing Authorization Information Securely":</dt> Securely:</dt>
        <dd>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 to define 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, hash with
        at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-180-4"/>, and with a per-authorization information random salt, salt with at least 128 bits.
        Returning the authorization information set in an EPP info response will not be supported.
        </dd>
      </dl>
      <section numbered="true" toc="default">
        <name>Conventions Used in This Document</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
        <t>XML <xref target="W3C.REC-xml-20081126"/> is case sensitive. Unless stated otherwise, XML specifications
        and examples provided in this document MUST <bcp14>MUST</bcp14> be interpreted in the
        character case presented in order to develop a conforming
        implementation.</t>
        <t>In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.
        Indentation and white empty space in examples are provided only to illustrate element relationships
        and are not a required feature of this protocol.
        </t>
        <t>The examples reference XML namespace prefixes that are used for the associated XML namespaces.
        Implementations MUST NOT <bcp14>MUST NOT</bcp14> 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:</t> include the following:</t>
        <dl newline="false" spacing="compact" spacing="normal" indent="4">
          <dt>"domain":</dt>
          <dt>domain:</dt>
          <dd>urn:ietf:params:xml:ns:domain-1.0</dd>
          <dt>"contact":</dt>
          <dt>contact:</dt>
          <dd>urn:ietf:params:xml:ns:contact-1.0</dd>
        </dl>
      </section>
    </section>
    <section anchor="rrr" numbered="true" toc="default">
      <name>Registrant, Registrar, Registry</name>
      <t>The EPP RFCs refer to client "client" and server, "server", but when it comes to transfers, there are three types of actors that are involved.
          This document will refer to the these actors as registrant, registrar, "registrant", "registrar", and registry. "registry".  <xref target="RFC8499" format="default"/> defines these terms formally for the Domain Name System (DNS).
          The terms are further described below to cover their roles as actors of using the authorization information in the transfer process of any object in the registry,
          such as a domain name or a contact:</t>
      <dl newline="false" spacing="compact" spacing="normal" indent="4">
        <dt>"registrant":</dt>
        <dt>Registrant:</dt>
        <dd>
      <xref target="RFC8499" format="default"/> defines the registrant as "an individual or organization on whose behalf a name in a zone is registered by the registry". 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.</dd>
        <dt>"registrar":</dt>
        <dt>Registrar:</dt>
        <dd>
          <xref target="RFC8499" format="default"/> defines the registrar as "a service provider that acts as a go-between for registrants and registries". 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 directly (1)&nbsp;directly interface with the registrant or may indirectly (2)&nbsp;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. 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, "losing registrar", to another registrar, referred to as the gaining registrar.</dd>
        <dt>"registry":</dt> "gaining registrar".</dd>
        <dt>Registry:</dt>
        <dd>
          <xref target="RFC8499" format="default"/> defines the registry as "the administrative operation of a zone that allows registration of names within the zone". 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.</dd>
      </dl>
    </section>
    <section anchor="signal-client-server-support" numbered="true" toc="default">
      <name>Signaling Client and Server Support</name>
      <t>This document does not define a new protocol but protocol; rather, it defines an operational practice using the existing EPP protocol, 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 &lt;svcExtension&gt; &lt;extURI&gt; element of the &lt;login&gt; command <xref target="RFC5730" format="default"/> &lt;login&gt; Command. format="default"/>.
      The server includes the namespace URI in an &lt;svcExtension&gt; &lt;extURI&gt; element of the greeting <xref target="RFC5730" format="default"/> Greeting.</t> format="default"/>.</t>
      <t>A client that receives the namespace URI in the server's Greeting greeting extension services can expect the following supported behavior by the server:
      </t>
      <ol spacing="compact" spacing="normal" type="1">
        <li>Support for an empty authorization information value with a create &lt;create&gt; command.</li>
        <li>Support for unsetting authorization information with an update &lt;update&gt; command.</li>
        <li>Support for validating authorization information with an info &lt;info&gt; command.</li>
        <li>Support for not returning an indication of whether the authorization information is set or unset to the non-sponsoring registrar.</li>
        <li>Support for returning an empty authorization information value to the sponsoring registrar when the authorization information is set in an info response.</li>
        <li>Support allowing for allowing the passing of a matching non-empty authorization information value to authorize a transfer.</li>
        <li>Support for automatically unsetting the authorization information upon a successful completion of a transfer.</li>
      </ol>
      <t>A server that receives the namespace URI in the client's &lt;login&gt; Command command extension services, services can expect the following supported behavior by the client:
      </t>
      <ol spacing="compact" spacing="normal" type="1">
        <li>Support for the generation of authorization information using a secure random value.</li>
        <li>Support for only setting the authorization information when there is a transfer is in process.</li>
      </ol>
    </section>
    <section anchor="secureAuthInfo" numbered="true" toc="default">
      <name>Secure Authorization Information</name>
      <t>The authorization information in the EPP RFCs (<xref target="RFC5731" format="default"/> and <xref target="RFC5733" format="default"/>) that support transfer use password-based authorization information (<xref target="RFC5731" format="default"/> to support transfer with the &lt;domain:pw&gt; element and <xref target="RFC5733" target="RFC5731" format="default"/> and with the &lt;contact:pw&gt; element). element <xref target="RFC5733" format="default"/>.
    Other EPP objects that support password-based authorization information for
          transfer can use the Secure Authorization Information secure authorization information as defined in this document.  For the
       authorization information to be secure, it must be generated using a strong random value and have a short time-to-live (TTL). TTL. The security of the authorization information is defined in the
          following sections.</t>
      <section anchor="secureRandomAuthInfo" numbered="true" toc="default">
        <name>Secure Random Authorization Information</name>
        <t>For authorization information to be secure, it MUST <bcp14>MUST</bcp14> 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 / log2 log<sub>2</sub> 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 <bcp14>SHOULD</bcp14> use at least 128 bits of
       entropy as the value of H.  The lengths below are calculated using that
       value.</t>
        <t keepWithNext="true">Calculation
        <t>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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[ROUNDUP(128 0x21-0x7E:</t>
<t>ROUNDUP(128 / log2 log<sub>2</sub> 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20
            ]]></artwork>
        <t keepWithNext="true">Calculation 20</t>
        <t>Calculation of the required length with 128 bits of entropy and with the set of case insensitive case-insensitive alphanumeric characters, which consists of 36 characters (a-z A-Z 0-9).</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[ROUNDUP(128 0-9):</t>
<t>ROUNDUP(128 / log2 log<sub>2</sub> 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
            ]]></artwork> 25</t>
            <t>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 Sections&nbsp;<xref target="RFC4086" section="7.1.2"
 sectionFormat="bare"/> and 7.1.3 of <xref target="RFC4086" format="default"/>. section="7.1.3"
 sectionFormat="bare"/> of <xref target="RFC4086"/>.  In environments
      that do not provide interfaces to strong random number
      generators, the practices defined in <xref target="RFC4086" format="default"/> and section 4.7.1 Section&nbsp;4.7.1 of the <xref target="FIPS-140-2">NIST Federal Information Processing Standards (FIPS) Publication 140-2</xref> can be followed to produce random values that will be
      resistant to attack.</t> attack. (Note:  FIPS 140-2 has been superseded by FIPS 140-3, but
      FIPS 140-3 does not contain information regarding random number generators.)</t>
      </section>
      <section anchor="authInfoTTL" numbered="true" toc="default">
        <name>Authorization Information Time-To-Live Time To Live (TTL)</name>
        <t>The authorization information SHOULD <bcp14>SHOULD</bcp14> only be set when there is a transfer is in process.  This implies that the authorization information
            has a Time-To-Live (TTL) TTL by which the authorization information is cleared when the TTL expires.  The EPP RFCs have no definition of 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 TTL, and the sponsoring registrar
	    MUST
            <bcp14>MUST</bcp14> inform the registrant of the TTL when the authorization information is provided to the registrant.</t>
      </section>
      <section anchor="authInfoStorageTransport" numbered="true" toc="default">
        <name>Authorization Information Storage and Transport</name>
        <t>To protect the disclosure of the authorization information, the following requirements apply:</t>
        <ol spacing="compact" spacing="normal" type="1">
          <li>The authorization information MUST <bcp14>MUST</bcp14> be stored by the registry using a strong one-way cryptographic hash, hash with
          at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-180-4"/>, and with a per-authorization information random salt, salt
          with at least 128 bits.</li>
          <li>Empty
          <li>An empty authorization information MUST value <bcp14>MUST</bcp14> be stored as an undefined value that is referred to as a NULL "NULL" value.
          The representation of a NULL (undefined) value is dependent on the type of database used.</li>
          <li>The authorization information MUST NOT <bcp14>MUST NOT</bcp14> be stored by the losing registrar.</li>
          <li>The authorization information MUST <bcp14>MUST</bcp14> only be stored by the gaining registrar as a "transient" value in support of the transfer process.</li>
          <li>The plain text plain-text version of the authorization information MUST NOT <bcp14>MUST NOT</bcp14> be written to any logs by a registrar or the registry, nor
           otherwise recorded where it will persist beyond the transfer process.</li>
          <li>All communication that includes the authorization information MUST <bcp14>MUST</bcp14> be over an encrypted channel, such as defined in channel (for example, see <xref target="RFC5734" format="default"/> format="default"/>) for EPP.</li>
          <li>The registrar's interface for communicating the authorization information with the registrant MUST <bcp14>MUST</bcp14> be over an authenticated and encrypted channel.</li>
        </ol>
      </section>
      <section anchor="authInfoMatching" numbered="true" toc="default">
        <name>Authorization Information Matching</name>
        <t>To support the authorization information TTL, as defined described in <xref target="authInfoTTL" format="default"/>, 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 defined described in <xref target="authInfoStorageTransport" format="default"/>, 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 <xref target="createCommand" format="default">create format="default">&lt;create&gt; command</xref> and the <xref target="updateCommand" format="default">update format="default">&lt;update&gt; command</xref> to
         define the unset state.  The matching of the authorization information in the <xref target="infoCommandResponse" format="default">info format="default">&lt;info&gt; command</xref> and the <xref target="transferRequestCommand" format="default">transfer format="default">&lt;transfer&gt; request command</xref> is based on the following rules:
        </t>
        <ol spacing="compact" spacing="normal" type="1">
          <li>Any input authorization information value MUST NOT <bcp14>MUST NOT</bcp14> match an unset authorization information value.
            This includes empty authorization information, such as &lt;domain:null/&gt; or &lt;domain:pw/&gt;
            For example, in <xref target="RFC5731" format="default"/>,
            and non-empty authorization information, such as target="RFC5731"/> the input &lt;domain:pw&gt;2fooBAR&lt;/domain:pw&gt; in <xref target="RFC5731" format="default"/>.</li> must not match an unset authorization information value that used &lt;domain:null/&gt; or &lt;domain:pw/&gt;.</li>
          <li>An empty input authorization information value MUST NOT <bcp14>MUST NOT</bcp14> match any set authorization information value.</li>
          <li>A non-empty input authorization information value MUST <bcp14>MUST</bcp14> be hashed and matched against the set authorization information value, which is stored using the same hash algorithm.</li>
        </ol>
      </section>
    </section>
    <section anchor="createTransferSecureAuthInfo" numbered="true" toc="default">
      <name>Create, Transfer, and Secure Authorization Information</name>
      <t>To secure the transfer process using secure authorization information, information as defined described in <xref target="secureAuthInfo" format="default"/>,
      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
      in
      for management of the authorization information for transfers include:</t> include the following:</t>
      <ol spacing="compact" spacing="normal" type="1">
        <li>Registrant
        <li>The registrant requests to register the object with the registrar.  Registrar The registrar sends the create command, &lt;create&gt; command with an empty authorization information value, value
to the registry, as defined described in <xref target="createCommand" format="default"/>.</li>
        <li>Registrant
        <li>The registrant requests from the losing registrar the authorization information to provide to the gaining registrar.</li>
        <li>Losing
        <li>The losing registrar generates a secure random authorization information value, value and sends it to the registry registry, as defined described in <xref target="updateCommand" format="default"/>, and then provides it to the registrant.</li>
        <li>Registrant
        <li>The registrant provides the authorization information value to the gaining registrar.</li>
        <li>Gaining
        <li>The gaining registrar optionally verifies the authorization information with the info &lt;info&gt; command to the registry, as defined described in <xref target="infoCommandResponse" format="default"/>.</li>
        <li>Gaining
        <li>The gaining registrar sends the transfer request with the authorization information to the registry, as defined described in <xref target="transferRequestCommand" format="default"/>.</li>
        <li>If the transfer successfully completes, completes successfully, the registry automatically unsets the authorization information;
            otherwise
            otherwise, the losing registrar unsets the authorization information when the TTL expires, as defined in expires; see <xref target="updateCommand" format="default"/>.</li>
      </ol>
      <t>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.</t>
      <section anchor="createCommand" numbered="true" toc="default">
        <name>Create
        <name>&lt;Create&gt; Command</name>
        <t>For a create &lt;create&gt; command, the registry MUST <bcp14>MUST</bcp14> allow for the passing of an empty authorization information value and MAY <bcp14>MAY</bcp14> disallow for  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 a an "eppcom:pwAuthInfoType" element can have pass an empty authorization information value passed. value.  Examples of such extensions are found in <xref target="RFC5731" format="default"/> and <xref target="RFC5733" format="default"/>.</t>
  <t keepWithNext="true">Example of passing an empty authorization information value in an <xref target="RFC5731" format="default"/> a domain name create command:</t>
        <artwork &lt;create&gt; command <xref target="RFC5731" format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t keepWithNext="true">Example of passing an empty authorization information value in an a contact &lt;create&gt; command <xref target="RFC5733" format="default"/> contact create command:</t>
        <artwork format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

      </section>
      <section anchor="updateCommand" numbered="true" toc="default">
        <name>Update
        <name>&lt;Update&gt; Command</name>
        <t>
          For an update &lt;update&gt; command, the registry MUST <bcp14>MUST</bcp14> 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 the information provided in <xref target="secureRandomAuthInfo" format="default"/>, and setting it
          in the registry in the update &lt;update&gt; 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.
        </t>
        <t>
        Because of this, registries may validate the randomness of
        the authorization information based on the length and character set
        required by the registry.  For registry -- for example,
        validating that an authorization value contains a combination of upper-case,
        lower-case, uppercase,
        lowercase, and non-alphanumeric characters, characters in an attempt to
        assess the strength of the value, value and return returning an EPP error result of
        2202 ("Invalid authorization information") <xref target="RFC5730"/>
        if the check fails.
        </t>
        <t>
          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", 2202 and respond by
          generating a new value and trying again, possibly more than once.
        </t>
        <t>
          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 <bcp14>MUST</bcp14> define a time-to-live (TTL), TTL, as defined described in <xref target="authInfoTTL" format="default"/>,
        where
        and if the TTL expires expires, the registrar will unset the authorization information.
        </t>
        <t keepWithNext="true">Example of removing the "clientTransferProhibited" status and setting the authorization information in an <xref target="RFC5731" format="default"/> a domain name update command:</t>
        <artwork &lt;update&gt; command <xref target="RFC5731" format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t>
        When the registrar-defined TTL expires, the sponsoring registrar MUST <bcp14>MUST</bcp14> cancel the transfer process by unsetting the authorization information value and MAY <bcp14>MAY</bcp14> add back statuses like the "clientTransferProbited" "clientTransferProhibited" status.
        Any EPP object extension that supports setting
        the authorization information with a an "eppcom:pwAuthInfoType" element, element can have pass an empty authorization information value passed. value. Examples of such extensions are found in  <xref target="RFC5731" format="default"/> and <xref target="RFC5733" format="default"/>.  Setting an
        empty authorization information value unsets the authorization information.  <xref target="RFC5731" format="default"/> supports an explicit mechanism of unsetting the authorization information, by passing the &lt;domain:null&gt; authorization
        information value.  The registry MUST <bcp14>MUST</bcp14> 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.</t>
        <t keepWithNext="true">Example of adding the "clientTransferProhibited" status and unsetting the authorization information explicitly in an  <xref target="RFC5731" format="default"/> a domain name update command:</t>
        <artwork &lt;update&gt; command <xref target="RFC5731" format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t keepWithNext="true">Example of unsetting the authorization information with an empty authorization information value in an  <xref target="RFC5731" format="default"/> a domain name update command:</t>
        <artwork &lt;update&gt; command <xref target="RFC5731" format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t keepWithNext="true">Example of unsetting the authorization information with an empty authorization information value in an a contact &lt;update&gt; command <xref target="RFC5733" format="default"/> contact update command:</t>
        <artwork format="default"/>:</t>
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

      </section>
      <section anchor="infoCommandResponse" numbered="true" toc="default">
        <name>Info
        <name>&lt;Info&gt; Command and Response</name>
        <t>For an info &lt;info&gt; command, the registry MUST <bcp14>MUST</bcp14> allow for 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 &lt;info&gt; 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 <bcp14>MUST</bcp14> return an EPP error result code of 2202 <xref target="RFC5730" format="default"/>.</t>
        <t keepWithNext="true">Example of passing a non-empty authorization information value in an <xref target="RFC5731" format="default"/> a domain name info &lt;info&gt; command <xref target="RFC5731" format="default"/> to verify the authorization information value:</t>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t>The info response in object extensions, such as those defined in <xref target="RFC5731" format="default"/> and <xref target="RFC5733" format="default"/>, MUST NOT <bcp14>MUST NOT</bcp14> 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 plain-text authorization information is not possible, unless a valid plain text plain-text authorization information is passed in the info &lt;info&gt; command.
    The registry MUST NOT <bcp14>MUST NOT</bcp14> 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 <bcp14>MAY</bcp14> return an indication to the sponsoring registrar that the authorization information is set by using an empty authorization information value.
    The registry MAY <bcp14>MAY</bcp14> return an indication to the sponsoring registrar that the authorization information is unset by not returning the authorization information element.</t>
        <t keepWithNext="true">Example of returning an empty authorization information value in an <xref target="RFC5731" format="default"/> a domain name info response <xref target="RFC5731" format="default"/> to indicate to the sponsoring registrar that the authorization information is set:</t>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

      </section>
      <section anchor="transferRequestCommand" numbered="true" toc="default">
        <name>Transfer
        <name>&lt;Transfer&gt; Request Command</name>
        <t>For a Transfer Request Command, &lt;transfer&gt; request command, the registry MUST <bcp14>MUST</bcp14> allow for 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 <bcp14>MUST</bcp14> return an EPP error result code of 2202 <xref target="RFC5730" format="default"/>.
        Whether the transfer occurs immediately or is pending is up to server policy.  When the transfer occurs immediately, the registry MUST <bcp14>MUST</bcp14> return the EPP success result code of 1000 ("Command completed successfully") <xref target="RFC5730" format="default"/>, and
        when the transfer is pending, the registry MUST <bcp14>MUST</bcp14> return the EPP success result code of 1001. 1001 ("Command completed successfully; action pending").  The losing registrar MUST <bcp14>MUST</bcp14> be informed of a successful transfer request using an EPP poll &lt;poll&gt; message.</t>
        <t keepWithNext="true">Example of passing a non-empty authorization information value in an <xref target="RFC5731" format="default"/> a domain name transfer &lt;transfer&gt; request command <xref target="RFC5731" format="default"/> to authorize the transfer:</t>
        <artwork
<sourcecode name="" type="" align="left" alt=""><![CDATA[ type="xml"><![CDATA[
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>
            ]]></artwork>
]]></sourcecode>

        <t>Upon successful completion of the transfer, the registry MUST <bcp14>MUST</bcp14> automatically unset the authorization information.
      If the transfer request is not submitted within the <xref target="authInfoTTL" format="default">time-to-live (TTL)</xref> format="default">TTL</xref> or the transfer is cancelled canceled or rejected,
      the registrar MUST <bcp14>MUST</bcp14> unset the authorization information information, as defined described in <xref target="updateCommand" format="default"/>.</t>
      </section>
    </section>
    <section anchor="Transition" numbered="true" toc="default">
      <name>Transition Considerations</name>
      <t>The
      <t>
The goal of the transition considerations to the practice defined in this document, referred to as the Secure Authorization Information Model, is to minimize the impact to the registrars in supporting the Secure Authorization Information Model defined in this document by supporting incremental steps of adoption. 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 "Classic Authorization Information Model, that have Model", which incorporates the following steps in the for management of the authorization information for transfers:</t> transfers:
</t>
      <ol spacing="compact" spacing="normal" type="1">
        <li>Registrant
        <li>The registrant requests to register the object with the registrar.  Registrar The registrar sends the create &lt;create&gt; 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.</li>
        <li>At the time of transfer, Registrant the registrant requests from the losing registrar the authorization information to provide to the gaining registrar.</li>
        <li>Losing
        <li>The losing registrar retrieves the locally stored authorization information or queries the registry for authorization information using the info &lt;info&gt; command, and provides it to the registrant.  If the registry is queried, the authorization information is decrypted and
               the plain text plain-text authorization information is returned in the info response to the registrar.</li>
        <li>Registrant
        <li>The registrant provides the authorization information value to the gaining registrar.</li>
        <li>Gaining
        <li>The gaining registrar optionally verifies the authorization information with the info &lt;info&gt; command to the registry, by passing the authorization information in the info &lt;info&gt; command to the registry.</li>
        <li>Gaining
        <li>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.</li>
        <li>If the transfer successfully completes, completes successfully, the authorization information is not touched by the registry and may be updated by the gaining registrar using the update &lt;update&gt; command.
               If the transfer is cancelled canceled or rejected, the losing registrar may reset the authorization information using the update &lt;update&gt; command.</li>
      </ol>
      <t>The gaps between the Classic Authorization Information Model and the Secure Authorization Information Model include:</t> include the following:</t>
      <ol spacing="compact" spacing="normal" type="1">
        <li>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.</li>
        <li>Registry not allowing the authorization information to be unset versus supporting providing support for unsetting the authorization to be unset information in the update &lt;update&gt; command.</li>
        <li>Registry storing the authorization information as an encrypted value versus as a hashed value.</li>
        <li>Registry support for returning the authorization information versus not returning the authorization information in the info response.</li>
        <li>Registry not touching the authorization information versus the registry automatically unsetting the authorization information upon a successful transfer.</li>
        <li>Registry may validate 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.</li>
      </ol>
      <t>The transition can be handled in the three phases defined in the sub-sections <xref  Sections&nbsp;<xref target="TransitionFeatures" format="default"/>, format="counter"/>, <xref target="TransitionStorage" format="default"/>, format="counter"/>, and <xref target="TransitionEnforcement" format="default"/>.</t> format="counter"/>.</t>
      <section anchor="TransitionFeatures" numbered="true" toc="default">
        <name>Transition Phase 1 - Features</name>
        <t>The goal of the "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 command commands and responses below:</t>
        <dl newline="false" spacing="compact">
          <dt>Create spacing="normal">
          <dt>&lt;Create&gt; Command:</dt>
          <dd>Change the create &lt;create&gt; 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 defined described in <xref target="createCommand" format="default"/>.</dd>
          <dt>Update
          <dt>&lt;Update&gt; Command:</dt>
          <dd>Change the update &lt;update&gt; command to allow unsetting the authorization information, as defined described in <xref target="updateCommand" format="default"/>.
            This enables the registrar to optionally unset the authorization information when the TTL expires or when the transfer is cancelled canceled or rejected.</dd>
          <dt>Transfer Approve Command and Transfer Auto-Approve:</dt>
          <dd>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 transfer, and the registrar implementing the
            Classic Authorization Information Model will set the new authorization information upon the a successful transfer.</dd>
          <dt>Info Response:</dt>
          <dd>Change the info &lt;info&gt; command to not return the authorization information in the info response, as defined described in <xref target="infoCommandResponse" format="default"/>.
          This sets up the implementation of "Transition Phase 2 - Storage", Storage" (<xref target="TransitionStorage"/>), since the dependency in 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 that has the potential of breaking registrar, and this change could potentially break the client, so it's recommended that the registry provide notice of the change.</dd>
          <dt>Info
          <dt>&lt;Info&gt; Command and Transfer Request:</dt>
          <dd>Change the info &lt;info&gt; 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.</dd>
        </dl>
      </section>
      <section anchor="TransitionStorage" numbered="true" toc="default">
        <name>Transition Phase 2 - Storage</name>
        <t>The goal of the "Transition Phase 2 - Storage" is to transition the registry to use hashed authorization information instead of encrypted authorization information.
          There is no direct impact to on the registrars, since the only visible indication that the authorization information has been hashed is by not returning that the set
          authorization information is not returned in the info response, which is as addressed in <xref target="TransitionFeatures" format="default">Transition format="default">"Transition Phase 1 - Features</xref>.  There are three steps to transition Features"</xref>.  Transitioning the authorization information storage, which includes:</t> storage includes the
following three steps:
</t>
        <dl newline="false" spacing="compact"> spacing="normal">
          <dt>Hash New Authorization Information Values:</dt>
          <dd>Change the create &lt;create&gt; command and the update &lt;update&gt; command to hash instead of encrypting rather than encrypt the authorization information.</dd>
          <dt>Supporting Comparing Against
          <dt>Support Comparison against Encrypted and or Hashed Authorization Information:</dt>
          <dd>Change the info &lt;info&gt; command and the transfer &lt;transfer&gt; 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 are be self-identifying as being in hashed or encrypted form.</dd>
          <dt>Hash Existing Encrypted Authorization Information Values:</dt>
          <dd>Convert the encrypted authorization information values stored in the registry database to hashed values.
              The
              This update is will not a be visible change to the registrar.  The conversion can be done over a period of time time, depending on registry policy.</dd>
        </dl>
      </section>
      <section anchor="TransitionEnforcement" numbered="true" toc="default">
        <name>Transition Phase 3 - Enforcement</name>
        <t>The goal of the "Transition Phase 3 - Enforcement" is to complete the implementation of the "Secure Secure Authorization Information Model", Model, by enforcing the following:</t>
        <dl newline="false" spacing="compact"> spacing="normal">
          <dt>Disallow Authorization Information on Create &lt;Create&gt; Command:</dt>
          <dd>Change the create &lt;create&gt; command to not allow for the passing of a non-empty authorization information value.
            This behavior has the potential of breaking could potentially break the client, so it's recommended that the registry provide notice
            of the this change.</dd>
          <dt>Validate the Strong Random Authorization Information:</dt>
          <dd>Change the validation of the authorization information in the update &lt;update&gt; command to ensure at least 128 bits of entropy.</dd>
        </dl>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="IANA-XML-Namespace" numbered="true" toc="default">
        <name>XML Namespace</name>
        <t>
             This document uses URNs to describe XML namespaces
             conforming to a the registry mechanism described in <xref target="RFC3688" format="default"/>.
             The IANA has assigned the following URI assignment is requested of IANA:
        </t>
        <t>Registration request for in the "ns" subregistry within the "IETF XML Registry" for secure authorization information for the transfer namespace:</t>
        <ul empty="true"

        <dl newline="false" spacing="compact">
          <li>URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0</li>
          <li>Registrant Contact: IESG</li>
          <li>XML: None.
        <dt>URI:</dt><dd>urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0</dd>
        <dt>Registrant Contact:</dt><dd>IESG</dd>
        <dt>XML:</dt><dd>None. Namespace URIs do not represent an XML specification.</li>
        </ul> specification.</dd>
    </dl>
      </section>
      <section anchor="EPP-Extension-Registry" numbered="true" toc="default">
        <name>EPP Extension Registry</name>
        <t>
   The
          IANA has registered the EPP operational practice described in this document should be registered by
   the IANA in the EPP Extension Registry described "Extensions for the Extensible Provisioning Protocol (EPP)" registry as defined in <xref target="RFC7451" format="default"/>.  The
   details of the registration are as follows:
        </t>
        <t>
   Name
    <dl newline="false" spacing="compact">
     <dt>Name of Extension: "Extensible Extension:</dt><dd>"Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer"
        </t>
        <t>
   Document status: Standards Track
        </t>
        <t>
   Reference: (insert reference to RFC version of this document)
        </t>
        <t>
   Registrant Transfer"</dd>
     <dt>Document status:</dt><dd>Standards Track</dd>
     <dt>Reference:</dt><dd>RFC 9154</dd>
     <dt>Registrant Name and Email Address: IESG, &lt;iesg@ietf.org&gt;
        </t>
        <t>
   TLDs: Any
        </t>
        <t>
   IPR Disclosure: None
        </t>
        <t>
   Status: Active
        </t>
        <t>
   Notes: None
        </t>
      </section>
    </section>
    <section anchor="Implementation" numbered="true" toc="default">
      <name>Implementation Status</name>
      <t>Note to RFC Editor: Please remove this section and the reference to
         <xref target="RFC7942" format="default">RFC 7942</xref> before publication.</t>
      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of
      this Internet-Draft, and is based on a proposal described in <xref target="RFC7942" format="default">RFC
      7942</xref>.  The description of implementations in this section is
      intended to assist the IETF in its decision processes in
      progressing drafts to RFCs.  Please note that the listing of any
      individual implementation here does not imply endorsement by the
      IETF.  Furthermore, no effort has been spent to verify the
      information presented here that was supplied by IETF contributors.
      This is not intended as, and must not be construed to be, a
      catalog of available implementations or their features.  Readers
      are advised to note that other implementations may exist.</t>
      <t>According to <xref target="RFC7942" format="default">RFC 7942</xref>, "this will allow reviewers and working
      groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented
      protocols more mature.  It is up to the individual working groups
      to use this information as they see fit".</t>
      <section numbered="true" toc="default">
        <name>Verisign EPP SDK</name>
        <t>Organization: Verisign Inc.</t>
        <t>Name: Verisign EPP SDK</t>
        <t>Description: The Verisign EPP SDK includes both a full client implementation
        and a full server stub implementation of draft-ietf-regext-secure-authinfo-transfer.</t>
        <t>Level of maturity: Development</t>
        <t>Coverage: All aspects of the protocol are implemented.</t>
        <t>Licensing: GNU Lesser General Public License</t>
        <t>Contact: jgould@verisign.com</t>
        <t>URL: https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks</t>
      </section>
      <section numbered="true" toc="default">
        <name>RegistryEngine EPP Service</name>
        <t>Organization: CentralNic</t>
        <t>Name: RegistryEngine EPP Service</t>
        <t>Description: Generic high-volume EPP service for gTLDs, ccTLDs and SLDs</t>
        <t>Level of maturity: Deployed in CentralNic's production environment as well as two other gTLD registry systems, and two ccTLD registry systems.</t>
        <t>Coverage: Authorization Information is "write only" in that the registrars can set the Authorization Information,
        but not get the Authorization Information in the Info Response.</t>
        <t>Licensing: Proprietary In-House software</t>
        <t>Contact: epp@centralnic.com</t>
        <t>URL: https://www.centralnic.com</t> Address:</dt><dd>IESG (iesg@ietf.org)</dd>
     <dt>TLDs:</dt><dd>Any</dd>
     <dt>IPR Disclosure:</dt><dd>None</dd>
     <dt>Status:</dt><dd>Active</dd>
     <dt>Notes:</dt><dd>None</dd>
    </dl>
      </section>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="secureRandomAuthInfo" format="default"/> defines the use of a secure random value for the generation of the authorization information.
      The client SHOULD <bcp14>SHOULD</bcp14> choose a length and set of characters that results result in at least 128 bits of entropy.</t>
      <t><xref target="authInfoTTL" format="default"/> defines the use of an authorization information Time-To-Live (TTL). TTL.  The registrar SHOULD <bcp14>SHOULD</bcp14> only set the authorization information during the transfer process
      by the server support for setting the authorization information at the start of the transfer process and unsetting the authorization information. information at the end of the transfer process.
 The TTL value is left up to registrar policy policy, and the sponsoring registrar MUST <bcp14>MUST</bcp14> inform the registrant of the TTL
      when providing the authorization information to the registrant.</t>
      <t><xref target="authInfoStorageTransport" format="default"/> defines the storage and transport of authorization information.  The losing registrar MUST NOT <bcp14>MUST NOT</bcp14> store the authorization information and the gaining
      registrar MUST <bcp14>MUST</bcp14> only store the authorization information as a "transient" value during the transfer process, where the authorization information MUST NOT <bcp14>MUST NOT</bcp14> be stored after the end of the transfer process.
      The registry MUST <bcp14>MUST</bcp14> store the authorization information using a one-way cryptographic hash of at least 256 bits and with a per-authorization information random salt, salt with at least 128 bits.
      All communication that includes the authorization information MUST <bcp14>MUST</bcp14> be over an encrypted channel.  The plain text plain-text
      authorization information MUST NOT <bcp14>MUST NOT</bcp14> be written to any logs by the registrar or the registry.</t>
      <t><xref target="authInfoMatching" format="default"/> 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.</t>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors wish to thank the following persons for their feedback and suggestions:
        <contact fullname="Michael Bauland"/>,
        <contact fullname="Martin Casanova"/>,
        <contact fullname="Scott Hollenbeck"/>,
        <contact fullname="Benjamin Kaduk"/>,
        <contact fullname="Jody Kolker"/>,
        <contact fullname="Barry Leiba"/>,
        <contact fullname="Patrick Mevzek"/>,
        <contact fullname="Matthew Pozun"/>,
        <contact fullname="Srikanth Veeramachaneni"/>,
        and <contact fullname="Ulrich Wisser"/>.
      </t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->
  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->
     <references>
       <name>References</name>
       <references>
         <name>Normative References</name>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5733.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5733.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5734.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5734.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
         <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>

     <reference anchor='W3C.REC-xml-20081126'
         target='https://www.w3.org/TR/2008/REC-xml-20081126'>
     <front>
     <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
     <author initials='T.' surname='Bray' fullname='Tim Bray'>
         <organization />
     </author>
     <author initials='J.' surname='Paoli' fullname='Jean Paoli'>
         <organization />
     </author>
     <author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg-McQueen'>
         <organization />
     </author>
     <author initials='E.' surname='Maler' fullname='Eve Maler'>
         <organization />
     </author>
     <author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
         <organization />
     </author>
     <date month='November' year='2008' />
     </front>
     <refcontent>World Wide Web Consortium Recommendation REC-xml-20081126</refcontent>
     </reference>
      </references>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"/> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml"/>

        <reference anchor='FIPS-180-4'
                   target=' https://csrc.nist.gov/publications/detail/fips/180/4/final'>
                   target='https://csrc.nist.gov/publications/detail/fips/180/4/final'>
          <front>
            <title>Secure Hash Standard, NIST Federal Information Processing Standards (FIPS) Publication 180-4</title>
            <author>
             <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>
            </author>
            <date month='August' year='2015'/>
          </front>
         <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
        </reference>

        <reference anchor='FIPS-140-2'
                   target='https://csrc.nist.gov/publications/detail/fips/140/2/final'>
          <front>
            <title>NIST Federal Information Processing Standards (FIPS) Publication 140-2</title>
            <author>
             <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>
            </author>
            <date month='May' year='2001'/>
          </front>
         <seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-2"/>
        </reference>
      </references>
    </references>
    <section numbered="true" toc="default">
      <name>Change History</name>
      <section anchor="change-00-to-01" numbered="true" toc="default">
        <name>Change from 00 to 01</name>
        <ol spacing="compact" type="1">
          <li>Filled in the "Implementation Status" section with the inclusion of the "Verisign EPP SDK" and "RegistryEngine EPP Service" implementations.</li>
          <li>Made small wording corrections based on private feedback.</li>
          <li>Added content to the "Acknowledgements" section.</li>
        </ol>
      </section>
      <section anchor="change-01-to-02" numbered="true" toc="default">
        <name>Change from 01 to 02</name>
        <ol spacing="compact" type="1">
          <li>Revised the language used for the storage of the authorization information based on the feedback from Patrick Mevzek and Jody Kolker.</li>
        </ol>
      </section>
      <section anchor="change-02-to-03" numbered="true" toc="default">
        <name>Change from 02 to 03</name>
        <ol spacing="compact" type="1">
          <li>
            <t>Updates based on the feedback from the interim REGEXT meeting held at ICANN-66:
            </t>
            <ol spacing="compact" type="1">
              <li>Section 3.3, include a reference to the hash algorithm to use.  Broke the requirements into a list and included a the reference the text ', with
              at least a 256-bit hash function, such as SHA-256'.</li>
              <li>Add a Transition Considerations section to cover the transition from the
                classic authorization information security model in the EPP RFCs to the model defined in the document.</li>
              <li>Add a statement to the Introduction that elements of the practice can be used for purposes other than transfer, but with a caveat.</li>
            </ol>
          </li>
          <li>
            <t>Updates based on the review by Michael Bauland, that include:
            </t>
            <ol spacing="compact" type="1">
              <li>In section 2, change 'there are three actors' to 'there are three types of actors' to cover the case with transfers that has two registrar actors (losing and gaining).</li>
              <li>In section 3.1, change the equations equals to be approximately equal by using '=~' instead of '=', where applicable.</li>
              <li>In section 3.3, change 'MUST be over an encrypted channel, such as RFC5734' to 'MUST be over an encrypted channel, such as defined in RFC5734'.</li>
              <li>In section 4.1, remove the optional RFC 5733 elements from the contact create, which includes
                the &lt;contact:voice&gt;, &lt;contact:fax&gt;, &lt;contact:disclose&gt;, &lt;contact:org&gt;, &lt;contact:street&gt;, &lt;contact:sp&gt;, and &lt;contact:cc&gt; elements.</li>
              <li>In section 4.2, changed 'Example of unsetting the authorization information explicitly in an [RFC5731] domain name update command.' to
                'Example of adding the "clientTransferProhibited" status and unsetting the authorization information explicitly in an [RFC5731] domain name update command.'</li>
              <li>In section 4.3, cover a corner case of the ability to return the authorization information when it's passed in the info command.</li>
              <li>In section 4.4, change 'If the transfer does not complete within the time-to-live (TTL)' to 'If the transfer is not initiated within the time-to-live (TTL)',
                since the TTL is the time between setting the authorization information and when it's successfully used in a transfer request.  Added the case of unsetting the authorization information when
                the transfer is cancelled or rejected.</li>
            </ol>
          </li>
          <li>
            <t>Updates based on the authorization information messages by Martin Casanova on the REGEXT mailing list, that include:
            </t>
            <ol spacing="compact" type="1">
              <li>Added section 3.4 'Authorization Information Matching' to clarify how the authorization information is matched, when there is set and unset authorization information in the database
                and empty and non-empty authorization information passed in the info and transfer commands.</li>
              <li>Added support for signaling that the authorization information is set or unset to the sponsoring registrar with the inclusion of an empty authorization information
                 element in the response to indicate that the authorization information is set and the exclusion of the authorization information element in the response to indicate
                 that the authorization information is unset.</li>
            </ol>
          </li>
          <li>Made the capitalization of command and response references consistent by uppercasing section and item titles and lowercasing references elsewhere.</li>
        </ol>
      </section>
      <section anchor="change-03-to-WG00" numbered="true" toc="default">
        <name>Change from 03 to REGEXT 00</name>
        <ol spacing="compact" type="1">
          <li>Changed to regext working group draft by changing draft-gould-regext-secure-authinfo-transfer to draft-ietf-regext-secure-authinfo-transfer.</li>
        </ol>
      </section>
      <section anchor="change-WG00-to-WG01" numbered="true" anchor="Acknowledgements" numbered="false" toc="default">
        <name>Change from REGEXT 00 to REGEXT 01</name>
        <ol spacing="compact" type="1">
          <li>Added the "Signaling Client and Server Support" section to describe the mechanism
      <name>Acknowledgements</name>
      <t>The authors wish to signal support for the BCP by the client and the server.</li>
          <li>Added the "IANA Considerations" section with the registration of the secure authorization for transfer
            XML namespace and the registration of the EPP Best Current Practice (BCP) in thank the EPP Extension Registry.</li>
        </ol>
      </section>
      <section anchor="change-WG01-to-WG02" numbered="true" toc="default">
        <name>Change from REGEXT 01 to REGEXT 02</name>
        <ol spacing="compact" type="1">
          <li>Added inclusion of random salt following persons for the hashed authorization information, based on feedback from Ulrich Wisser.</li>
          <li>Added clarification that the representation of a NULL (undefined) value is dependent on the type of database, based on their feedback from Patrick Mevzek.</li>
          <li>Filled in the Security Considerations section.</li>
        </ol>
      </section>
      <section anchor="change-WG02-to-WG03" numbered="true" toc="default">
        <name>Change from REGEXT 02 to REGEXT 03</name>
        <ol spacing="compact" type="1">
          <li>Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0, which removed bcp from the namespace and bumped the version from 0.1 suggestions:
        <contact fullname="Michael Bauland"/>,
        <contact fullname="Martin Casanova"/>,
        <contact fullname="Scott Hollenbeck"/>,
        <contact fullname="Benjamin Kaduk"/>,
        <contact fullname="Jody Kolker"/>,
        <contact fullname="Barry Leiba"/>,
        <contact fullname="Patrick Mevzek"/>,
        <contact fullname="Matthew Pozun"/>,
        <contact fullname="Srikanth Veeramachaneni"/>,
        and 1.0.
          Inclusion of bcp in the XML namespace was discussed at the REGEXT interim meeting.</li>
          <li>Replaced Auhtorization with Authorization based on a review by Jody Kolker.</li>
        </ol>
      </section>
      <section anchor="change-WG03-to-WG04" numbered="true" toc="default">
        <name>Change from REGEXT 03 to REGEXT 04</name>
        <ol spacing="compact" type="1">
          <li>Converted from xml2rfc v2 to v3.</li>
          <li>Updated Acknowledgements to match the approach taken by the RFC Editor with draft-ietf-regext-login-security.</li>
          <li>Changed from Best Current Practice (BCP) to Standards Track based on mailing list discussion.</li>
        </ol>
      </section>
      <section anchor="change-WG04-to-WG05" numbered="true" toc="default">
        <name>Change from REGEXT 04 to REGEXT 05</name>
        <ol spacing="compact" type="1">
          <li>Fixed IDNITS issues, including moving RFC7451 to Informative References section.</li>
        </ol>
      </section>
      <section anchor="change-WG05-to-WG06" numbered="true" toc="default">
        <name>Change from REGEXT 05 to REGEXT 06</name>
        <t>Updates based on the Barry Leiba (AD) feedback: <contact fullname="Ulrich Wisser"/>.
      </t>
        <ol spacing="compact" type="1">
          <li>Simplified the abstract based on the proposal provided.</li>
          <li>In the Introduction, split the first paragraph by starting a new paragraph at "This document".</li>
          <li>In section 1.1, updated to use the new BCP 14 boilerplate and add a normative reference to RFC 8174.</li>
          <li>In section 4, Updated the phrasing to "For the authorization information to be secure it must be generated
            using a strong random value and have a short time-to-live (TTL).".</li>
          <li>In section 4.1, removed the first two unnecessary calculations and condensed the introduction of the section.</li>
          <li>In section 4.1, added the use of the normative SHOULD for use of at least 128 bits of entropy.</li>
          <li>Added an informative reference to FIPS 180-4 for the SHA-256 references.</li>
          <li>Normalized the way that the "empty and non-empty authorization information values" are referenced, which a few exceptions.</li>
          <li>In section 4, revised the first sentence to explicitly reference the use of the &lt;domain:pw&gt; and &lt;contact:pw&gt; elements for password-based authorization information.</li>
          <li>In section 4.4, revised the language associated with the storage of the authorization information to be cleaner.</li>
          <li>In section 4.4, added "set" in the sentence "An empty input authorization information value MUST NOT match any set authorization information value."</li>
          <li>In section 5.1 and 5.2, clarified the references to RFC5731 and RFC5733 as examples of object extensions that use the "eppcom:pwAuthInfoType" element.</li>
          <li>In section 5.2, updated language for the validation of the randomness of the authorization information, based on an offline review by Barry Leiba, Benjamin Kaduk, and Roman Danyliw.</li>
          <li>In section 9, changed "49 bits of entropy" to "128 bits of entropy".</li>
        </ol>
        <t>In section 3, replaced the reference to BCP with operational practice, since the draft is not defined as a BCP.</t>
      </section>
      <section anchor="change-WG06-to-WG07" numbered="true" toc="default">
        <name>Change from REGEXT 06 to REGEXT 07</name>
        <ol>
          <li>
            <t>Updates based on the Lars Eggert feedback:</t>
            <ol spacing="compact" type="1">
              <li>Updated Section 1, Paragraph 4 to read "The operational practice will require the client to not store the authorization information and".</li>
              <li>Updated each of the example references to end with a colon instead of a period.</li>
              <li>Updated Section 1, Paragraph 3 to read "provide secure authorization information used for transfers."</li>
              <li>Updated Section 3, Paragraph 3 to read "extension services can expect".</li>
              <li>Updated Section 4, Paragraph 2 to read "authorization information to be secure, it must".</li>
              <li>Updated Section 4.2, Paragraph 2 to read "authorization information by the sponsoring registrar, the".</li>
              <li>Updated Section 4.2, Paragraph 2 to read "proprietary registrar-specific criteria, which".</li>
              <li>Updated Section 4.3, Paragraph 3 to read "256-bit hash function, such as SHA-256".</li>
              <li>Updated Section 4.3, Paragraph 3 to read "a NULL (undefined) value".</li>
              <li>Updated Section 5, Paragraph 2 to read "To secure the transfer process using secure authorization".</li>
              <li>Updated Section 5.2, Paragraph 6 to read "Often, the registrar has the "clientTransferProhibited" status set".</li>
              <li>Updated Section 5.2, Paragraph 9 to read "MUST cancel cancel the transfer process by unsetting the authorization information value and MAY add back statuses".</li>
              <li>Updated Section 5.2, Paragraph 9 to read ""eppcom:pwAuthInfoType" element can have".</li>
            </ol>
          </li>
          <li>Updated the first sentence of the abstract and introduction based on the Rob Wilton feedback to help non-EPP readers on the what and the who for transfers.</li>
          <li>Removed the duplicate first paragraph of section 5.2 based on feedback from Francesca Palombini.</li>
          <li>
            <t>Updates based on the Benjamin Kaduk feedback:</t>
            <ol spacing="compact" type="1">
              <li>Added the second paragraph in the Introduction to provide high-level motivation for the work.</li>
              <li>Updated Section 1, changed "in any way" to "in any substantial way".</li>
              <li>Updated Section 1 by adding the sentence "All of these features are compatible with the EPP RFCs, though not mandatory to implement." for the "Short-Lived Authorization Information".</li>
              <li>Updated the description of "Short-Lived Authorization Information" in Section 1 to reference section 2.6 of RFC5731 and change in nature of the authorization information.</li>
              <li>Updated Section 4.1, Paragraph 1 and 2 were merged with modified language proposed by Benjamin Kaduk, which included removing the reference to RFC4086 for length and entropy.</li>
              <li>Updated rule #1 of Section 4.1 to add a second clarifying sentence for what is meant by input authorization information.</li>
              <li>Updated Section 4.1 by replacing the last paragraph "The strength of the random..." with a revised version.</li>
              <li>Updated "retrieves the stored authorization information locally" with "retrieves the locally stored authorization information".</li>
              <li>Updated Section 6.1 to include the recommendation that the registry provide notice of the Info Response change.</li>
              <li>Updated Section 6.2 to include the sentence "This requires that the stored values are self-identifying as being in hashed or encrypted form"
                for the "Supporting Comparing Against Encrypted and Hashed Authorization Information" step.</li>
              <li>Updated Section 6.3 to include the recommendation that the registry provide notice of the Create Command change.</li>
              <li>Updated "written to any logs by the registrar or the registry" to "written to any logs by a registrar or the registry" to cover both the losing and the gaining registrar.</li>
              <li>Updated references to "with a random salt" to "with a per-authorization information random salt,
                with at least 128 bits" to address sharing of salts and the size of the salts.</li>
              <li>Updated the first paragraph of Section 9 to remove the reference to defining a server policy for the length
                and set of characters that are included in the randomization to target the target entropy level.</li>
              <li>Updated Section 9 by removing the sentence "A random number generator (RNG) is preferable over the use of a pseudorandom number generator (PRNG) when creating the authorization information value."</li>
              <li>Changed FIPS-140-2 from a normative reference to an informative reference.</li>
            </ol>
          </li>
        </ol>
      </section>
    </section>
  </back>
  <!-- vim: set ts=2 sw=2 expandtab: -->
</rfc>