rfc9154.original.xml   rfc9154.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!DOCTYPE rfc [
<!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-ie
tf-regext-secure-authinfo-transfer-07" ipr="trust200902" obsoletes="" updates=""
submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="tru
e" sortRefs="true" version="3" consensus="true">
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-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> <front>
<title abbrev="secure-transfer-authinfo"> <title abbrev="EPP Secure AuthInfo for Transfer">
Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer</title> Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-regext-secure-authinfo-t ransfer-07"/> <seriesInfo name="RFC" value="9154"/>
<author fullname="James Gould" surname="Gould"> <author fullname="James Gould" surname="Gould">
<organization>VeriSign, Inc.</organization> <organization>Verisign, Inc.</organization>
<address> <address>
<postal> <postal>
<street>12061 Bluemont Way</street> <street>12061 Bluemont Way</street>
<city>Reston</city> <city>Reston</city>
<region>VA</region> <region>VA</region>
<code>20190</code> <code>20190</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>jgould@verisign.com</email> <email>jgould@verisign.com</email>
<uri>http://www.verisign.com</uri> <uri>https://www.verisign.com</uri>
</address> </address>
</author> </author>
<author fullname="Richard Wilhelm" surname="Wilhelm"> <author fullname="Richard Wilhelm" surname="Wilhelm">
<organization>VeriSign, Inc.</organization> <organization>Verisign, Inc.</organization>
<address> <address>
<postal> <postal>
<street>12061 Bluemont Way</street> <street>12061 Bluemont Way</street>
<city>Reston</city> <city>Reston</city>
<region>VA</region> <region>VA</region>
<code>20190</code> <code>20190</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>rwilhelm@verisign.com</email> <email>4rickwilhelm@gmail.com</email>
<uri>http://www.verisign.com</uri> <uri>https://www.verisign.com</uri>
</address> </address>
</author> </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> <abstract>
<t>The Extensible Provisioning Protocol (EPP), in RFC 5730, <t>The Extensible Provisioning Protocol (EPP) (RFC 5730)
defines the use of authorization information to authorize a transfer of a n EPP object, defines the use of authorization information to authorize a transfer of a n EPP object,
such as a domain name, between clients that are referred to as registrars such as a domain name, between clients that are referred to as "registrar
. s".
Object-specific, password-based authorization information (see RFC 5731 a Object-specific, password-based authorization information (see RFCs 5731
nd and
RFC 5733) is commonly used, but raises issues related to the security, 5733) is commonly used but raises issues related to the security,
complexity, storage, and lifetime of authentication information. complexity, storage, and lifetime of authentication information.
This document defines an operational practice, using the EPP RFCs, This document defines an operational practice, using the EPP RFCs,
that leverages the use of strong random authorization information that leverages the use of strong random authorization information
values that are short-lived, not stored by the client, and stored values that are short lived, not stored by the client, and stored
by the server using a cryptographic hash that provides for secure by the server using a cryptographic hash that provides for secure
authorization information that can safely be used for object authorization information that can safely be used for object
transfers.</t> transfers.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The Extensible Provisioning Protocol (EPP), in <xref target="RFC5730" f ormat="default"/>, <t>The Extensible Provisioning Protocol (EPP) <xref target="RFC5730" forma t="default"/>
defines the use of authorization information to authorize a transfer of an EPP object, 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. such as a domain name, between clients that are referred to as "registrars
The authorization information is object-specific and has been ".
defined in the EPP Domain Name Mapping, in <xref target="RFC5731" format=" The authorization information is object specific and has been
default"/>, and the defined in "<xref target="RFC5731" format="title"/>" <xref target="RFC5731
EPP Contact Mapping, in <xref target="RFC5733" format="default"/>, as pass " format="default"/> and "<xref target="RFC5733" format="title"/>" <xref target=
word-based authorization "RFC5733" format="default"/> as password-based authorization
information. Other authorization mechanisms can be used, but in practice information. Other authorization mechanisms can be used, but in practice
the password-based authorization information has been used at the time of object create, 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 r equest. managed with the object update, and used to authorize an object transfer r equest.
What has not been considered is the security of the authorization What has not been considered is the security of the authorization
information that includes the complexity of the authorization information, information, which includes the complexity of the authorization informatio
the time-to-live (TTL) of the authorization information, n,
the Time To Live (TTL) of the authorization information,
and where and how the authorization information is stored.</t> and where and how the authorization information is stored.</t>
<t>The current/original lifecycle for authorization information involves <t>The current/original lifecycle for authorization information involves
long-term storage of encrypted (not hashed) passwords, which presents a long-term storage of encrypted (not hashed) passwords, which presents a
significant latent risk of password compromise and is not consistent significant latent risk of password compromise and is not consistent
with current best practices. The mechanisms in this document provide a with current best practices. The mechanisms in this document provide a
way to avoid long-term password storage entirely, and to only require way to avoid long-term password storage entirely and to only require
the storage of hashed (not retrievable) passwords instead of encrypted the storage of hashed (not retrievable) passwords instead of encrypted
passwords.</t> passwords.</t>
<t>This document <t>This document
defines an operational practice, using the EPP RFCs, that defines an operational practice, using the EPP RFCs, that
leverages the use of strong, random authorization information values leverages the use of strong, random authorization information values
that are short-lived, that are not stored by the client, and that are that are short lived, not stored by the client, and stored by the server u
stored by the server using a cryptographic hash to provide sing a cryptographic hash to provide
secure authorization information used for transfers. secure authorization information used for transfers.
This operational practice can be used to support This operational practice can be used to support
transfers of any EPP object, where the domain name object defined in <xref target="RFC5731" format="default"/> is used in this document for illustration p urposes. transfers of any EPP object, where the domain name object as defined in <x ref target="RFC5731" format="default"/> is used in this document for illustratio n purposes.
Elements of the practice may be used to support the secure use of the Elements of the practice may be used to support the secure use of the
authorization information for purposes other than transfer, but any authorization information for purposes other than transfer, but any
other purposes and the applicable elements are out-of-scope for this docum other purposes and the applicable elements are out of scope for this docum
ent.</t> ent.</t>
<t>The overall goal is to have strong, random authorization information va <t>The overall goal is to have strong, random authorization information va
lues, lues
that are short-lived, and that are either not stored or stored as a that are short lived and are either not stored or stored as
cryptographic hash values by the non-responsible parties. cryptographic hash values by the non-responsible parties.
In a registrant, registrar, and registry model, the registrant registers In a registrant, registrar, and registry model, the registrant registers
the object through the registrar to the registry. the object through the registrar to the registry.
The registrant is the responsible party and the registrar The registrant is the responsible party, and the registrar
and the registry are the non-responsible parties. EPP is a protocol 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 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 the "client" and the registry is referred to as the "server". The followi ng
are the elements of the operational practice and how the existing features are the elements of the operational practice and how the existing features
of the EPP RFCs can be leveraged to satisfy them:</t> of the EPP RFCs can be leveraged to satisfy them:</t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>"Strong Random Authorization Information":</dt> <dt>Strong Random Authorization Information:</dt>
<dd> <dd>
The EPP RFCs define the password-based authorization information value using 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. 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 This operational practice defines the recommended mechanism for
creating a strong random authorization value, that would be generated by the client. creating a strong random authorization value that would be generated b y the client.
</dd> </dd>
<dt>"Short-Lived Authorization Information":</dt> <dt>Short-Lived Authorization Information:</dt>
<dd>The EPP RFCs don't explicitly <dd>The EPP RFCs don't explicitly
support short-lived authorization information or a time-to-live (TTL) fo r authorization information, support short-lived authorization information or a TTL for authorization information,
but there are EPP RFC features that can be leveraged to support short-li ved authorization information. but there are EPP RFC features that can be leveraged to support short-li ved authorization information.
All of these features are compatible with the EPP RFCs, though not manda tory to implement. All of these features are compatible with the EPP RFCs, though not manda tory to implement.
In section 2.6 of <xref target="RFC5731" format="default"/> it states th As stated in <xref target="RFC5731" sectionFormat="of" section="2.6"/>,
at authorization information is assigned when a domain object is created, authorization information is assigned when a domain object is created,
which results in long-lived authorization information. This specificati on changes the nature of the which results in long-lived authorization information. This specificati on changes the nature of the
authorization information to be short-lived. authorization information from long lived to short lived.
If authorization information is set only when there is a transfer in pro If authorization information is set only when a transfer is in process,
cess, the server the server
needs to support an empty authorization information value on create, sup port setting and needs to support an empty authorization information value on create, sup port setting and
unsetting authorization information, and support automatically unsetting the authorization information upon a 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. successful transfer. All of these features can be supported by the EPP RFCs.
</dd> </dd>
<dt>"Storing Authorization Information Securely":</dt> <dt>Storing Authorization Information Securely:</dt>
<dd>The EPP RFCs don't <dd>The EPP RFCs don't
specify where and how the authorization information is stored in the cli ent or the server, so specify where and how the authorization information is stored in the cli ent or the server, so
there are no restrictions to define an operational practice for storing the authorization information there are no restrictions on defining an operational practice for storin g the authorization information
securely. The operational practice will require the client to not store 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 and will require the server to store the authorization information using
a cryptographic hash, with a cryptographic hash with
at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-180 at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-180
-4"/>, and with a per-authorization information random salt, with at least 128 b -4"/>, and with a per-authorization information random salt with at least 128 bi
its. ts.
Returning the authorization information set in an EPP info response will not be supported. Returning the authorization information set in an EPP info response will not be supported.
</dd> </dd>
</dl> </dl>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>SHOULD NOT</bcp14>",
when, and only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>XML is case sensitive. Unless stated otherwise, XML specifications are to be interpreted as described in BCP&nbsp;14
and examples provided in this document MUST be interpreted in the <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 s
tated otherwise, XML specifications
and examples provided in this document <bcp14>MUST</bcp14> be interprete
d in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation.</t> implementation.</t>
<t>In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. <t>In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.
Indentation and white space in examples are provided only to illustrate element relationships Indentation and empty space in examples are provided only to illustrate element relationships
and are not a required feature of this protocol. and are not a required feature of this protocol.
</t> </t>
<t>The examples reference XML namespace prefixes that are used for the a ssociated XML namespaces. <t>The examples reference XML namespace prefixes that are used for the a ssociated XML namespaces.
Implementations MUST NOT depend on the example XML namespaces and instea d employ a proper Implementations <bcp14>MUST NOT</bcp14> depend on the example XML namesp aces and instead employ a proper
namespace-aware XML parser and serializer to interpret and namespace-aware XML parser and serializer to interpret and
output the XML documents. The example namespace prefixes used and their output the XML documents. The example namespace prefixes used and their
associated XML namespaces include:</t> associated XML namespaces include the following:</t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>"domain":</dt> <dt>domain:</dt>
<dd>urn:ietf:params:xml:ns:domain-1.0</dd> <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> <dd>urn:ietf:params:xml:ns:contact-1.0</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="rrr" numbered="true" toc="default"> <section anchor="rrr" numbered="true" toc="default">
<name>Registrant, Registrar, Registry</name> <name>Registrant, Registrar, Registry</name>
<t>The EPP RFCs refer to client and server, but when it comes to transfers <t>The EPP RFCs refer to "client" and "server", but when it comes to trans
, there are three types of actors that are involved. fers, there are three types of actors that are involved.
This document will refer to the actors as registrant, registrar, and re This document will refer to these actors as "registrant", "registrar",
gistry. <xref target="RFC8499" format="default"/> defines these terms formally and "registry". <xref target="RFC8499" format="default"/> defines these terms
for the Domain Name System (DNS). formally for the Domain Name System (DNS).
The terms are further described below to cover their roles as actors of The terms are further described below to cover their roles as actors u
using the authorization information in the transfer process of any object in th sing the authorization information in the transfer process of any object in the
e registry, registry,
such as a domain name or a contact:</t> such as a domain name or a contact:</t>
<dl newline="false" spacing="compact" indent="4"> <dl newline="false" spacing="normal" indent="4">
<dt>"registrant":</dt> <dt>Registrant:</dt>
<dd> <dd>
<xref target="RFC8499" format="default"/> defines the registrant as "a <xref target="RFC8499" format="default"/> defines the registrant as "an in
n individual or organization on whose behalf a name in a zone is registered by t dividual or organization on whose behalf a name in a zone is registered by the r
he registry". egistry."
The registrant can be the owner of any object in the registry, such a The registrant can be the owner of any object in the registry, such
s a domain name or a contact. The registrant interfaces with the as a domain name or a contact. The registrant interfaces with the
registrar for provisioning the objects. A transfer is coordinated by registrar for provisioning the objects. A transfer is coordinated b
the registrant to transfer the sponsorship y the registrant to transfer the sponsorship
of the object from one registrar to another. The authorization infor of the object from one registrar to another. The authorization info
mation is meant to authenticate the registrant rmation is meant to authenticate the registrant
as the owner of the object to the non-sponsoring registrar and to aut as the owner of the object to the non-sponsoring registrar and to au
horize the transfer.</dd> thorize the transfer.</dd>
<dt>"registrar":</dt> <dt>Registrar:</dt>
<dd> <dd>
<xref target="RFC8499" format="default"/> defines the registrar as "a <xref target="RFC8499" format="default"/> defines the registrar as "a
service provider that acts as a go-between for registrants and registries". service provider that acts as a go-between for registrants and registries."
The registrar interfaces with the registrant for the provisioning of The registrar interfaces with the registrant for the provisioning of
objects, such as domain names and contacts, and with the objects, such as domain names and contacts, and with the
registries to satisfy the registrant's provisioning requests. A regi registries to satisfy the registrant's provisioning requests. A reg
strar may directly interface with the registrant istrar may (1)&nbsp;directly interface with the registrant or (2)&nbsp;indirectl
or may indirectly interface with the registrant, typically through on y interface with the registrant, typically through one or more resellers. Imple
e or more resellers. Implementing a transfer using menting a transfer using
secure authorization information extends through the registrar's rese secure authorization information extends through the registrar's res
ller channel up to the direct interface with the registrant. The eller channel up to the direct interface with the registrant. The
registrar's interface with the registries uses EPP. The registrar's registrar's interface with the registries uses EPP. The registrar's
interface with its reseller channel or the registrant is registrar-specific. interface with its reseller channel or the registrant is registrar specific.
In the EPP RFCs, the registrar is referred to as the "client", since In the EPP RFCs, the registrar is referred to as the "client", since
EPP is the protocol used between the registrar and the registry. EPP is the protocol used between the registrar and the registry.
The sponsoring registrar is the authorized registrar to manage object The sponsoring registrar is the authorized registrar to manage objec
s on behalf of the registrant. A non-sponsoring registrar ts on behalf of the registrant. A non-sponsoring registrar
is not authorized to manage objects on behalf of the registrant. A t is not authorized to manage objects on behalf of the registrant. A
ransfer of an object's sponsorship is from one registrar, transfer of an object's sponsorship is from one registrar,
referred to as the losing registrar, to another registrar, referred t referred to as the "losing registrar", to another registrar, referre
o as the gaining registrar.</dd> d to as the "gaining registrar".</dd>
<dt>"registry":</dt> <dt>Registry:</dt>
<dd> <dd>
<xref target="RFC8499" format="default"/> defines the registry as "the <xref target="RFC8499" format="default"/> defines the registry as "the
administrative operation of a zone that allows registration of names within the administrative operation of a zone that allows registration of names within tha
zone". t zone."
The registry typically interfaces with the registrars over EPP and ge The registry typically interfaces with the registrars over EPP and g
nerally does not enerally does not
interact directly with the registrant. In the EPP RFCs, the registry interact directly with the registrant. In the EPP RFCs, the registr
is referred to as the "server", since EPP is the protocol used between y 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 spo the registrar and the registry. The registry has a record of the sp
nsoring registrar for each object and provides the mechanism onsoring registrar for each object and provides the mechanism
(over EPP) to coordinate a transfer of an object's sponsorship betwee (over EPP) to coordinate a transfer of an object's sponsorship betwe
n registrars.</dd> en registrars.</dd>
</dl> </dl>
</section> </section>
<section anchor="signal-client-server-support" numbered="true" toc="default" > <section anchor="signal-client-server-support" numbered="true" toc="default" >
<name>Signaling Client and Server Support</name> <name>Signaling Client and Server Support</name>
<t>This document does not define new protocol but an operational practice using the existing EPP protocol, where <t>This document does not define a new protocol; rather, it defines an ope rational 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 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 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 client includes the namespace URI in an &lt;svcExtension&gt; &lt;extURI&gt
; element of the <xref target="RFC5730" format="default"/> &lt;login&gt; Command ; element of the &lt;login&gt; command <xref target="RFC5730" format="default"/>
. .
The server includes the namespace URI in an &lt;svcExtension&gt; &lt;extUR The server includes the namespace URI in an &lt;svcExtension&gt; &lt;extUR
I&gt; element of the <xref target="RFC5730" format="default"/> Greeting.</t> I&gt; element of the greeting <xref target="RFC5730" format="default"/>.</t>
<t>A client that receives the namespace URI in the server's Greeting exten <t>A client that receives the namespace URI in the server's greeting exten
sion services can expect the following supported behavior by the server: sion services can expect the following supported behavior by the server:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>Support an empty authorization information value with a create comma <li>Support for an empty authorization information value with a &lt;crea
nd.</li> te&gt; command.</li>
<li>Support unsetting authorization information with an update command.< <li>Support for unsetting authorization information with an &lt;update&g
/li> t; command.</li>
<li>Support validating authorization information with an info command.</ <li>Support for validating authorization information with an &lt;info&gt
li> ; command.</li>
<li>Support not returning an indication whether the authorization inform <li>Support for not returning an indication of whether the authorization
ation is set or unset to the non-sponsoring registrar.</li> information is set or unset to the non-sponsoring registrar.</li>
<li>Support returning an empty authorization information value to the sp <li>Support for returning an empty authorization information value to th
onsoring registrar when the authorization information is set in an info response e sponsoring registrar when the authorization information is set in an info resp
.</li> onse.</li>
<li>Support allowing for the passing of a matching non-empty authorizati <li>Support for allowing the passing of a matching non-empty authorizati
on information value to authorize a transfer.</li> on information value to authorize a transfer.</li>
<li>Support automatically unsetting the authorization information upon a <li>Support for automatically unsetting the authorization information up
successful completion of transfer.</li> on successful completion of a transfer.</li>
</ol> </ol>
<t>A server that receives the namespace URI in the client's &lt;login&gt; Command extension services, can expect the following supported behavior by the c lient: <t>A server that receives the namespace URI in the client's &lt;login&gt; command extension services can expect the following supported behavior by the cl ient:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>Support generation of authorization information using a secure rando <li>Support for the generation of authorization information using a secu
m value.</li> re random value.</li>
<li>Support only setting the authorization information when there is a t <li>Support for only setting the authorization information when a transf
ransfer in process.</li> er is in process.</li>
</ol> </ol>
</section> </section>
<section anchor="secureAuthInfo" numbered="true" toc="default"> <section anchor="secureAuthInfo" numbered="true" toc="default">
<name>Secure Authorization Information</name> <name>Secure Authorization Information</name>
<t>The authorization information in the EPP RFCs (<xref target="RFC5731" f <t>The EPP RFCs (<xref target="RFC5731" format="default"/> and <xref targe
ormat="default"/> and <xref target="RFC5733" format="default"/>) that support tr t="RFC5733" format="default"/>) use password-based authorization information to
ansfer use support transfer with the &lt;domain:pw&gt; element <xref target="RFC5731" forma
password-based authorization information (<xref target="RFC5731" format t="default"/> and with the &lt;contact:pw&gt; element <xref target="RFC5733" for
="default"/> with the &lt;domain:pw&gt; element and <xref target="RFC5733" forma mat="default"/>.
t="default"/> with the &lt;contact:pw&gt; element).
Other EPP objects that support password-based authorization information for Other EPP objects that support password-based authorization information for
transfer can use the Secure Authorization Information defined in this d transfer can use secure authorization information as defined in this d
ocument. For the ocument. For
authorization information to be secure, it must be generated using a stro authorization information to be secure, it must be generated using a stro
ng random value and have a short time-to-live (TTL). ng random value and have a short TTL. The security of the authorization informat
The security of the authorization information is defined in the ion is defined in the
following sections.</t> following sections.</t>
<section anchor="secureRandomAuthInfo" numbered="true" toc="default"> <section anchor="secureRandomAuthInfo" numbered="true" toc="default">
<name>Secure Random Authorization Information</name> <name>Secure Random Authorization Information</name>
<t>For authorization information to be secure, it MUST be generated <t>For authorization information to be secure, it <bcp14>MUST</bcp14> be generated
using a secure random value. The authorization information is treated 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 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 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 N). Given a the desired entropy H, in the equation L = ROUNDUP(H / log<sub>2</sub> N) . Given a
target entropy, the required length can be calculated after deciding on t he target entropy, the required length can be calculated after deciding on t he
set of characters that will be randomized. In accordance with current set of characters that will be randomized. In accordance with current
best practices and noting that the authorization information is a best practices and noting that the authorization information is a
machine-generated value, the implementation SHOULD use at least 128 bits of machine-generated value, the implementation <bcp14>SHOULD</bcp14> use at least 128 bits of
entropy as the value of H. The lengths below are calculated using that entropy as the value of H. The lengths below are calculated using that
value.</t> value.</t>
<t keepWithNext="true">Calculation of the required length with 128 bits <t>Calculation of the required length with 128 bits of entropy and with
of entropy and with the set of all printable ASCII characters except space (0x20 the set of all printable ASCII characters except space (0x20), which consists of
), which consists of the 94 characters 0x21-0x7E.</t> the 94 characters 0x21-0x7E:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ROUNDUP(128 / log2 <t>ROUNDUP(128 / log<sub>2</sub> 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) =
94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 20</t>
]]></artwork> <t>Calculation of the required length with 128 bits of entropy and with
<t keepWithNext="true">Calculation of the required length with 128 bits the set of case-insensitive alphanumeric characters, which consists of 36 charac
of entropy and with the set of case insensitive alphanumeric characters, which c ters (a-z A-Z 0-9):</t>
onsists of 36 characters (a-z A-Z 0-9).</t> <t>ROUNDUP(128 / log<sub>2</sub> 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) =
<artwork name="" type="" align="left" alt=""><![CDATA[ROUNDUP(128 / log2 25</t>
36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
]]></artwork>
<t>The strength of the random authorization information is dependent on the <t>The strength of the random authorization information is dependent on the
random number generator. Suitably strong random number generators are random number generator. Suitably strong random number generators are
available in a wide variety of implementation environments, including the available in a wide variety of implementation environments, including the
interfaces listed in Sections 7.1.2 and 7.1.3 of <xref target="RFC4086" fo interfaces listed in Sections&nbsp;<xref target="RFC4086" section="7.1.2"
rmat="default"/>. In environments sectionFormat="bare"/> and <xref target="RFC4086" section="7.1.3"
sectionFormat="bare"/> of <xref target="RFC4086"/>. In environments
that do not provide interfaces to strong random number that do not provide interfaces to strong random number
generators, the practices defined in <xref target="RFC4086" format="defaul generators, the practices defined in <xref target="RFC4086" format="defaul
t"/> and section 4.7.1 of the t"/> and Section&nbsp;4.7.1 of the <xref target="FIPS-140-2">NIST Federal Inform
<xref target="FIPS-140-2">NIST Federal Information Processing Standards (F ation Processing Standards (FIPS) Publication 140-2</xref> can be followed to pr
IPS) Publication 140-2</xref> can be followed to produce random values that will oduce random values that will be
be resistant to attack. (Note: FIPS 140-2 has been superseded by FIPS 140-3,
resistant to attack.</t> but
FIPS 140-3 does not contain information regarding random number generators
.)</t>
</section> </section>
<section anchor="authInfoTTL" numbered="true" toc="default"> <section anchor="authInfoTTL" numbered="true" toc="default">
<name>Authorization Information Time-To-Live (TTL)</name> <name>Authorization Information Time To Live (TTL)</name>
<t>The authorization information SHOULD only be set when there is a tran <t>The authorization information <bcp14>SHOULD</bcp14> only be set when
sfer in process. This implies that the authorization information a transfer is in process. This implies that the authorization information
has a Time-To-Live (TTL) by which the authorization information is cl has a TTL by which the authorization information is cleared when the
eared when the TTL expires. The EPP RFCs have no definition of TTL, TTL expires. The EPP RFCs do not provide definitions for TTL,
but since the server supports the setting and unsetting of the author but since the server supports the setting and unsetting of the autho
ization information by the sponsoring registrar, the sponsoring registrar rization information by the sponsoring registrar, the sponsoring registrar
can apply a TTL based on client policy. The TTL client policy may be can apply a TTL based on client policy. The TTL client policy may b
based on proprietary registrar-specific criteria, which provides for a e based on proprietary registrar-specific criteria, which provides for a
transfer-specific TTL tuned for the particular circumstances of the t transfer-specific TTL tuned for the particular circumstances of the
ransaction. transaction.
The sponsoring registrar will be aware of the TTL and the sponsoring The sponsoring registrar will be aware of the TTL, and the sponsorin
registrar g registrar
MUST inform the registrant of the TTL when the authorization informat <bcp14>MUST</bcp14> inform the registrant of the TTL when the author
ion is provided to the registrant.</t> ization information is provided to the registrant.</t>
</section> </section>
<section anchor="authInfoStorageTransport" numbered="true" toc="default"> <section anchor="authInfoStorageTransport" numbered="true" toc="default">
<name>Authorization Information Storage and Transport</name> <name>Authorization Information Storage and Transport</name>
<t>To protect the disclosure of the authorization information, the follo wing requirements apply:</t> <t>To protect the disclosure of the authorization information, the follo wing requirements apply:</t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>The authorization information MUST be stored by the registry using <li>The authorization information <bcp14>MUST</bcp14> be stored by the
a strong one-way cryptographic hash, with registry using a strong one-way cryptographic hash with
at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-1 at least a 256-bit hash function, such as SHA-256 <xref target="FIPS-1
80-4"/>, and with a per-authorization information random salt, 80-4"/>, and with a per-authorization information random salt
with at least 128 bits.</li> with at least 128 bits.</li>
<li>Empty authorization information MUST be stored as an undefined val ue that is referred to as a NULL value. <li>An empty authorization information value <bcp14>MUST</bcp14> be st ored as an undefined value that is referred to as a "NULL" value.
The representation of a NULL (undefined) value is dependent on the typ e of database used.</li> The representation of a NULL (undefined) value is dependent on the typ e of database used.</li>
<li>The authorization information MUST NOT be stored by the losing reg <li>The authorization information <bcp14>MUST NOT</bcp14> be stored by
istrar.</li> the losing registrar.</li>
<li>The authorization information MUST only be stored by the gaining r <li>The authorization information <bcp14>MUST</bcp14> only be stored b
egistrar as a "transient" value in support of the transfer process.</li> y the gaining registrar as a "transient" value in support of the transfer proces
<li>The plain text version of the authorization information MUST NOT b s.</li>
e written to any logs by a registrar or the registry, nor <li>The plain-text version of the authorization information <bcp14>MUS
T 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> otherwise recorded where it will persist beyond the transfer process. </li>
<li>All communication that includes the authorization information MUST <li>All communication that includes the authorization information <bcp
be over an encrypted channel, such as defined in <xref target="RFC5734" format= 14>MUST</bcp14> be over an encrypted channel (for example, see <xref target="RFC
"default"/> for EPP.</li> 5734" format="default"/>) for EPP.</li>
<li>The registrar's interface for communicating the authorization info <li>The registrar's interface for communicating the authorization info
rmation with the registrant MUST be over an authenticated and encrypted channel. rmation with the registrant <bcp14>MUST</bcp14> be over an authenticated and enc
</li> rypted channel.</li>
</ol> </ol>
</section> </section>
<section anchor="authInfoMatching" numbered="true" toc="default"> <section anchor="authInfoMatching" numbered="true" toc="default">
<name>Authorization Information Matching</name> <name>Authorization Information Matching</name>
<t>To support the authorization information TTL, as defined in <xref tar get="authInfoTTL" format="default"/>, the authorization information must have ei ther a set or unset state. <t>To support the authorization information TTL, as described in <xref t arget="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 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, authorization information using a strong one-way cryptographic hash,
as defined in <xref target="authInfoStorageTransport" format="default"/> as described in <xref target="authInfoStorageTransport" format="default"
, authorization information that is set is />, authorization information that is set is
stored with a non-NULL hashed value. The empty authorization informatio stored with a non-NULL hashed value. The empty authorization informatio
n is used as input in both the <xref target="createCommand" format="default">cre n value is used as input in both the <xref target="createCommand" format="defaul
ate command</xref> and the <xref target="updateCommand" format="default">update t">&lt;create&gt; command</xref> and the <xref target="updateCommand" format="de
command</xref> to fault">&lt;update&gt; command</xref> to
define the unset state. The matching of the authorization information define the unset state. The matching of the authorization information
in the <xref target="infoCommandResponse" format="default">info command</xref> a in the <xref target="infoCommandResponse" format="default">&lt;info&gt; command<
nd the <xref target="transferRequestCommand" format="default">transfer request c /xref> and the <xref target="transferRequestCommand" format="default">&lt;transf
ommand</xref> is based on the following rules: er&gt; request command</xref> is based on the following rules:
</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>Any input authorization information value MUST NOT match an unset <li>Any input authorization information value <bcp14>MUST NOT</bcp14>
authorization information value. match an unset authorization information value.
This includes empty authorization information, such as &lt;domain:nu For example, in <xref target="RFC5731"/> the input &lt;domain:pw&gt;
ll/&gt; or &lt;domain:pw/&gt; in <xref target="RFC5731" format="default"/>, 2fooBAR&lt;/domain:pw&gt; must not match an unset authorization information valu
and non-empty authorization information, such as &lt;domain:pw&gt;2f e that used &lt;domain:null/&gt; or &lt;domain:pw/&gt;.</li>
ooBAR&lt;/domain:pw&gt; in <xref target="RFC5731" format="default"/>.</li> <li>An empty input authorization information value <bcp14>MUST NOT</bc
<li>An empty input authorization information value MUST NOT match any p14> match any set authorization information value.</li>
set authorization information value.</li> <li>A non-empty input authorization information value <bcp14>MUST</bcp
<li>A non-empty input authorization information value MUST be hashed a 14> be hashed and matched against the set authorization information value, which
nd matched against the set authorization information value, which is stored usin is stored using the same hash algorithm.</li>
g the same hash algorithm.</li>
</ol> </ol>
</section> </section>
</section> </section>
<section anchor="createTransferSecureAuthInfo" numbered="true" toc="default" > <section anchor="createTransferSecureAuthInfo" numbered="true" toc="default" >
<name>Create, Transfer, and Secure Authorization Information</name> <name>Create, Transfer, and Secure Authorization Information</name>
<t>To secure the transfer process using secure authorization information, as defined in <xref target="secureAuthInfo" format="default"/>, <t>To secure the transfer process using secure authorization information a s described in <xref target="secureAuthInfo" format="default"/>,
the client and server need to implement steps where the authorization info rmation is set only when a transfer is the client and server need to implement steps where the authorization info rmation is set only when a transfer is
actively in process and ensure that the authorization information is store d securely and transported only over secure channels. The steps actively in process and ensure that the authorization information is store d securely and transported only over secure channels. The steps
in management of the authorization information for transfers include:</t> for management of the authorization information for transfers include the
<ol spacing="compact" type="1"> following:</t>
<li>Registrant requests to register the object with the registrar. Regi <ol spacing="normal" type="1">
strar sends the create command, with an empty authorization information value, t <li>The registrant requests to register the object with the registrar. T
o the registry, as defined in <xref target="createCommand" format="default"/>.</ he registrar sends the &lt;create&gt; command with an empty authorization inform
li> ation value
<li>Registrant requests from the losing registrar the authorization info to the registry, as described in <xref target="createCommand" format="default"/>
rmation to provide to the gaining registrar.</li> .</li>
<li>Losing registrar generates a secure random authorization information <li>The registrant requests from the losing registrar the authorization
value, sends it to the registry as defined in <xref target="updateCommand" form information to provide to the gaining registrar.</li>
at="default"/>, and provides it to the registrant.</li> <li>The losing registrar generates a secure random authorization informa
<li>Registrant provides the authorization information value to the gaini tion value and sends it to the registry, as described in <xref target="updateCom
ng registrar.</li> mand" format="default"/>, and then provides it to the registrant.</li>
<li>Gaining registrar optionally verifies the authorization information <li>The registrant provides the authorization information value to the g
with the info command to the registry, as defined in <xref target="infoCommandRe aining registrar.</li>
sponse" format="default"/>.</li> <li>The gaining registrar optionally verifies the authorization informat
<li>Gaining registrar sends the transfer request with the authorization ion with the &lt;info&gt; command to the registry, as described in <xref target=
information to the registry, as defined in <xref target="transferRequestCommand" "infoCommandResponse" format="default"/>.</li>
format="default"/>.</li> <li>The gaining registrar sends the transfer request with the authorizat
<li>If the transfer successfully completes, the registry automatically u ion information to the registry, as described in <xref target="transferRequestCo
nsets the authorization information; mmand" format="default"/>.</li>
otherwise the losing registrar unsets the authorization information <li>If the transfer completes successfully, the registry automatically u
when the TTL expires, as defined in <xref target="updateCommand" format="default nsets the authorization information;
"/>.</li> otherwise, the losing registrar unsets the authorization information
when the TTL expires; see <xref target="updateCommand" format="default"/>.</li>
</ol> </ol>
<t>The following sections outline the practices of the EPP commands and re sponses between the registrar and the registry that supports secure authorizatio n information <t>The following sections outline the practices of the EPP commands and re sponses between the registrar and the registry that supports secure authorizatio n information
for transfer.</t> for transfer.</t>
<section anchor="createCommand" numbered="true" toc="default"> <section anchor="createCommand" numbered="true" toc="default">
<name>Create Command</name> <name>&lt;Create&gt; Command</name>
<t>For a create command, the registry MUST allow for the passing of an e <t>For a &lt;create&gt; command, the registry <bcp14>MUST</bcp14> allow
mpty authorization information value and MAY disallow for the passing of a non-e the passing of an empty authorization information value and <bcp14>MAY</bcp14> d
mpty isallow the passing of a non-empty
authorization information value. By having an empty authorization infor authorization information value. By having an empty authorization infor
mation value on create, the object is initially not in the transfer process. An mation value on create, the object is initially not involved in the transfer pro
y EPP object extension that supports setting cess. Any EPP object extension that supports setting
the authorization information with a "eppcom:pwAuthInfoType" element can the authorization information with an "eppcom:pwAuthInfoType" element ca
have an empty authorization information value passed. Examples of such extensi n pass an empty authorization information value. Examples of such extensions ar
ons are <xref target="RFC5731" format="default"/> and <xref target="RFC5733" for e found in <xref target="RFC5731" format="default"/> and <xref target="RFC5733"
mat="default"/>.</t> format="default"/>.</t>
<t keepWithNext="true">Example of passing an empty authorization informa <t keepWithNext="true">Example of passing an empty authorization information v
tion value in an <xref target="RFC5731" format="default"/> domain name create co alue in a domain name &lt;create&gt; command <xref target="RFC5731" format="defa
mmand:</t> ult"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <create> C: <create>
C: <domain:create C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw/> C: <domain:pw/>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:create> C: </domain:create>
C: </create> C: </create>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">Example of passing an empty authorization informa
tion value in an <xref target="RFC5733" format="default"/> contact create comman <t keepWithNext="true">Example of passing an empty authorization informa
d:</t> tion value in a contact &lt;create&gt; command <xref target="RFC5733" format="de
<artwork name="" type="" align="left" alt=""><![CDATA[ fault"/>:</t>
<sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <create> C: <create>
C: <contact:create C: <contact:create
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C: <contact:id>sh8013</contact:id> C: <contact:id>sh8013</contact:id>
C: <contact:postalInfo type="int"> C: <contact:postalInfo type="int">
C: <contact:name>John Doe</contact:name> C: <contact:name>John Doe</contact:name>
C: <contact:addr> C: <contact:addr>
skipping to change at line 396 skipping to change at line 382
C: </contact:postalInfo> C: </contact:postalInfo>
C: <contact:email>jdoe@example.com</contact:email> C: <contact:email>jdoe@example.com</contact:email>
C: <contact:authInfo> C: <contact:authInfo>
C: <contact:pw/> C: <contact:pw/>
C: </contact:authInfo> C: </contact:authInfo>
C: </contact:create> C: </contact:create>
C: </create> C: </create>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="updateCommand" numbered="true" toc="default"> <section anchor="updateCommand" numbered="true" toc="default">
<name>Update Command</name> <name>&lt;Update&gt; Command</name>
<t> <t>
For an update command, the registry MUST allow for the setting and For an &lt;update&gt; command, the registry <bcp14>MUST</bcp14> allow the setting and
unsetting of the authorization information. The registrar sets the unsetting of the authorization information. The registrar sets the
authorization information by first generating a strong, random authorization information by first generating a strong, random
authorization information value, based on <xref target="secureRandomAu authorization information value, based on the information provided in
thInfo" format="default"/>, and setting it <xref target="secureRandomAuthInfo" format="default"/>, and setting it
in the registry in the update command. The importance of generating in the registry in the &lt;update&gt; command. The importance of gene
rating
strong authorization information values cannot be overstated: secure strong authorization information values cannot be overstated: secure
transfers are very important to the Internet to mitigate damage in the transfers are very important to the Internet to mitigate damage in the
form of theft, fraud, and other abuse. It is form of theft, fraud, and other abuse. It is
critical that registrars only use strong, critical that registrars only use strong,
randomly generated authorization information values. randomly generated authorization information values.
</t> </t>
<t> <t>
Because of this, registries may validate the randomness of Because of this, registries may validate the randomness of
the authorization information based on the length and character set the authorization information based on the length and character set
required by the registry. For example, required by the registry -- for example,
validating an authorization value contains a combination of upper-case, validating that an authorization value contains a combination of upperca
lower-case, and non-alphanumeric characters, in an attempt to se,
assess the strength of the value, and return an EPP error result of lowercase, and non-alphanumeric characters in an attempt to
2202 if the check fails. assess the strength of the value and returning an EPP error result of
2202 ("Invalid authorization information") <xref target="RFC5730"/>
if the check fails.
</t> </t>
<t> <t>
Such checks are, by their nature, heuristic and imperfect, and Such checks are, by their nature, heuristic and imperfect, and
may identify well-chosen authorization may identify well-chosen authorization
information values as being not sufficiently strong. Registrars, information values as being not sufficiently strong. Registrars,
therefore, must be prepared for an error response of 2202, therefore, must be prepared for an error response of 2202 and respond
"Invalid authorization information", and respond by generating by
a new value and trying again, possibly more than once. generating a new value and trying again, possibly more than once.
</t> </t>
<t> <t>
Often, the registrar has the "clientTransferProhibited" status set, so to start the transfer process, the "clientTransferProhibited" status needs to b e Often, the registrar has the "clientTransferProhibited" status set, so to start the transfer process, the "clientTransferProhibited" status needs to b e
removed, and the strong, random authorization information value needs to removed, and the strong, random authorization information value needs to
be set. The registrar MUST define a time-to-live (TTL), as defined in <xref ta be set. The registrar <bcp14>MUST</bcp14> define a TTL, as described in <xref
rget="authInfoTTL" format="default"/>, target="authInfoTTL" format="default"/>,
where if the TTL expires the registrar will unset the authorization info and if the TTL expires, the registrar will unset the authorization infor
rmation. mation.
</t> </t>
<t keepWithNext="true">Example of removing the "clientTransferProhibited <t keepWithNext="true">Example of removing the "clientTransferProhibited
" status and setting the authorization information in an <xref target="RFC5731" " status and setting the authorization information in a domain name &lt;update&g
format="default"/> domain name update command:</t> t; command <xref target="RFC5731" format="default"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <update> C: <update>
C: <domain:update C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:rem> C: <domain:rem>
C: <domain:status s="clientTransferProhibited"/> C: <domain:status s="clientTransferProhibited"/>
C: </domain:rem> C: </domain:rem>
skipping to change at line 457 skipping to change at line 444
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C: </domain:pw> C: </domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:chg> C: </domain:chg>
C: </domain:update> C: </domain:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t> <t>
When the registrar-defined TTL expires, the sponsoring registrar MUST ca ncel the transfer process by unsetting the authorization information value and M AY add back statuses like the "clientTransferProbited" status. When the registrar-defined TTL expires, the sponsoring registrar <bcp14> MUST</bcp14> cancel the transfer process by unsetting the authorization informat ion value and <bcp14>MAY</bcp14> add back statuses like the "clientTransferProhi bited" status.
Any EPP object extension that supports setting Any EPP object extension that supports setting
the authorization information with a "eppcom:pwAuthInfoType" element, ca n have an empty authorization information value passed. Examples of such extensi ons are <xref target="RFC5731" format="default"/> and <xref target="RFC5733" for mat="default"/>. Setting an the authorization information with an "eppcom:pwAuthInfoType" element ca n pass an empty authorization information 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 informati on. <xref target="RFC5731" format="default"/> supports an explicit mechanism of unsetting the authorization information, by passing the &lt;domain:null&gt; aut horization empty authorization information value unsets the authorization informati on. <xref target="RFC5731" format="default"/> supports an explicit mechanism of unsetting the authorization information, by passing the &lt;domain:null&gt; aut horization
information value. The registry MUST support unsetting the authorizatio n information by accepting an empty authorization information value and acceptin g an explicit unset element if it information value. The registry <bcp14>MUST</bcp14> support unsetting t he authorization information by accepting an empty authorization information val ue and accepting an explicit unset element if it
is supported by the object extension.</t> is supported by the object extension.</t>
<t keepWithNext="true">Example of adding the "clientTransferProhibited" <t keepWithNext="true">Example of adding the "clientTransferProhibited"
status and unsetting the authorization information explicitly in an <xref targe status and unsetting the authorization information explicitly in a domain name &
t="RFC5731" format="default"/> domain name update command:</t> lt;update&gt; command <xref target="RFC5731" format="default"/>:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <update> C: <update>
C: <domain:update C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:add> C: <domain:add>
C: <domain:status s="clientTransferProhibited"/> C: <domain:status s="clientTransferProhibited"/>
C: </domain:add> C: </domain:add>
C: <domain:chg> C: <domain:chg>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:null/> C: <domain:null/>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:chg> C: </domain:chg>
C: </domain:update> C: </domain:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">Example of unsetting the authorization informatio
n with an empty authorization information value in an <xref target="RFC5731" fo <t keepWithNext="true">Example of unsetting the authorization informatio
rmat="default"/> domain name update command:</t> n with an empty authorization information value in a domain name &lt;update&gt;
<artwork name="" type="" align="left" alt=""><![CDATA[ command <xref target="RFC5731" format="default"/>:</t>
<sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <update> C: <update>
C: <domain:update C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:add> C: <domain:add>
C: <domain:status s="clientTransferProhibited"/> C: <domain:status s="clientTransferProhibited"/>
C: </domain:add> C: </domain:add>
C: <domain:chg> C: <domain:chg>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw/> C: <domain:pw/>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:chg> C: </domain:chg>
C: </domain:update> C: </domain:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t keepWithNext="true">Example of unsetting the authorization informatio
n with an empty authorization information value in an <xref target="RFC5733" fo <t keepWithNext="true">Example of unsetting the authorization informatio
rmat="default"/> contact update command:</t> n with an empty authorization information value in a contact &lt;update&gt; comm
<artwork name="" type="" align="left" alt=""><![CDATA[ and <xref target="RFC5733" format="default"/>:</t>
<sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <update> C: <update>
C: <contact:update C: <contact:update
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C: <contact:id>sh8013</contact:id> C: <contact:id>sh8013</contact:id>
C: <contact:chg> C: <contact:chg>
C: <contact:authInfo> C: <contact:authInfo>
C: <contact:pw/> C: <contact:pw/>
C: </contact:authInfo> C: </contact:authInfo>
C: </contact:chg> C: </contact:chg>
C: </contact:update> C: </contact:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="infoCommandResponse" numbered="true" toc="default"> <section anchor="infoCommandResponse" numbered="true" toc="default">
<name>Info Command and Response</name> <name>&lt;Info&gt; Command and Response</name>
<t>For an info command, the registry MUST allow for the passing of a non <t>For an &lt;info&gt; command, the registry <bcp14>MUST</bcp14> allow t
-empty authorization information value for verification. The gaining registrar he passing of a non-empty authorization information value for verification. The
can pre-verify the authorization information gaining registrar can pre-verify the authorization information
provided by the registrant prior to submitting the transfer request with provided by the registrant prior to submitting the transfer request with
the use of the info command. The the use of the &lt;info&gt; command. The
registry compares the hash of the passed authorization information with the hashed authorization information value stored for the object. 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 authorizatio When the authorization information is not set or the passed authorizatio
n information does not match the previously set value, the registry MUST return n information does not match the previously set value, the registry <bcp14>MUST<
an EPP error result code of 2202 <xref target="RFC5730" format="default"/>.</t> /bcp14> return an EPP error result code of 2202 <xref target="RFC5730" format="d
<t keepWithNext="true">Example of passing a non-empty authorization info efault"/>.</t>
rmation value in an <xref target="RFC5731" format="default"/> domain name info c <t keepWithNext="true">Example of passing a non-empty authorization info
ommand to verify the authorization information value:</t> rmation value in a domain name &lt;info&gt; command <xref target="RFC5731" forma
<artwork name="" type="" align="left" alt=""><![CDATA[ t="default"/> to verify the authorization information value:</t>
<sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <info> C: <info>
C: <domain:info C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name> C: <domain:name>example.com</domain:name>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C: </domain:pw> C: </domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:info> C: </domain:info>
C: </info> C: </info>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t>The info response in object extensions, such as <xref target="RFC5731
" format="default"/> and <xref target="RFC5733" format="default"/>, MUST NOT inc <t>The info response in object extensions, such as those defined in <xre
lude the optional authorization information element with a non-empty authorizati f target="RFC5731" format="default"/> and <xref target="RFC5733" format="default
on value. The authorization "/>, <bcp14>MUST NOT</bcp14> include the optional authorization information elem
information is stored as a hash in the registry, so returning the ent with a non-empty authorization value. The authorization
plain text authorization information is not possible, unless a valid plain text information is stored as a hash in the registry, so returning th
authorization information is passed in the info command. e plain-text authorization information is not possible, unless valid plain-text
The registry MUST NOT return any indication of whether the authorization authorization information is passed in the &lt;info&gt; command.
information is set or unset to the non-sponsoring registrar by no The registry <bcp14>MUST NOT</bcp14> return any indication of whether the au
t returning the authorization information element in the response. thorization
The registry MAY return an indication to the sponsoring registrar that the a information is set or unset to the non-sponsoring registrar by n
uthorization information is set by using an empty authorization information valu ot returning the authorization information element in the response.
e. The registry <bcp14>MAY</bcp14> return an indication to the sponsoring regis
The registry MAY return an indication to the sponsoring registrar that the a trar that the authorization information is set by using an empty authorization i
uthorization information is unset by not returning the authorization information nformation value.
element.</t> The registry <bcp14>MAY</bcp14> return an indication to the sponsoring regis
<t keepWithNext="true">Example of returning an empty authorization infor trar that the authorization information is unset by not returning the authorizat
mation value in an <xref target="RFC5731" format="default"/> domain name info re ion information element.</t>
sponse to indicate to the sponsoring registrar that the authorization informatio <t keepWithNext="true">Example of returning an empty authorization infor
n is set:</t> mation value in a domain name info response <xref target="RFC5731" format="defau
<artwork name="" type="" align="left" alt=""><![CDATA[ lt"/> to indicate to the sponsoring registrar that the authorization information
is set:</t>
<sourcecode name="" type="xml"><![CDATA[
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response> S: <response>
S: <result code="1000"> S: <result code="1000">
S: <msg>Command completed successfully</msg> S: <msg>Command completed successfully</msg>
S: </result> S: </result>
S: <resData> S: <resData>
S: <domain:infData S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>example.com</domain:name> S: <domain:name>example.com</domain:name>
skipping to change at line 589 skipping to change at line 581
S: <domain:pw/> S: <domain:pw/>
S: </domain:authInfo> S: </domain:authInfo>
S: </domain:infData> S: </domain:infData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="transferRequestCommand" numbered="true" toc="default"> <section anchor="transferRequestCommand" numbered="true" toc="default">
<name>Transfer Request Command</name> <name>&lt;Transfer&gt; Request Command</name>
<t>For a Transfer Request Command, the registry MUST allow for the passi <t>For a &lt;transfer&gt; request command, the registry <bcp14>MUST</bcp
ng of a non-empty authorization information value to authorize a transfer. The 14> allow the passing of a non-empty authorization information value to authoriz
e a transfer. The
registry compares the hash of the passed authorization information with the hashed authorization information value stored for the object. 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 authorizatio When the authorization information is not set or the passed authorizatio
n information does not match the previously set value, the registry MUST return n information does not match the previously set value, the registry <bcp14>MUST<
an EPP error result code of 2202 <xref target="RFC5730" format="default"/>. /bcp14> return an EPP error result code of 2202 <xref target="RFC5730" format="d
Whether the transfer occurs immediately or is pending is up to server po efault"/>.
licy. When the transfer occurs immediately, the registry MUST return the EPP su Whether the transfer occurs immediately or is pending is up to server po
ccess result code of 1000 and licy. When the transfer occurs immediately, the registry <bcp14>MUST</bcp14> re
when the transfer is pending, the registry MUST return the EPP success r turn the EPP success result code of 1000 ("Command completed successfully") <xre
esult code of 1001. The losing registrar MUST be informed of a successful trans f target="RFC5730" format="default"/>, and
fer request using an EPP poll message.</t> when the transfer is pending, the registry <bcp14>MUST</bcp14> return th
<t keepWithNext="true">Example of passing a non-empty authorization info e EPP success result code of 1001 ("Command completed successfully; action pendi
rmation value in an <xref target="RFC5731" format="default"/> domain name transf ng"). The losing registrar <bcp14>MUST</bcp14> be informed of a successful tran
er request command to authorize the transfer:</t> sfer request using an EPP &lt;poll&gt; message.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <t keepWithNext="true">Example of passing a non-empty authorization info
rmation value in a domain name &lt;transfer&gt; request command <xref target="RF
C5731" format="default"/> to authorize the transfer:</t>
<sourcecode name="" type="xml"><![CDATA[
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command> C: <command>
C: <transfer op="request"> C: <transfer op="request">
C: <domain:transfer C: <domain:transfer
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example1.com</domain:name> C: <domain:name>example1.com</domain:name>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C: </domain:pw> C: </domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:transfer> C: </domain:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
]]></artwork> ]]></sourcecode>
<t>Upon successful completion of the transfer, the registry MUST automat
ically unset the authorization information. <t>Upon successful completion of the transfer, the registry <bcp14>MUST<
If the transfer request is not submitted within the <xref target="authInfo /bcp14> automatically unset the authorization information.
TTL" format="default">time-to-live (TTL)</xref> or the transfer is cancelled or If the transfer request is not submitted within the <xref target="authInfo
rejected, TTL" format="default">TTL</xref> or the transfer is canceled or rejected,
the registrar MUST unset the authorization information as defined in <xref the registrar <bcp14>MUST</bcp14> unset the authorization information, as
target="updateCommand" format="default"/>.</t> described in <xref target="updateCommand" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="Transition" numbered="true" toc="default"> <section anchor="Transition" numbered="true" toc="default">
<name>Transition Considerations</name> <name>Transition Considerations</name>
<t>The goal of the transition considerations to the practice defined in th <t>
is document, referred to as the Secure Authorization Information Model, is to mi The goal of the transition considerations is to minimize the impact to the regis
nimize the impact to the registrars by supporting incremental steps of adoption. trars in supporting the Secure Authorization Information Model defined in this d
ocument by supporting incremental transition steps.
The transition steps are dependent on the starting point of the registr y. Registries may have different starting points, since some of the elements of the Secure Authorization Information Model may have already been implemented. The transition steps are dependent on the starting point of the registr y. 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 The considerations assume a starting point, referred to as the "Classic
Authorization Information Model, that have Authorization Information Model", which incorporates the following steps for ma
the following steps in the management of the authorization information nagement of the authorization information for transfers:
for transfers:</t> </t>
<ol spacing="compact" type="1"> <ol spacing="normal" type="1">
<li>Registrant requests to register the object with the registrar. Regi <li>The registrant requests to register the object with the registrar. T
strar sends the create command, with a non-empty authorization information value he registrar sends the &lt;create&gt; command, with a non-empty authorization in
, to the registry. The registry formation value, to the registry. The registry
stores the authorization information as an encrypted value and re quires a non-empty authorization information value for the life of the object. The registrar may store the long-lived authorization information.</li> stores the authorization information as an encrypted value and re quires 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 requests from the losing registr <li>At the time of transfer, the registrant requests from the losing reg
ar the authorization information to provide to the gaining registrar.</li> istrar the authorization information to provide to the gaining registrar.</li>
<li>Losing registrar retrieves the locally stored authorization informat <li>The losing registrar retrieves the locally stored authorization info
ion or queries the registry for authorization information using the info command rmation or queries the registry for authorization information using the &lt;info
, and provides it to the registrant. If the registry is queried, the authorizat &gt; command, and provides it to the registrant. If the registry is queried, th
ion information is decrypted and e authorization information is decrypted and
the plain text authorization information is returned in the info the plain-text authorization information is returned in the info
response to the registrar.</li> response to the registrar.</li>
<li>Registrant provides the authorization information value to the gaini <li>The registrant provides the authorization information value to the g
ng registrar.</li> aining registrar.</li>
<li>Gaining registrar optionally verifies the authorization information <li>The gaining registrar optionally verifies the authorization informat
with the info command to the registry, by passing the authorization information ion with the &lt;info&gt; command to the registry, by passing the authorization
in the info command to the registry.</li> information in the &lt;info&gt; command to the registry.</li>
<li>Gaining registrar sends the transfer request with the authorization <li>The gaining registrar sends the transfer request with the authorizat
information to the registry. The registry will decrypt the stored authorization ion information to the registry. The registry will decrypt the stored authoriza
information to compare to the passed authorization information.</li> tion information to compare to the passed authorization information.</li>
<li>If the transfer successfully completes, the authorization informatio <li>If the transfer completes successfully, the authorization informatio
n is not touched by the registry and may be updated by the gaining registrar usi n is not touched by the registry and may be updated by the gaining registrar usi
ng the update command. ng the &lt;update&gt; command.
If the transfer is cancelled or rejected, the losing registrar ma If the transfer is canceled or rejected, the losing registrar may
y reset the authorization information using the update command.</li> reset the authorization information using the &lt;update&gt; command.</li>
</ol> </ol>
<t>The gaps between the Classic Authorization Information Model and the Se <t>The gaps between the Classic Authorization Information Model and the Se
cure Authorization Information Model include:</t> cure Authorization Information Model include the following:</t>
<ol spacing="compact" type="1"> <ol 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 n ot being set on create and only being set when a transfer is in process.</li> <li>Registry requirement for a non-empty authorization information value on create and for the life of the object versus the authorization information n ot 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 vers <li>Registry not allowing the authorization information to be unset vers
us supporting the authorization to be unset in the update command.</li> us providing support for unsetting the authorization information in the &lt;upda
<li>Registry storing the authorization information as an encrypted value te&gt; command.</li>
versus as a hashed value.</li> <li>Registry storing the authorization information as an encrypted value
versus 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 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 regis try automatically unsetting the authorization information upon a successful tran sfer.</li> <li>Registry not touching the authorization information versus the regis try automatically unsetting the authorization information upon a successful tran sfer.</li>
<li>Registry may validate a shorter authorization information value usin g password complexity rules versus validating the randomness of a longer authori zation information value that meets the required bits of entropy.</li> <li>Registry possibly validating a shorter authorization information val ue using password complexity rules versus validating the randomness of a longer authorization information value that meets the required bits of entropy.</li>
</ol> </ol>
<t>The transition can be handled in the three phases defined in the sub-se ctions <xref target="TransitionFeatures" format="default"/>, <xref target="Trans itionStorage" format="default"/>, <xref target="TransitionEnforcement" format="d efault"/>.</t> <t>The transition can be handled in the three phases defined in Sections& nbsp;<xref target="TransitionFeatures" format="counter"/>, <xref target="Transit ionStorage" format="counter"/>, and <xref target="TransitionEnforcement" format= "counter"/>.</t>
<section anchor="TransitionFeatures" numbered="true" toc="default"> <section anchor="TransitionFeatures" numbered="true" toc="default">
<name>Transition Phase 1 - Features</name> <name>Transition Phase 1 - Features</name>
<t>The goal of the "Transition Phase 1 - Features" is to implement the n <t>The goal of "Transition Phase 1 - Features" is to implement the neede
eeded features in EPP so that the registrar can optionally implement the Secure d features in EPP so that the registrar can optionally implement the Secure Auth
Authorization Information Model. The features to implement are broken out by orization Information Model. The features to implement are broken out by
the command and responses below:</t> the commands and responses below:</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="normal">
<dt>Create Command:</dt> <dt>&lt;Create&gt; Command:</dt>
<dd>Change the create command to make the authorization information op <dd>Change the &lt;create&gt; command to make the authorization inform
tional, by allowing both a non-empty value and an empty value. ation optional, by allowing both a non-empty value and an empty value.
This enables a registrar to optionally create objects without an aut This enables a registrar to optionally create objects without an aut
horization information value, as defined in <xref target="createCommand" format= horization information value, as described in <xref target="createCommand" forma
"default"/>.</dd> t="default"/>.</dd>
<dt>Update Command:</dt> <dt>&lt;Update&gt; Command:</dt>
<dd>Change the update command to allow unsetting the authorization inf <dd>Change the &lt;update&gt; command to allow unsetting the authoriza
ormation, as defined in <xref target="updateCommand" format="default"/>. tion information, as described in <xref target="updateCommand" format="default"/
This enables the registrar to optionally unset the authorization inf >.
ormation when the TTL expires or when the transfer is cancelled or rejected.</dd This enables the registrar to optionally unset the authorization inf
> ormation when the TTL expires or when the transfer is canceled or rejected.</dd>
<dt>Transfer Approve Command and Transfer Auto-Approve:</dt> <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. <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 authorizat ion information set. This sets the default state of the object to not have the authorizat ion information set.
The registrar implementing the Secure Authorization Information Mode The registrar implementing the Secure Authorization Information Mode
l will not set the authorization information for an inbound transfer and the reg l will not set the authorization information for an inbound transfer, and the re
istrar implementing the gistrar implementing the
Classic Authorization Information Model will set the new authorizati Classic Authorization Information Model will set the new authorizati
on information upon the successful transfer.</dd> on information upon a successful transfer.</dd>
<dt>Info Response:</dt> <dt>Info Response:</dt>
<dd>Change the info command to not return the authorization informatio <dd>Change the &lt;info&gt; command to not return the authorization in
n in the info response, as defined in <xref target="infoCommandResponse" format= formation in the info response, as described in <xref target="infoCommandRespons
"default"/>. e" format="default"/>.
This sets up the implementation of "Transition Phase 2 - Storage", sin This sets up the implementation of "Transition Phase 2 - Storage" (<xr
ce the dependency in returning the authorization information in the info respons ef target="TransitionStorage"/>), since the dependency on returning the authoriz
e will be removed. ation information in the info response will be removed.
This feature is the only one that is not an optional change to the reg This feature is the only one that is not an optional change to the reg
istrar that has the potential of breaking the client, so it's recommended that t istrar, and this change could potentially break the client, so it's recommended
he registry provide notice of the change.</dd> that the registry provide notice of the change.</dd>
<dt>Info Command and Transfer Request:</dt> <dt>&lt;Info&gt; Command and Transfer Request:</dt>
<dd>Change the info command and the transfer request to ensure that a <dd>Change the &lt;info&gt; command and the transfer request to ensure
registrar cannot get an indication that the authorization information 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 whe n comparing a passed authorization to a non-matching set authorization informati on value or an unset value.</dd> is set or not set by returning the EPP error result code of 2202 whe n comparing a passed authorization to a non-matching set authorization informati on value or an unset value.</dd>
</dl> </dl>
</section> </section>
<section anchor="TransitionStorage" numbered="true" toc="default"> <section anchor="TransitionStorage" numbered="true" toc="default">
<name>Transition Phase 2 - Storage</name> <name>Transition Phase 2 - Storage</name>
<t>The goal of the "Transition Phase 2 - Storage" is to transition the r <t>The goal of "Transition Phase 2 - Storage" is to transition the regis
egistry to use hashed authorization information instead of encrypted authorizati try to use hashed authorization information instead of encrypted authorization i
on information. nformation.
There is no direct impact to the registrars, since the only visible in There is no direct impact on the registrars, since the only visible in
dication that the authorization information has been hashed is by not returning dication that the authorization information has been hashed is that the set
the set authorization information is not returned in the info response, as add
authorization information in the info response, which is addressed in ressed in <xref target="TransitionFeatures" format="default">"Transition Phase 1
<xref target="TransitionFeatures" format="default">Transition Phase 1 - Feature - Features"</xref>. Transitioning the authorization information storage includ
s</xref>. There are three steps to transition the authorization information sto es the
rage, which includes:</t> following three steps:
<dl newline="false" spacing="compact"> </t>
<dl newline="false" spacing="normal">
<dt>Hash New Authorization Information Values:</dt> <dt>Hash New Authorization Information Values:</dt>
<dd>Change the create command and the update command to hash instead o <dd>Change the &lt;create&gt; command and the &lt;update&gt; command t
f encrypting the authorization information.</dd> o hash rather than encrypt the authorization information.</dd>
<dt>Supporting Comparing Against Encrypted and Hashed Authorization In <dt>Support Comparison against Encrypted or Hashed Authorization Infor
formation:</dt> mation:</dt>
<dd>Change the info command and the transfer request command to be abl <dd>Change the &lt;info&gt; command and the &lt;transfer&gt; request c
e to compare a passed authorization information value with ommand to be able to compare a passed authorization information value with
either a hashed or encrypted authorization information value. This either a hashed or encrypted authorization information value. This
requires that the stored values are self-identifying as being in hashed or encry requires that the stored values be self-identifying as being in hashed or encryp
pted form.</dd> ted form.</dd>
<dt>Hash Existing Encrypted Authorization Information Values:</dt> <dt>Hash Existing Encrypted Authorization Information Values:</dt>
<dd>Convert the encrypted authorization information values stored in t he registry database to hashed values. <dd>Convert the encrypted authorization information values stored in t he registry database to hashed values.
The update is not a visible change to the registrar. The conversi on can be done over a period of time depending on registry policy.</dd> This update will not be visible to the registrar. The conversion can be done over a period of time, depending on registry policy.</dd>
</dl> </dl>
</section> </section>
<section anchor="TransitionEnforcement" numbered="true" toc="default"> <section anchor="TransitionEnforcement" numbered="true" toc="default">
<name>Transition Phase 3 - Enforcement</name> <name>Transition Phase 3 - Enforcement</name>
<t>The goal of the "Transition Phase 3 - Enforcement" is to complete the <t>The goal of "Transition Phase 3 - Enforcement" is to complete the imp
implementation of the "Secure Authorization Information Model", by enforcing th lementation of the Secure Authorization Information Model, by enforcing the foll
e following:</t> owing:</t>
<dl newline="false" spacing="compact"> <dl newline="false" spacing="normal">
<dt>Disallow Authorization Information on Create Command:</dt> <dt>Disallow Authorization Information on &lt;Create&gt; Command:</dt>
<dd>Change the create command to not allow for the passing of a non-em <dd>Change the &lt;create&gt; command to not allow the passing of a no
pty authorization information value. n-empty authorization information value.
This behavior has the potential of breaking the client, so it's reco This behavior could potentially break the client, so it's recommende
mmended that the registry provide notice d that the registry provide notice
of the change.</dd> of this change.</dd>
<dt>Validate the Strong Random Authorization Information:</dt> <dt>Validate the Strong Random Authorization Information:</dt>
<dd>Change the validation of the authorization information in the upda te command to ensure at least 128 bits of entropy.</dd> <dd>Change the validation of the authorization information in the &lt; update&gt; command to ensure at least 128 bits of entropy.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="IANA-XML-Namespace" numbered="true" toc="default"> <section anchor="IANA-XML-Namespace" numbered="true" toc="default">
<name>XML Namespace</name> <name>XML Namespace</name>
<t> <t>
This document uses URNs to describe XML namespaces This document uses URNs to describe XML namespaces
conforming to a registry mechanism described in <xref target="RFC36 conforming to the registry mechanism described in <xref target="RFC
88" format="default"/>. 3688" format="default"/>. IANA has assigned the following URI in the "ns" subreg
The following URI assignment is requested of IANA: istry within the "IETF XML Registry" for secure authorization information for th
</t> e transfer namespace:</t>
<t>Registration request for the secure authorization information for tra
nsfer namespace:</t> <dl newline="false" spacing="compact">
<ul empty="true" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
<li>URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0</li> </dd>
<li>Registrant Contact: IESG</li> <dt>Registrant Contact:</dt><dd>IESG</dd>
<li>XML: None. Namespace URIs do not represent an XML specification.</ <dt>XML:</dt><dd>None. Namespace URIs do not represent an XML specificat
li> ion.</dd>
</ul> </dl>
</section> </section>
<section anchor="EPP-Extension-Registry" numbered="true" toc="default"> <section anchor="EPP-Extension-Registry" numbered="true" toc="default">
<name>EPP Extension Registry</name> <name>EPP Extension Registry</name>
<t> <t>
The EPP operational practice described in this document should be registered IANA has registered the EPP operational practice described in this doc
by ument in the "Extensions for the Extensible Provisioning Protocol (EPP)" registr
the IANA in the EPP Extension Registry described in <xref target="RFC7451" fo y as defined in <xref target="RFC7451" format="default"/>. The
rmat="default"/>. The
details of the registration are as follows: details of the registration are as follows:
</t> </t>
<t> <dl newline="false" spacing="compact">
Name of Extension: "Extensible Provisioning Protocol (EPP) Secure Authorizati <dt>Name of Extension:</dt><dd>"Extensible Provisioning Protocol (EPP) Secu
on Information for Transfer" re Authorization Information for Transfer"</dd>
</t> <dt>Document status:</dt><dd>Standards Track</dd>
<t> <dt>Reference:</dt><dd>RFC 9154</dd>
Document status: Standards Track <dt>Registrant Name and Email Address:</dt><dd>IESG (iesg@ietf.org)</dd>
</t> <dt>TLDs:</dt><dd>Any</dd>
<t> <dt>IPR Disclosure:</dt><dd>None</dd>
Reference: (insert reference to RFC version of this document) <dt>Status:</dt><dd>Active</dd>
</t> <dt>Notes:</dt><dd>None</dd>
<t> </dl>
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 publicat
ion.</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 impleme
ntation
and a full server stub implementation of draft-ietf-regext-secure-authin
fo-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 SL
Ds</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 regis
trars 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>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="secureRandomAuthInfo" format="default"/> defines the use <t><xref target="secureRandomAuthInfo" format="default"/> defines the use
a secure random value for the generation of the authorization information. of a secure random value for the generation of authorization information.
The client SHOULD choose a length and set of characters that results in at The client <bcp14>SHOULD</bcp14> choose a length and set of characters tha
least 128 bits of entropy.</t> t result in at least 128 bits of entropy.</t>
<t><xref target="authInfoTTL" format="default"/> defines the use of an aut <t><xref target="authInfoTTL" format="default"/> defines the use of an aut
horization information Time-To-Live (TTL). The registrar SHOULD only set the au horization information TTL. The registrar <bcp14>SHOULD</bcp14> only set the au
thorization information during the transfer process thorization information during the transfer process
by the server support for setting and unsetting the authorization informat by setting the authorization information at the start of the transfer proc
ion. The TTL value is up to registrar policy and the sponsoring registrar MUST ess and unsetting the authorization information at the end of the transfer proce
inform the registrant of the TTL ss.
The TTL value is left up to registrar policy, and the sponsoring registrar <bcp
14>MUST</bcp14> inform the registrant of the TTL
when providing the authorization information to the registrant.</t> when providing the authorization information to the registrant.</t>
<t><xref target="authInfoStorageTransport" format="default"/> defines the <t><xref target="authInfoStorageTransport" format="default"/> defines the
storage and transport of authorization information. The losing registrar MUST N storage and transport of authorization information. The losing registrar <bcp14
OT store the authorization information and the gaining >MUST NOT</bcp14> store the authorization information and the gaining
registrar MUST only store the authorization information as a "transient" v registrar <bcp14>MUST</bcp14> only store the authorization information as
alue during the transfer process, where the authorization information MUST NOT b a "transient" value during the transfer process, where the authorization informa
e stored after the end of the transfer process. tion <bcp14>MUST NOT</bcp14> be stored after the end of the transfer process.
The registry MUST store the authorization information using a one-way cryp The registry <bcp14>MUST</bcp14> store the authorization information using
tographic hash of at least 256 bits and with a per-authorization information ran a one-way cryptographic hash of at least 256 bits and with a per-authorization
dom salt, with at least 128 bits. information random salt with at least 128 bits.
All communication that includes the authorization information MUST be over All communication that includes the authorization information <bcp14>MUST<
an encrypted channel. The plain text /bcp14> be over an encrypted channel. The plain-text
authorization information MUST NOT be written to any logs by the registrar authorization information <bcp14>MUST NOT</bcp14> be written to any logs b
or the registry.</t> y the registrar or the registry.</t>
<t><xref target="authInfoMatching" format="default"/> defines the matching <t><xref target="authInfoMatching" format="default"/> defines the matching
of the authorization information values. The registry stores an unset authoriz of the authorization information values. The registry stores an unset authoriz
ation information as a NULL (undefined) value to ensure that ation information value as a NULL (undefined) value to ensure that
an empty input authorization information never matches it. The method use an empty input authorization information value never matches it. The meth
d to define a NULL (undefined) value is database specific.</t> od 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> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation librarie
s:
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.xm
l"?> 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 fi
les in the same
directory as the including file. You can also define the XML_LIBRARY enviro
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.4086.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.5730.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.5731.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.5733.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.5734.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.
RFC.8499.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <reference anchor='W3C.REC-xml-20081126'
rence.RFC.2119.xml"/> target='https://www.w3.org/TR/2008/REC-xml-20081126'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <front>
rence.RFC.3688.xml"/> <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <author initials='T.' surname='Bray' fullname='Tim Bray'>
rence.RFC.4086.xml"/> <organization />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe </author>
rence.RFC.5730.xml"/> <author initials='J.' surname='Paoli' fullname='Jean Paoli'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <organization />
rence.RFC.5731.xml"/> </author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg
rence.RFC.5733.xml"/> -McQueen'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <organization />
rence.RFC.5734.xml"/> </author>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <author initials='E.' surname='Maler' fullname='Eve Maler'>
rence.RFC.7942.xml"/> <organization />
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe </author>
rence.RFC.8174.xml"/> <author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <organization />
rence.RFC.8499.xml"/> </author>
<date month='November' year='2008' />
</front>
<refcontent>World Wide Web Consortium Recommendation REC-xml-20081126</refc
ontent>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7451.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.7451.xml"/>
<reference anchor='FIPS-180-4' <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> <front>
<title>Secure Hash Standard, NIST Federal Information Processing Sta ndards (FIPS) Publication 180-4</title> <title>Secure Hash Standard, NIST Federal Information Processing Sta ndards (FIPS) Publication 180-4</title>
<author> <author>
<organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization> <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>
</author> </author>
<date month='August' year='2015'/> <date month='August' year='2015'/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<reference anchor='FIPS-140-2' <reference anchor='FIPS-140-2'
target='https://csrc.nist.gov/publications/detail/fips/140/2/ final'> target='https://csrc.nist.gov/publications/detail/fips/140/2/ final'>
<front> <front>
<title>NIST Federal Information Processing Standards (FIPS) Publicat ion 140-2</title> <title>NIST Federal Information Processing Standards (FIPS) Publicat ion 140-2</title>
<author> <author>
<organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization> <organization>National Institute of Standards and Technology, U.S. Department of Commerce</organization>
</author> </author>
<date month='May' year='2001'/> <date month='May' year='2001'/>
</front> </front>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.140-2"/>
</reference> </reference>
</references> </references>
</references> </references>
<section numbered="true" toc="default"> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Change History</name> <name>Acknowledgements</name>
<section anchor="change-00-to-01" numbered="true" toc="default"> <t>The authors wish to thank the following persons for their feedback and
<name>Change from 00 to 01</name> suggestions:
<ol spacing="compact" type="1"> <contact fullname="Michael Bauland"/>,
<li>Filled in the "Implementation Status" section with the inclusion o <contact fullname="Martin Casanova"/>,
f the "Verisign EPP SDK" and "RegistryEngine EPP Service" implementations.</li> <contact fullname="Scott Hollenbeck"/>,
<li>Made small wording corrections based on private feedback.</li> <contact fullname="Benjamin Kaduk"/>,
<li>Added content to the "Acknowledgements" section.</li> <contact fullname="Jody Kolker"/>,
</ol> <contact fullname="Barry Leiba"/>,
</section> <contact fullname="Patrick Mevzek"/>,
<section anchor="change-01-to-02" numbered="true" toc="default"> <contact fullname="Matthew Pozun"/>,
<name>Change from 01 to 02</name> <contact fullname="Srikanth Veeramachaneni"/>,
<ol spacing="compact" type="1"> and <contact fullname="Ulrich Wisser"/>.
<li>Revised the language used for the storage of the authorization inf </t>
ormation 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 hel
d 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 ', wi
th
at least a 256-bit hash function, such as SHA-256'.</li>
<li>Add a Transition Considerations section to cover the transitio
n 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 pract
ice 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 th
ree types of actors' to cover the case with transfers that has two registrar act
ors (losing and gaining).</li>
<li>In section 3.1, change the equations equals to be approximatel
y equal by using '=~' instead of '=', where applicable.</li>
<li>In section 3.3, change 'MUST be over an encrypted channel, suc
h 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:disc
lose&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 authorizatio
n information explicitly in an [RFC5731] domain name update command.' to
'Example of adding the "clientTransferProhibited" status and uns
etting the authorization information explicitly in an [RFC5731] domain name upda
te command.'</li>
<li>In section 4.3, cover a corner case of the ability to return t
he authorization information when it's passed in the info command.</li>
<li>In section 4.4, change 'If the transfer does not complete with
in 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 info
rmation and when it's successfully used in a transfer request. Added the case o
f 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 clar
ify how the authorization information is matched, when there is set and unset au
thorization 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 auth
orization information
element in the response to indicate that the authorization info
rmation 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 consist
ent 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-rege
xt-secure-authinfo-transfer to draft-ietf-regext-secure-authinfo-transfer.</li>
</ol>
</section>
<section anchor="change-WG00-to-WG01" numbered="true" 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 describ
e the mechanism to signal support for the BCP by the client and the server.</li>
<li>Added the "IANA Considerations" section with the registration of t
he secure authorization for transfer
XML namespace and the registration of the EPP Best Current Practice
(BCP) in 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 for the hashed authorization inform
ation, 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 feedback from Patrick Mevze
k.</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-aut
hinfo-transfer-1.0, which removed bcp from the namespace and bumped the version
from 0.1 and 1.0.
Inclusion of bcp in the XML namespace was discussed at the REGEXT inte
rim meeting.</li>
<li>Replaced Auhtorization with Authorization based on a review by Jod
y 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 Ed
itor 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 Refer
ences 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:
</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 p
aragraph 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 infor
mation 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 a
t least 128 bits of entropy.</li>
<li>Added an informative reference to FIPS 180-4 for the SHA-256 refer
ences.</li>
<li>Normalized the way that the "empty and non-empty authorization inf
ormation values" are referenced, which a few exceptions.</li>
<li>In section 4, revised the first sentence to explicitly reference t
he use of the &lt;domain:pw&gt; and &lt;contact:pw&gt; elements for password-bas
ed authorization information.</li>
<li>In section 4.4, revised the language associated with the storage o
f the authorization information to be cleaner.</li>
<li>In section 4.4, added "set" in the sentence "An empty input author
ization 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 RF
C5733 as examples of object extensions that use the "eppcom:pwAuthInfoType" elem
ent.</li>
<li>In section 5.2, updated language for the validation of the randomn
ess 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 practi
ce will require the client to not store the authorization information and".</li>
<li>Updated each of the example references to end with a colon ins
tead of a period.</li>
<li>Updated Section 1, Paragraph 3 to read "provide secure authori
zation 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 informat
ion to be secure, it must".</li>
<li>Updated Section 4.2, Paragraph 2 to read "authorization inform
ation by the sponsoring registrar, the".</li>
<li>Updated Section 4.2, Paragraph 2 to read "proprietary registra
r-specific criteria, which".</li>
<li>Updated Section 4.3, Paragraph 3 to read "256-bit hash functio
n, such as SHA-256".</li>
<li>Updated Section 4.3, Paragraph 3 to read "a NULL (undefined) v
alue".</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 t
he transfer process by unsetting the authorization information value and MAY add
back statuses".</li>
<li>Updated Section 5.2, Paragraph 9 to read ""eppcom:pwAuthInfoTy
pe" 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 t
ransfers.</li>
<li>Removed the duplicate first paragraph of section 5.2 based on feed
back 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 feature
s 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 Informat
ion" in Section 1 to reference section 2.6 of RFC5731 and change in nature of th
e authorization information.</li>
<li>Updated Section 4.1, Paragraph 1 and 2 were merged with modifi
ed 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 sent
ence for what is meant by input authorization information.</li>
<li>Updated Section 4.1 by replacing the last paragraph "The stren
gth of the random..." with a revised version.</li>
<li>Updated "retrieves the stored authorization information locall
y" with "retrieves the locally stored authorization information".</li>
<li>Updated Section 6.1 to include the recommendation that the reg
istry provide notice of the Info Response change.</li>
<li>Updated Section 6.2 to include the sentence "This requires tha
t the stored values are self-identifying as being in hashed or encrypted form"
for the "Supporting Comparing Against Encrypted and Hashed Autho
rization Information" step.</li>
<li>Updated Section 6.3 to include the recommendation that the reg
istry 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 losin
g and the gaining registrar.</li>
<li>Updated references to "with a random salt" to "with a per-auth
orization 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 referen
ce 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 ge
nerator (RNG) is preferable over the use of a pseudorandom number generator (PRN
G) when creating the authorization information value."</li>
<li>Changed FIPS-140-2 from a normative reference to an informativ
e reference.</li>
</ol>
</li>
</ol>
</section>
</section> </section>
</back> </back>
<!-- vim: set ts=2 sw=2 expandtab: -->
</rfc> </rfc>
 End of changes. 122 change blocks. 
1008 lines changed or deleted 662 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/