rfc9154.original   rfc9154.txt 
Network Working Group J. Gould Internet Engineering Task Force (IETF) J. Gould
Internet-Draft R. Wilhelm Request for Comments: 9154 R. Wilhelm
Intended status: Standards Track VeriSign, Inc. Category: Standards Track Verisign, Inc.
Expires: 30 December 2021 28 June 2021 ISSN: 2070-1721 December 2021
Extensible Provisioning Protocol (EPP) Secure Authorization Information Extensible Provisioning Protocol (EPP) Secure Authorization Information
for Transfer for Transfer
draft-ietf-regext-secure-authinfo-transfer-07
Abstract Abstract
The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use
use of authorization information to authorize a transfer of an EPP of authorization information to authorize a transfer of an EPP
object, such as a domain name, between clients that are referred to object, such as a domain name, between clients that are referred to
as registrars. Object-specific, password-based authorization as "registrars". Object-specific, password-based authorization
information (see RFC 5731 and RFC 5733) is commonly used, but raises information (see RFCs 5731 and 5733) is commonly used but raises
issues related to the security, complexity, storage, and lifetime of issues related to the security, complexity, storage, and lifetime of
authentication information. This document defines an operational authentication information. This document defines an operational
practice, using the EPP RFCs, that leverages the use of strong random practice, using the EPP RFCs, that leverages the use of strong random
authorization information values that are short-lived, not stored by authorization information values that are short lived, not stored by
the client, and stored by the server using a cryptographic hash that the client, and stored by the server using a cryptographic hash that
provides for secure authorization information that can safely be used provides for secure authorization information that can safely be used
for object transfers. for object transfers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 30 December 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9154.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document
2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 2. Registrant, Registrar, Registry
3. Signaling Client and Server Support . . . . . . . . . . . . . 6 3. Signaling Client and Server Support
4. Secure Authorization Information . . . . . . . . . . . . . . 7 4. Secure Authorization Information
4.1. Secure Random Authorization Information . . . . . . . . . 7 4.1. Secure Random Authorization Information
4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 4.2. Authorization Information Time To Live (TTL)
4.3. Authorization Information Storage and Transport . . . . . 8 4.3. Authorization Information Storage and Transport
4.4. Authorization Information Matching . . . . . . . . . . . 9 4.4. Authorization Information Matching
5. Create, Transfer, and Secure Authorization Information . . . 10 5. Create, Transfer, and Secure Authorization Information
5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 5.1. <Create> Command
5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 5.2. <Update> Command
5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 5.3. <Info> Command and Response
5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17 5.4. <Transfer> Request Command
6. Transition Considerations . . . . . . . . . . . . . . . . . . 18 6. Transition Considerations
6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 20 6.1. Transition Phase 1 - Features
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 21 6.2. Transition Phase 2 - Storage
6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 6.3. Transition Phase 3 - Enforcement
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 7.1. XML Namespace
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 22 7.2. EPP Extension Registry
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23 9. References
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 9.1. Normative References
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgements
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28
A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28
A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28
A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28
A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 28
A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29
A.11. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the The Extensible Provisioning Protocol (EPP) [RFC5730] defines the use
use of authorization information to authorize a transfer of an EPP of authorization information to authorize a transfer of an EPP
object, such as a domain name, between clients that are referred to object, such as a domain name, between clients that are referred to
as registrars. The authorization information is object-specific and as "registrars". The authorization information is object specific
has been defined in the EPP Domain Name Mapping, in [RFC5731], and and has been defined in "Extensible Provisioning Protocol (EPP)
the EPP Contact Mapping, in [RFC5733], as password-based Domain Name Mapping" [RFC5731] and "Extensible Provisioning Protocol
authorization information. Other authorization mechanisms can be (EPP) Contact Mapping" [RFC5733] as password-based authorization
used, but in practice the password-based authorization information information. Other authorization mechanisms can be used, but in
has been used at the time of object create, managed with the object practice the password-based authorization information has been used
update, and used to authorize an object transfer request. What has at the time of object creation, managed with the object update, and
not been considered is the security of the authorization information used to authorize an object transfer request. What has not been
that includes the complexity of the authorization information, the considered is the security of the authorization information, which
time-to-live (TTL) of the authorization information, and where and includes the complexity of the authorization information, the Time To
how the authorization information is stored. Live (TTL) of the authorization information, and where and how the
authorization information is stored.
The current/original lifecycle for authorization information involves The current/original lifecycle for authorization information involves
long-term storage of encrypted (not hashed) passwords, which presents long-term storage of encrypted (not hashed) passwords, which presents
a significant latent risk of password compromise and is not a significant latent risk of password compromise and is not
consistent with current best practices. The mechanisms in this consistent with current best practices. The mechanisms in this
document provide a way to avoid long-term password storage entirely, document provide a way to avoid long-term password storage entirely
and to only require the storage of hashed (not retrievable) passwords and to only require the storage of hashed (not retrievable) passwords
instead of encrypted passwords. instead of encrypted passwords.
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, that are not stored by the client, and values that are short lived, not stored by the client, and stored by
that are stored by the server using a cryptographic hash to provide the server using a cryptographic hash to provide secure authorization
secure authorization information used for transfers. This information used for transfers. This operational practice can be
operational practice can be used to support transfers of any EPP used to support transfers of any EPP object, where the domain name
object, where the domain name object defined in [RFC5731] is used in object as defined in [RFC5731] is used in this document for
this document for illustration purposes. Elements of the practice illustration purposes. Elements of the practice may be used to
may be used to support the secure use of the authorization support the secure use of the authorization information for purposes
information for purposes other than transfer, but any other purposes other than transfer, but any other purposes and the applicable
and the applicable elements are out-of-scope for this document. elements are out of scope for this document.
The overall goal is to have strong, random authorization information The overall goal is to have strong, random authorization information
values, that are short-lived, and that are either not stored or values that are short lived and are either not stored or stored as
stored as a cryptographic hash values by the non-responsible parties. cryptographic hash values by the non-responsible parties. In a
In a registrant, registrar, and registry model, the registrant registrant, registrar, and registry model, the registrant registers
registers the object through the registrar to the registry. The the object through the registrar to the registry. The registrant is
registrant is the responsible party and the registrar and the the responsible party, and the registrar and the registry are the
registry are the non-responsible parties. EPP is a protocol between non-responsible parties. EPP is a protocol between the registrar and
the registrar and the registry, where the registrar is referred to as the registry, where the registrar is referred to as the "client" and
the client and the registry is referred to as the server. The the registry is referred to as the "server". The following are the
following are the elements of the operational practice and how the elements of the operational practice and how the existing features of
existing features of the EPP RFCs can be leveraged to satisfy them: the EPP RFCs can be leveraged to satisfy them:
"Strong Random Authorization Information": The EPP RFCs define the Strong Random Authorization Information: The EPP RFCs define the
password-based authorization information value using an XML password-based authorization information value using an XML
schema "normalizedString" type, so they don't restrict what can schema "normalizedString" type, so they don't restrict what can
be used in any substantial way. This operational practice be used in any substantial way. This operational practice
defines the recommended mechanism for creating a strong random defines the recommended mechanism for creating a strong random
authorization value, that would be generated by the client. authorization value that would be generated by the client.
"Short-Lived Authorization Information": The EPP RFCs don't
explicitly support short-lived authorization information or a Short-Lived Authorization Information: The EPP RFCs don't explicitly
time-to-live (TTL) for authorization information, but there are support short-lived authorization information or a TTL for
EPP RFC features that can be leveraged to support short-lived authorization information, but there are EPP RFC features that
authorization information. All of these features are compatible can be leveraged to support short-lived authorization
with the EPP RFCs, though not mandatory to implement. In section information. All of these features are compatible with the EPP
2.6 of [RFC5731] it states that authorization information is RFCs, though not mandatory to implement. As stated in
assigned when a domain object is created, which results in long- Section 2.6 of [RFC5731], authorization information is assigned
lived authorization information. This specification changes the when a domain object is created, which results in long-lived
nature of the authorization information to be short-lived. If authorization information. This specification changes the nature
authorization information is set only when there is a transfer in of the authorization information from long lived to short lived.
If authorization information is set only when a transfer is in
process, the server needs to support an empty authorization process, the server needs to support an empty authorization
information value on create, support setting and unsetting information value on create, support setting and unsetting
authorization information, and support automatically unsetting authorization information, and support automatically unsetting
the authorization information upon a successful transfer. All of the authorization information upon a successful transfer. All of
these features can be supported by the EPP RFCs. these features can be supported by the EPP RFCs.
"Storing Authorization Information Securely": The EPP RFCs don't
Storing Authorization Information Securely: The EPP RFCs don't
specify where and how the authorization information is stored in specify where and how the authorization information is stored in
the client or the server, so there are no restrictions to define the client or the server, so there are no restrictions on
an operational practice for storing the authorization information defining an operational practice for storing the authorization
securely. The operational practice will require the client to information securely. The operational practice will require the
not store the authorization information and will require the client to not store the authorization information and will
server to store the authorization information using a require the server to store the authorization information using a
cryptographic hash, with at least a 256-bit hash function, such cryptographic hash with at least a 256-bit hash function, such as
as SHA-256 [FIPS-180-4], and with a per-authorization information SHA-256 [FIPS-180-4], and with a per-authorization information
random salt, with at least 128 bits. Returning the authorization random salt with at least 128 bits. Returning the authorization
information set in an EPP info response will not be supported. information set in an EPP info response will not be supported.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
XML is case sensitive. Unless stated otherwise, XML specifications XML [W3C.REC-xml-20081126] is case sensitive. Unless stated
and examples provided in this document MUST be interpreted in the otherwise, XML specifications and examples provided in this document
character case presented in order to develop a conforming MUST be interpreted in the character case presented in order to
implementation. develop a conforming implementation.
In examples, "C:" represents lines sent by a protocol client and "S:" In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and represents lines returned by a protocol server. Indentation and
white space in examples are provided only to illustrate element empty space in examples are provided only to illustrate element
relationships and are not a required feature of this protocol. relationships and are not a required feature of this protocol.
The examples reference XML namespace prefixes that are used for the The examples reference XML namespace prefixes that are used for the
associated XML namespaces. Implementations MUST NOT depend on the associated XML namespaces. Implementations MUST NOT depend on the
example XML namespaces and instead employ a proper namespace-aware example XML namespaces and instead employ a proper namespace-aware
XML parser and serializer to interpret and output the XML documents. XML parser and serializer to interpret and output the XML documents.
The example namespace prefixes used and their associated XML The example namespace prefixes used and their associated XML
namespaces include: namespaces include the following:
"domain": urn:ietf:params:xml:ns:domain-1.0 domain: urn:ietf:params:xml:ns:domain-1.0
"contact": urn:ietf:params:xml:ns:contact-1.0
contact: urn:ietf:params:xml:ns:contact-1.0
2. Registrant, Registrar, Registry 2. Registrant, Registrar, Registry
The EPP RFCs refer to client and server, but when it comes to The EPP RFCs refer to "client" and "server", but when it comes to
transfers, there are three types of actors that are involved. This transfers, there are three types of actors that are involved. This
document will refer to the actors as registrant, registrar, and document will refer to these actors as "registrant", "registrar", and
registry. [RFC8499] defines these terms formally for the Domain Name "registry". [RFC8499] defines these terms formally for the Domain
System (DNS). The terms are further described below to cover their Name System (DNS). The terms are further described below to cover
roles as actors of using the authorization information in the their roles as actors using the authorization information in the
transfer process of any object in the registry, such as a domain name transfer process of any object in the registry, such as a domain name
or a contact: or a contact:
"registrant": [RFC8499] defines the registrant as "an individual or Registrant: [RFC8499] defines the registrant as "an individual or
organization on whose behalf a name in a zone is registered by organization on whose behalf a name in a zone is registered by
the registry". The registrant can be the owner of any object in the registry." The registrant can be the owner of any object in
the registry, such as a domain name or a contact. The registrant the registry, such as a domain name or a contact. The registrant
interfaces with the registrar for provisioning the objects. A interfaces with the registrar for provisioning the objects. A
transfer is coordinated by the registrant to transfer the transfer is coordinated by the registrant to transfer the
sponsorship of the object from one registrar to another. The sponsorship of the object from one registrar to another. The
authorization information is meant to authenticate the registrant authorization information is meant to authenticate the registrant
as the owner of the object to the non-sponsoring registrar and to as the owner of the object to the non-sponsoring registrar and to
authorize the transfer. authorize the transfer.
"registrar": [RFC8499] defines the registrar as "a service provider
that acts as a go-between for registrants and registries". The Registrar: [RFC8499] defines the registrar as "a service provider
that acts as a go-between for registrants and registries." The
registrar interfaces with the registrant for the provisioning of 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 registries to satisfy the registrant's provisioning requests. A
registrar may directly interface with the registrant or may registrar may (1) directly interface with the registrant or
indirectly interface with the registrant, typically through one (2) indirectly interface with the registrant, typically through
or more resellers. Implementing a transfer using secure one or more resellers. Implementing a transfer using secure
authorization information extends through the registrar's authorization information extends through the registrar's
reseller channel up to the direct interface with the registrant. reseller channel up to the direct interface with the registrant.
The registrar's interface with the registries uses EPP. The The registrar's interface with the registries uses EPP. The
registrar's interface with its reseller channel or the registrant registrar's interface with its reseller channel or the registrant
is registrar-specific. In the EPP RFCs, the registrar is is registrar specific. In the EPP RFCs, the registrar is
referred to as the "client", since EPP is the protocol used referred to as the "client", since EPP is the protocol used
between the registrar and the registry. The sponsoring registrar between the registrar and the registry. The sponsoring registrar
is the authorized registrar to manage objects on behalf of the is the authorized registrar to manage objects on behalf of the
registrant. A non-sponsoring registrar is not authorized to registrant. A non-sponsoring registrar is not authorized to
manage objects on behalf of the registrant. A transfer of an manage objects on behalf of the registrant. A transfer of an
object's sponsorship is from one registrar, referred to as the object's sponsorship is from one registrar, referred to as the
losing registrar, to another registrar, referred to as the "losing registrar", to another registrar, referred to as the
gaining registrar. "gaining registrar".
"registry": [RFC8499] defines the registry as "the administrative
operation of a zone that allows registration of names within the Registry: [RFC8499] defines the registry as "the administrative
zone". The registry typically interfaces with the registrars operation of a zone that allows registration of names within that
zone." The registry typically interfaces with the registrars
over EPP and generally does not interact directly with the over EPP and generally does not interact directly with the
registrant. In the EPP RFCs, the registry is referred to as the registrant. In the EPP RFCs, the registry is referred to as the
"server", since EPP is the protocol used between the registrar "server", since EPP is the protocol used between the registrar
and the registry. The registry has a record of the sponsoring and the registry. The registry has a record of the sponsoring
registrar for each object and provides the mechanism (over EPP) registrar for each object and provides the mechanism (over EPP)
to coordinate a transfer of an object's sponsorship between to coordinate a transfer of an object's sponsorship between
registrars. registrars.
3. Signaling Client and Server Support 3. Signaling Client and Server Support
This document does not define new protocol but an operational This document does not define a new protocol; rather, it defines an
practice using the existing EPP protocol, where the client and the operational practice using existing EPP features, where the client
server can signal support for the operational practice using a and the server can signal support for the operational practice using
namespace URI in the login and greeting extension services. The a namespace URI in the login and greeting extension services. The
namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer- namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-
1.0" is used to signal support for the operational practice. The 1.0" is used to signal support for the operational practice. The
client includes the namespace URI in an <svcExtension> <extURI> client includes the namespace URI in an <svcExtension> <extURI>
element of the [RFC5730] <login> Command. The server includes the element of the <login> command [RFC5730]. The server includes the
namespace URI in an <svcExtension> <extURI> element of the [RFC5730] namespace URI in an <svcExtension> <extURI> element of the greeting
Greeting. [RFC5730].
A client that receives the namespace URI in the server's Greeting A client that receives the namespace URI in the server's greeting
extension services can expect the following supported behavior by the extension services can expect the following supported behavior by the
server: server:
1. Support an empty authorization information value with a create 1. Support for an empty authorization information value with a
command. <create> command.
2. Support unsetting authorization information with an update
2. Support for unsetting authorization information with an <update>
command. command.
3. Support validating authorization information with an info
3. Support for validating authorization information with an <info>
command. command.
4. Support not returning an indication whether the authorization 4. Support for not returning an indication of whether the
information is set or unset to the non-sponsoring registrar. authorization information is set or unset to the non-sponsoring
5. Support returning an empty authorization information value to the registrar.
sponsoring registrar when the authorization information is set in
an info response. 5. Support for returning an empty authorization information value to
6. Support allowing for the passing of a matching non-empty the sponsoring registrar when the authorization information is
set in an info response.
6. Support for allowing the passing of a matching non-empty
authorization information value to authorize a transfer. authorization information value to authorize a transfer.
7. Support automatically unsetting the authorization information
upon a successful completion of transfer. 7. Support for automatically unsetting the authorization information
upon successful completion of a transfer.
A server that receives the namespace URI in the client's <login> A server that receives the namespace URI in the client's <login>
Command extension services, can expect the following supported command extension services can expect the following supported
behavior by the client: behavior by the client:
1. Support generation of authorization information using a secure 1. Support for the generation of authorization information using a
random value. secure random value.
2. Support only setting the authorization information when there is
a transfer in process. 2. Support for only setting the authorization information when a
transfer is in process.
4. Secure Authorization Information 4. Secure Authorization Information
The authorization information in the EPP RFCs ([RFC5731] and The EPP RFCs ([RFC5731] and [RFC5733]) use password-based
[RFC5733]) that support transfer use password-based authorization authorization information to support transfer with the <domain:pw>
information ([RFC5731] with the <domain:pw> element and [RFC5733] element [RFC5731] and with the <contact:pw> element [RFC5733]. Other
with the <contact:pw> element). Other EPP objects that support EPP objects that support password-based authorization information for
password-based authorization information for transfer can use the transfer can use secure authorization information as defined in this
Secure Authorization Information defined in this document. For the document. For authorization information to be secure, it must be
authorization information to be secure, it must be generated using a generated using a strong random value and have a short TTL. The
strong random value and have a short time-to-live (TTL). The
security of the authorization information is defined in the following security of the authorization information is defined in the following
sections. sections.
4.1. Secure Random Authorization Information 4.1. Secure Random Authorization Information
For authorization information to be secure, it MUST be generated For authorization information to be secure, it MUST be generated
using a secure random value. The authorization information is using a secure random value. The authorization information is
treated as a password, and the required length L of a password, treated as a password, and the required length L of a password,
rounded up to the largest whole number, is based on the size N of the rounded up to the largest whole number, is based on the size N of the
set of characters and the desired entropy H, in the equation L = set of characters and the desired entropy H, in the equation L =
ROUNDUP(H / log2 N). Given a target entropy, the required length can ROUNDUP(H / log_2 N). Given a target entropy, the required length
be calculated after deciding on the set of characters that will be can be calculated after deciding on the set of characters that will
randomized. In accordance with current best practices and noting be randomized. In accordance with current best practices and noting
that the authorization information is a machine-generated value, the that the authorization information is a machine-generated value, the
implementation SHOULD use at least 128 bits of entropy as the value implementation SHOULD use at least 128 bits of entropy as the value
of H. The lengths below are calculated using that value. of H. The lengths below are calculated using that value.
Calculation of the required length with 128 bits of entropy and with Calculation of the required length with 128 bits of entropy and with
the set of all printable ASCII characters except space (0x20), which the set of all printable ASCII characters except space (0x20), which
consists of the 94 characters 0x21-0x7E. consists of the 94 characters 0x21-0x7E:
ROUNDUP(128 / log2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20
Calculation of the required length with 128 bits of entropy and with Calculation of the required length with 128 bits of entropy and with
the set of case insensitive alphanumeric characters, which consists the set of case-insensitive alphanumeric characters, which consists
of 36 characters (a-z A-Z 0-9). of 36 characters (a-z A-Z 0-9):
ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 ROUNDUP(128 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
The strength of the random authorization information is dependent on The strength of the random authorization information is dependent on
the random number generator. Suitably strong random number the random number generator. Suitably strong random number
generators are available in a wide variety of implementation generators are available in a wide variety of implementation
environments, including the interfaces listed in Sections 7.1.2 and environments, including the interfaces listed in Sections 7.1.2 and
7.1.3 of [RFC4086]. In environments that do not provide interfaces 7.1.3 of [RFC4086]. In environments that do not provide interfaces
to strong random number generators, the practices defined in to strong random number generators, the practices defined in
[RFC4086] and section 4.7.1 of the NIST Federal Information [RFC4086] and Section 4.7.1 of the NIST Federal Information
Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be
followed to produce random values that will be resistant to attack. followed to produce random values that will be resistant to attack.
(Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3
does not contain information regarding random number generators.)
4.2. Authorization Information Time-To-Live (TTL) 4.2. Authorization Information Time To Live (TTL)
The authorization information SHOULD only be set when there is a The authorization information SHOULD only be set when a transfer is
transfer in process. This implies that the authorization information in process. This implies that the authorization information has a
has a Time-To-Live (TTL) by which the authorization information is TTL by which the authorization information is cleared when the TTL
cleared when the TTL expires. The EPP RFCs have no definition of expires. The EPP RFCs do not provide definitions for TTL, but since
TTL, but since the server supports the setting and unsetting of the the server supports the setting and unsetting of the authorization
authorization information by the sponsoring registrar, the sponsoring information by the sponsoring registrar, the sponsoring registrar can
registrar can apply a TTL based on client policy. The TTL client apply a TTL based on client policy. The TTL client policy may be
policy may be based on proprietary registrar-specific criteria, which based on proprietary registrar-specific criteria, which provides for
provides for a transfer-specific TTL tuned for the particular a transfer-specific TTL tuned for the particular circumstances of the
circumstances of the transaction. The sponsoring registrar will be transaction. The sponsoring registrar will be aware of the TTL, and
aware of the TTL and the sponsoring registrar MUST inform the the sponsoring registrar MUST inform the registrant of the TTL when
registrant of the TTL when the authorization information is provided the authorization information is provided to the registrant.
to the registrant.
4.3. Authorization Information Storage and Transport 4.3. Authorization Information Storage and Transport
To protect the disclosure of the authorization information, the To protect the disclosure of the authorization information, the
following requirements apply: following requirements apply:
1. The authorization information MUST be stored by the registry 1. The authorization information MUST be stored by the registry
using a strong one-way cryptographic hash, with at least a using a strong one-way cryptographic hash with at least a 256-bit
256-bit hash function, such as SHA-256 [FIPS-180-4], and with a hash function, such as SHA-256 [FIPS-180-4], and with a per-
per-authorization information random salt, with at least 128 authorization information random salt with at least 128 bits.
bits.
2. An empty authorization information value MUST be stored as an
undefined value that is referred to as a "NULL" value. The
representation of a NULL (undefined) value is dependent on the
type of database used.
2. Empty authorization information MUST be stored as an undefined
value that is referred to as a NULL value. The representation of
a NULL (undefined) value is dependent on the type of database
used.
3. The authorization information MUST NOT be stored by the losing 3. The authorization information MUST NOT be stored by the losing
registrar. registrar.
4. The authorization information MUST only be stored by the gaining 4. The authorization information MUST only be stored by the gaining
registrar as a "transient" value in support of the transfer registrar as a "transient" value in support of the transfer
process. process.
5. The plain text version of the authorization information MUST NOT
5. The plain-text version of the authorization information MUST NOT
be written to any logs by a registrar or the registry, nor be written to any logs by a registrar or the registry, nor
otherwise recorded where it will persist beyond the transfer otherwise recorded where it will persist beyond the transfer
process. process.
6. All communication that includes the authorization information 6. All communication that includes the authorization information
MUST be over an encrypted channel, such as defined in [RFC5734] MUST be over an encrypted channel (for example, see [RFC5734])
for EPP. for EPP.
7. The registrar's interface for communicating the authorization 7. The registrar's interface for communicating the authorization
information with the registrant MUST be over an authenticated and information with the registrant MUST be over an authenticated and
encrypted channel. encrypted channel.
4.4. Authorization Information Matching 4.4. Authorization Information Matching
To support the authorization information TTL, as defined in To support the authorization information TTL, as described in
Section 4.2, the authorization information must have either a set or Section 4.2, the authorization information must have either a set or
unset state. Authorization information that is unset is stored with unset state. Authorization information that is unset is stored with
a NULL (undefined) value. Based on the requirement to store the 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 Section 4.3, authorization information that is set is as described in Section 4.3, authorization information that is set is
stored with a non-NULL hashed value. The empty authorization stored with a non-NULL hashed value. The empty authorization
information is used as input in both the create command (Section 5.1) information value is used as input in both the <create> command
and the update command (Section 5.2) to define the unset state. The (Section 5.1) and the <update> command (Section 5.2) to define the
matching of the authorization information in the info command unset state. The matching of the authorization information in the
(Section 5.3) and the transfer request command (Section 5.4) is based <info> command (Section 5.3) and the <transfer> request command
on the following rules: (Section 5.4) is based on the following rules:
1. Any input authorization information value MUST NOT match an unset 1. Any input authorization information value MUST NOT match an unset
authorization information value. This includes empty authorization information value. For example, in [RFC5731] the
authorization information, such as <domain:null/> or <domain:pw/> input <domain:pw>2fooBAR</domain:pw> must not match an unset
in [RFC5731], and non-empty authorization information, such as authorization information value that used <domain:null/> or
<domain:pw>2fooBAR</domain:pw> in [RFC5731]. <domain:pw/>.
2. An empty input authorization information value MUST NOT match any 2. An empty input authorization information value MUST NOT match any
set authorization information value. set authorization information value.
3. A non-empty input authorization information value MUST be hashed 3. A non-empty input authorization information value MUST be hashed
and matched against the set authorization information value, and matched against the set authorization information value,
which is stored using the same hash algorithm. which is stored using the same hash algorithm.
5. Create, Transfer, and Secure Authorization Information 5. Create, Transfer, and Secure Authorization Information
To secure the transfer process using secure authorization To secure the transfer process using secure authorization information
information, as defined in Section 4, the client and server need to as described in Section 4, the client and server need to implement
implement steps where the authorization information is set only when steps where the authorization information is set only when a transfer
a transfer is actively in process and ensure that the authorization is actively in process and ensure that the authorization information
information is stored securely and transported only over secure is stored securely and transported only over secure channels. The
channels. The steps in management of the authorization information steps for management of the authorization information for transfers
for transfers include: include the following:
1. Registrant requests to register the object with the registrar. 1. The registrant requests to register the object with the
Registrar sends the create command, with an empty authorization registrar. The registrar sends the <create> command with an
information value, to the registry, as defined in Section 5.1. empty authorization information value to the registry, as
2. Registrant requests from the losing registrar the authorization described in Section 5.1.
information to provide to the gaining registrar.
3. Losing registrar generates a secure random authorization 2. The registrant requests from the losing registrar the
information value, sends it to the registry as defined in authorization information to provide to the gaining registrar.
Section 5.2, and provides it to the registrant.
4. Registrant provides the authorization information value to the 3. The losing registrar generates a secure random authorization
gaining registrar. information value and sends it to the registry, as described in
5. Gaining registrar optionally verifies the authorization Section 5.2, and then provides it to the registrant.
information with the info command to the registry, as defined in
Section 5.3. 4. The registrant provides the authorization information value to
6. Gaining registrar sends the transfer request with the the gaining registrar.
authorization information to the registry, as defined in
5. The gaining registrar optionally verifies the authorization
information with the <info> command to the registry, as described
in Section 5.3.
6. The gaining registrar sends the transfer request with the
authorization information to the registry, as described in
Section 5.4. Section 5.4.
7. If the transfer successfully completes, the registry
automatically unsets the authorization information; otherwise the 7. If the transfer completes successfully, the registry
losing registrar unsets the authorization information when the automatically unsets the authorization information; otherwise,
TTL expires, as defined in Section 5.2. the losing registrar unsets the authorization information when
the TTL expires; see Section 5.2.
The following sections outline the practices of the EPP commands and The following sections outline the practices of the EPP commands and
responses between the registrar and the registry that supports secure responses between the registrar and the registry that supports secure
authorization information for transfer. authorization information for transfer.
5.1. Create Command 5.1. <Create> Command
For a create command, the registry MUST allow for the passing of an For a <create> command, the registry MUST allow the passing of an
empty authorization information value and MAY disallow for the empty authorization information value and MAY disallow the passing of
passing of a non-empty authorization information value. By having an a non-empty authorization information value. By having an empty
empty authorization information value on create, the object is authorization information value on create, the object is initially
initially not in the transfer process. Any EPP object extension that not involved in the transfer process. Any EPP object extension that
supports setting the authorization information with a supports setting the authorization information with an
"eppcom:pwAuthInfoType" element can have an empty authorization "eppcom:pwAuthInfoType" element can pass an empty authorization
information value passed. Examples of such extensions are [RFC5731] information value. Examples of such extensions are found in
and [RFC5733]. [RFC5731] and [RFC5733].
Example of passing an empty authorization information value in an Example of passing an empty authorization information value in a
[RFC5731] domain name create command: domain name <create> command [RFC5731]:
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>
Example of passing an empty authorization information value in an Example of passing an empty authorization information value in a
[RFC5733] contact create command: contact <create> command [RFC5733]:
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>
skipping to change at page 12, line 5 skipping to change at line 532
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>
5.2. Update Command 5.2. <Update> Command
For an update command, the registry MUST allow for the setting and For an <update> command, the registry MUST 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 Section 4.1, and setting it authorization information value, based on the information provided in
in the registry in the update command. The importance of generating Section 4.1, and setting it in the registry in the <update> command.
strong authorization information values cannot be overstated: secure The importance of generating strong authorization information values
transfers are very important to the Internet to mitigate damage in cannot be overstated: secure transfers are very important to the
the form of theft, fraud, and other abuse. It is critical that Internet to mitigate damage in the form of theft, fraud, and other
registrars only use strong, randomly generated authorization abuse. It is critical that registrars only use strong, randomly
information values. generated authorization information values.
Because of this, registries may validate the randomness of the Because of this, registries may validate the randomness of the
authorization information based on the length and character set authorization information based on the length and character set
required by the registry. For example, validating an authorization required by the registry -- for example, validating that an
value contains a combination of upper-case, lower-case, and non- authorization value contains a combination of uppercase, lowercase,
alphanumeric characters, in an attempt to assess the strength of the and non-alphanumeric characters in an attempt to assess the strength
value, and return an EPP error result of 2202 if the check fails. of the value and returning an EPP error result of 2202 ("Invalid
authorization information") [RFC5730] if the check fails.
Such checks are, by their nature, heuristic and imperfect, and may Such checks are, by their nature, heuristic and imperfect, and may
identify well-chosen authorization information values as being not identify well-chosen authorization information values as being not
sufficiently strong. Registrars, therefore, must be prepared for an sufficiently strong. Registrars, therefore, must be prepared for an
error response of 2202, "Invalid authorization information", and error response of 2202 and respond by generating a new value and
respond by generating a new value and trying again, possibly more trying again, possibly more than once.
than once.
Often, the registrar has the "clientTransferProhibited" status set, Often, the registrar has the "clientTransferProhibited" status set,
so to start the transfer process, the "clientTransferProhibited" so to start the transfer process, the "clientTransferProhibited"
status needs to be removed, and the strong, random authorization status needs to be removed, and the strong, random authorization
information value needs to be set. The registrar MUST define a time- information value needs to be set. The registrar MUST define a TTL,
to-live (TTL), as defined in Section 4.2, where if the TTL expires as described in Section 4.2, and if the TTL expires, the registrar
the registrar will unset the authorization information. will unset the authorization information.
Example of removing the "clientTransferProhibited" status and setting Example of removing the "clientTransferProhibited" status and setting
the authorization information in an [RFC5731] domain name update the authorization information in a domain name <update> command
command: [RFC5731]:
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"/>
skipping to change at page 13, line 30 skipping to change at line 595
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>
When the registrar-defined TTL expires, the sponsoring registrar MUST When the registrar-defined TTL expires, the sponsoring registrar MUST
cancel the transfer process by unsetting the authorization cancel the transfer process by unsetting the authorization
information value and MAY add back statuses like the information value and MAY add back statuses like the
"clientTransferProbited" status. Any EPP object extension that "clientTransferProhibited" status. Any EPP object extension that
supports setting the authorization information with a supports setting the authorization information with an
"eppcom:pwAuthInfoType" element, can have an empty authorization "eppcom:pwAuthInfoType" element can pass an empty authorization
information value passed. Examples of such extensions are [RFC5731] information value. Examples of such extensions are found in
and [RFC5733]. Setting an empty authorization information value [RFC5731] and [RFC5733]. Setting an empty authorization information
unsets the authorization information. [RFC5731] supports an explicit value unsets the authorization information. [RFC5731] supports an
mechanism of unsetting the authorization information, by passing the explicit mechanism of unsetting the authorization information, by
<domain:null> authorization information value. The registry MUST passing the <domain:null> authorization information value. The
support unsetting the authorization information by accepting an empty registry MUST support unsetting the authorization information by
authorization information value and accepting an explicit unset accepting an empty authorization information value and accepting an
element if it is supported by the object extension. explicit unset element if it is supported by the object extension.
Example of adding the "clientTransferProhibited" status and unsetting Example of adding the "clientTransferProhibited" status and unsetting
the authorization information explicitly in an [RFC5731] domain name the authorization information explicitly in a domain name <update>
update command: command [RFC5731]:
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"/>
skipping to change at page 14, line 27 skipping to change at line 633
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>
Example of unsetting the authorization information with an empty Example of unsetting the authorization information with an empty
authorization information value in an [RFC5731] domain name update authorization information value in a domain name <update> command
command: [RFC5731]:
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"/>
skipping to change at page 15, line 4 skipping to change at line 656
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>
Example of unsetting the authorization information with an empty Example of unsetting the authorization information with an empty
authorization information value in an [RFC5733] contact update authorization information value in a contact <update> command
command: [RFC5733]:
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>
5.3. Info Command and Response 5.3. <Info> Command and Response
For an info command, the registry MUST allow for the passing of a For an <info> command, the registry MUST allow the passing of a non-
non-empty authorization information value for verification. The empty authorization information value for verification. The gaining
gaining registrar can pre-verify the authorization information registrar can pre-verify the authorization information provided by
provided by the registrant prior to submitting the transfer request the registrant prior to submitting the transfer request with the use
with the use of the info command. The registry compares the hash of of the <info> command. The registry compares the hash of the passed
the passed authorization information with the hashed authorization authorization information with the hashed authorization information
information value stored for the object. When the authorization value stored for the object. When the authorization information is
information is not set or the passed authorization information does not set or the passed authorization information does not match the
not match the previously set value, the registry MUST return an EPP previously set value, the registry MUST return an EPP error result
error result code of 2202 [RFC5730]. code of 2202 [RFC5730].
Example of passing a non-empty authorization information value in an Example of passing a non-empty authorization information value in a
[RFC5731] domain name info command to verify the authorization domain name <info> command [RFC5731] to verify the authorization
information value: information value:
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>
The info response in object extensions, such as [RFC5731] and The info response in object extensions, such as those defined in
[RFC5733], MUST NOT include the optional authorization information [RFC5731] and [RFC5733], MUST NOT include the optional authorization
element with a non-empty authorization value. The authorization information element with a non-empty authorization value. The
information is stored as a hash in the registry, so returning the authorization information is stored as a hash in the registry, so
plain text authorization information is not possible, unless a valid returning the plain-text authorization information is not possible,
plain text authorization information is passed in the info command. unless valid plain-text authorization information is passed in the
The registry MUST NOT return any indication of whether the <info> command. The registry MUST NOT return any indication of
authorization information is set or unset to the non-sponsoring whether the authorization information is set or unset to the non-
registrar by not returning the authorization information element in sponsoring registrar by not returning the authorization information
the response. The registry MAY return an indication to the element in the response. The registry MAY return an indication to
sponsoring registrar that the authorization information is set by the sponsoring registrar that the authorization information is set by
using an empty authorization information value. The registry MAY using an empty authorization information value. The registry MAY
return an indication to the sponsoring registrar that the return an indication to the sponsoring registrar that the
authorization information is unset by not returning the authorization authorization information is unset by not returning the authorization
information element. information element.
Example of returning an empty authorization information value in an Example of returning an empty authorization information value in a
[RFC5731] domain name info response to indicate to the sponsoring domain name info response [RFC5731] to indicate to the sponsoring
registrar that the authorization information is set: registrar that the authorization information is set:
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
skipping to change at page 17, line 30 skipping to change at line 758
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>
5.4. Transfer Request Command 5.4. <Transfer> Request Command
For a Transfer Request Command, the registry MUST allow for the For a <transfer> request command, the registry MUST allow the passing
passing of a non-empty authorization information value to authorize a of a non-empty authorization information value to authorize a
transfer. The registry compares the hash of the passed authorization transfer. The registry compares the hash of the passed authorization
information with the hashed authorization information value stored information with the hashed authorization information value stored
for the object. When the authorization information is not set or the for the object. When the authorization information is not set or the
passed authorization information does not match the previously set passed authorization information does not match the previously set
value, the registry MUST return an EPP error result code of 2202 value, the registry MUST return an EPP error result code of 2202
[RFC5730]. Whether the transfer occurs immediately or is pending is [RFC5730]. Whether the transfer occurs immediately or is pending is
up to server policy. When the transfer occurs immediately, the up to server policy. When the transfer occurs immediately, the
registry MUST return the EPP success result code of 1000 and when the registry MUST return the EPP success result code of 1000 ("Command
transfer is pending, the registry MUST return the EPP success result completed successfully") [RFC5730], and when the transfer is pending,
code of 1001. The losing registrar MUST be informed of a successful the registry MUST return the EPP success result code of 1001
transfer request using an EPP poll message. ("Command completed successfully; action pending"). The losing
registrar MUST be informed of a successful transfer request using an
EPP <poll> message.
Example of passing a non-empty authorization information value in an Example of passing a non-empty authorization information value in a
[RFC5731] domain name transfer request command to authorize the domain name <transfer> request command [RFC5731] to authorize the
transfer: transfer:
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>
skipping to change at page 18, line 24 skipping to change at line 799
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>
Upon successful completion of the transfer, the registry MUST Upon successful completion of the transfer, the registry MUST
automatically unset the authorization information. If the transfer automatically unset the authorization information. If the transfer
request is not submitted within the time-to-live (TTL) (Section 4.2) request is not submitted within the TTL (Section 4.2) or the transfer
or the transfer is cancelled or rejected, the registrar MUST unset is canceled or rejected, the registrar MUST unset the authorization
the authorization information as defined in Section 5.2. information, as described in Section 5.2.
6. Transition Considerations 6. Transition Considerations
The goal of the transition considerations to the practice defined in The goal of the transition considerations is to minimize the impact
this document, referred to as the Secure Authorization Information to the registrars in supporting the Secure Authorization Information
Model, is to minimize the impact to the registrars by supporting Model defined in this document by supporting incremental transition
incremental steps of adoption. The transition steps are dependent on steps. The transition steps are dependent on the starting point of
the starting point of the registry. Registries may have different the registry. Registries may have different starting points, since
starting points, since some of the elements of the Secure some of the elements of the Secure Authorization Information Model
Authorization Information Model may have already been implemented. may have already been implemented. The considerations assume a
The considerations assume a starting point, referred to as the starting point, referred to as the "Classic Authorization Information
Classic Authorization Information Model, that have the following Model", which incorporates the following steps for management of the
steps in the management of the authorization information for authorization information for transfers:
transfers:
1. Registrant requests to register the object with the registrar. 1. The registrant requests to register the object with the
Registrar sends the create command, with a non-empty registrar. The registrar sends the <create> command, with a non-
authorization information value, to the registry. The registry empty authorization information value, to the registry. The
stores the authorization information as an encrypted value and registry stores the authorization information as an encrypted
requires a non-empty authorization information value for the life value and requires a non-empty authorization information value
of the object. The registrar may store the long-lived for the life of the object. The registrar may store the long-
authorization information. lived authorization information.
2. At the time of transfer, Registrant requests from the losing
2. At the time of transfer, the registrant requests from the losing
registrar the authorization information to provide to the gaining registrar the authorization information to provide to the gaining
registrar. registrar.
3. Losing registrar retrieves the locally stored authorization 3. The losing registrar retrieves the locally stored authorization
information or queries the registry for authorization information information or queries the registry for authorization information
using the info command, and provides it to the registrant. If using the <info> command, and provides it to the registrant. If
the registry is queried, the authorization information is the registry is queried, the authorization information is
decrypted and the plain text authorization information is decrypted and the plain-text authorization information is
returned in the info response to the registrar. returned in the info response to the registrar.
4. Registrant provides the authorization information value to the
gaining registrar. 4. The registrant provides the authorization information value to
5. Gaining registrar optionally verifies the authorization the gaining registrar.
information with the info command to the registry, by passing the
authorization information in the info command to the registry. 5. The gaining registrar optionally verifies the authorization
6. Gaining registrar sends the transfer request with the information with the <info> command to the registry, by passing
the authorization information in the <info> command to the
registry.
6. The gaining registrar sends the transfer request with the
authorization information to the registry. The registry will authorization information to the registry. The registry will
decrypt the stored authorization information to compare to the decrypt the stored authorization information to compare to the
passed authorization information. passed authorization information.
7. If the transfer successfully completes, the authorization
7. If the transfer completes successfully, the authorization
information is not touched by the registry and may be updated by information is not touched by the registry and may be updated by
the gaining registrar using the update command. If the transfer the gaining registrar using the <update> command. If the
is cancelled or rejected, the losing registrar may reset the transfer is canceled or rejected, the losing registrar may reset
authorization information using the update command. the authorization information using the <update> command.
The gaps between the Classic Authorization Information Model and the The gaps between the Classic Authorization Information Model and the
Secure Authorization Information Model include: Secure Authorization Information Model include the following:
1. Registry requirement for a non-empty authorization information 1. Registry requirement for a non-empty authorization information
value on create and for the life of the object versus the value on create and for the life of the object versus the
authorization information not being set on create and only being authorization information not being set on create and only being
set when a transfer is in process. set when a transfer is in process.
2. Registry not allowing the authorization information to be unset 2. Registry not allowing the authorization information to be unset
versus supporting the authorization to be unset in the update versus providing support for unsetting the authorization
command. information in the <update> command.
3. Registry storing the authorization information as an encrypted 3. Registry storing the authorization information as an encrypted
value versus as a hashed value. value versus a hashed value.
4. Registry support for returning the authorization information 4. Registry support for returning the authorization information
versus not returning the authorization information in the info versus not returning the authorization information in the info
response. response.
5. Registry not touching the authorization information versus the 5. Registry not touching the authorization information versus the
registry automatically unsetting the authorization information registry automatically unsetting the authorization information
upon a successful transfer. upon a successful transfer.
6. Registry may validate a shorter authorization information value
using password complexity rules versus validating the randomness
of a longer authorization information value that meets the
required bits of entropy.
The transition can be handled in the three phases defined in the sub- 6. Registry possibly validating a shorter authorization information
sections Section 6.1, Section 6.2, Section 6.3. value using password complexity rules versus validating the
randomness of a longer authorization information value that meets
the required bits of entropy.
The transition can be handled in the three phases defined in
Sections 6.1, 6.2, and 6.3.
6.1. Transition Phase 1 - Features 6.1. Transition Phase 1 - Features
The goal of the "Transition Phase 1 - Features" is to implement the The goal of "Transition Phase 1 - Features" is to implement the
needed features in EPP so that the registrar can optionally implement needed features in EPP so that the registrar can optionally implement
the Secure Authorization Information Model. The features to the Secure Authorization Information Model. The features to
implement are broken out by the command and responses below: implement are broken out by the commands and responses below:
Create Command: Change the create command to make the authorization <Create> Command: Change the <create> command to make the
information optional, by allowing both a non-empty value and an authorization information optional, by allowing both a non-empty
empty value. This enables a registrar to optionally create value and an empty value. This enables a registrar to optionally
objects without an authorization information value, as defined in create objects without an authorization information value, as
Section 5.1. described in Section 5.1.
Update Command: Change the update command to allow unsetting the
authorization information, as defined in Section 5.2. This <Update> Command: Change the <update> command to allow unsetting the
authorization information, as described in Section 5.2. This
enables the registrar to optionally unset the authorization enables the registrar to optionally unset the authorization
information when the TTL expires or when the transfer is cancelled information when the TTL expires or when the transfer is canceled
or rejected. or rejected.
Transfer Approve Command and Transfer Auto-Approve: Change the Transfer Approve Command and Transfer Auto-Approve: Change the
transfer approve command and the transfer auto-approve to transfer approve command and the transfer auto-approve to
automatically unset the authorization information. This sets the automatically unset the authorization information. This sets the
default state of the object to not have the authorization default state of the object to not have the authorization
information set. The registrar implementing the Secure information set. The registrar implementing the Secure
Authorization Information Model will not set the authorization Authorization Information Model will not set the authorization
information for an inbound transfer and the registrar implementing information for an inbound transfer, and the registrar
the Classic Authorization Information Model will set the new implementing the Classic Authorization Information Model will set
authorization information upon the successful transfer. the new authorization information upon a successful transfer.
Info Response: Change the info command to not return the
authorization information in the info response, as defined in Info Response: Change the <info> command to not return the
authorization information in the info response, as described in
Section 5.3. This sets up the implementation of "Transition Phase Section 5.3. This sets up the implementation of "Transition Phase
2 - Storage", since the dependency in returning the authorization 2 - Storage" (Section 6.2), since the dependency on returning the
information in the info response will be removed. This feature is authorization information in the info response will be removed.
the only one that is not an optional change to the registrar that This feature is the only one that is not an optional change to the
has the potential of breaking the client, so it's recommended that registrar, and this change could potentially break the client, so
the registry provide notice of the change. it's recommended that the registry provide notice of the change.
Info Command and Transfer Request: Change the info command and the
transfer request to ensure that a registrar cannot get an <Info> Command and Transfer Request: Change the <info> command and
the transfer request to ensure that a registrar cannot get an
indication that the authorization information is set or not set by indication that the authorization information is set or not set by
returning the EPP error result code of 2202 when comparing a returning the EPP error result code of 2202 when comparing a
passed authorization to a non-matching set authorization passed authorization to a non-matching set authorization
information value or an unset value. information value or an unset value.
6.2. Transition Phase 2 - Storage 6.2. Transition Phase 2 - Storage
The goal of the "Transition Phase 2 - Storage" is to transition the The goal of "Transition Phase 2 - Storage" is to transition the
registry to use hashed authorization information instead of encrypted registry to use hashed authorization information instead of encrypted
authorization information. There is no direct impact to the authorization information. There is no direct impact on the
registrars, since the only visible indication that the authorization registrars, since the only visible indication that the authorization
information has been hashed is by not returning the set authorization information has been hashed is that the set authorization information
information in the info response, which is addressed in Transition is not returned in the info response, as addressed in "Transition
Phase 1 - Features (Section 6.1). There are three steps to Phase 1 - Features" (Section 6.1). Transitioning the authorization
transition the authorization information storage, which includes: information storage includes the following three steps:
Hash New Authorization Information Values: Change the create command Hash New Authorization Information Values: Change the <create>
and the update command to hash instead of encrypting the command and the <update> command to hash rather than encrypt the
authorization information. authorization information.
Supporting Comparing Against Encrypted and Hashed Authorization
Information: Change the info command and the transfer request Support Comparison against Encrypted or Hashed Authorization
Information: Change the <info> command and the <transfer> request
command to be able to compare a passed authorization information command to be able to compare a passed authorization information
value with either a hashed or encrypted authorization information value with either a hashed or encrypted authorization information
value. This requires that the stored values are self-identifying value. This requires that the stored values be self-identifying
as being in hashed or encrypted form. as being in hashed or encrypted form.
Hash Existing Encrypted Authorization Information Values: Convert Hash Existing Encrypted Authorization Information Values: Convert
the encrypted authorization information values stored in the the encrypted authorization information values stored in the
registry database to hashed values. The update is not a visible registry database to hashed values. This update will not be
change to the registrar. The conversion can be done over a period visible to the registrar. The conversion can be done over a
of time depending on registry policy. period of time, depending on registry policy.
6.3. Transition Phase 3 - Enforcement 6.3. Transition Phase 3 - Enforcement
The goal of the "Transition Phase 3 - Enforcement" is to complete the The goal of "Transition Phase 3 - Enforcement" is to complete the
implementation of the "Secure Authorization Information Model", by implementation of the Secure Authorization Information Model, by
enforcing the following: enforcing the following:
Disallow Authorization Information on Create Command: Change the Disallow Authorization Information on <Create> Command: Change the
create command to not allow for the passing of a non-empty <create> command to not allow the passing of a non-empty
authorization information value. This behavior has the potential authorization information value. This behavior could potentially
of breaking the client, so it's recommended that the registry break the client, so it's recommended that the registry provide
provide notice of the change. notice of this change.
Validate the Strong Random Authorization Information: Change the Validate the Strong Random Authorization Information: Change the
validation of the authorization information in the update command validation of the authorization information in the <update>
to ensure at least 128 bits of entropy. command to ensure at least 128 bits of entropy.
7. IANA Considerations 7. IANA Considerations
7.1. XML Namespace 7.1. XML Namespace
This document uses URNs to describe XML namespaces conforming to a This document uses URNs to describe XML namespaces conforming to the
registry mechanism described in [RFC3688]. The following URI registry mechanism described in [RFC3688]. IANA has assigned the
assignment is requested of IANA: following URI in the "ns" subregistry within the "IETF XML Registry"
for secure authorization information for the transfer namespace:
Registration request for the secure authorization information for
transfer namespace:
URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
7.2. EPP Extension Registry 7.2. EPP Extension Registry
The EPP operational practice described in this document should be IANA has registered the EPP operational practice described in this
registered by the IANA in the EPP Extension Registry described in document in the "Extensions for the Extensible Provisioning Protocol
[RFC7451]. The details of the registration are as follows: (EPP)" registry as defined in [RFC7451]. The details of the
registration are as follows:
Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
Authorization Information for Transfer"
Document status: Standards Track
Reference: (insert reference to RFC version of this document)
Registrant Name and Email Address: IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
8. Implementation Status
Note to RFC Editor: Please remove this section and the reference to
RFC 7942 [RFC7942] before publication.
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 RFC 7942
[RFC7942]. 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.
According to RFC 7942 [RFC7942], "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".
8.1. Verisign EPP SDK
Organization: Verisign Inc.
Name: Verisign EPP SDK
Description: The Verisign EPP SDK includes both a full client
implementation and a full server stub implementation of draft-ietf-
regext-secure-authinfo-transfer.
Level of maturity: Development
Coverage: All aspects of the protocol are implemented.
Licensing: GNU Lesser General Public License
Contact: jgould@verisign.com
URL: https://www.verisign.com/en_US/channel-resources/domain-
registry-products/epp-sdks
8.2. RegistryEngine EPP Service
Organization: CentralNic
Name: RegistryEngine EPP Service
Description: Generic high-volume EPP service for gTLDs, ccTLDs and
SLDs
Level of maturity: Deployed in CentralNic's production environment as
well as two other gTLD registry systems, and two ccTLD registry
systems.
Coverage: Authorization Information is "write only" in that the
registrars can set the Authorization Information, but not get the
Authorization Information in the Info Response.
Licensing: Proprietary In-House software
Contact: epp@centralnic.com Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
URL: https://www.centralnic.com Authorization Information for Transfer"
Document status: Standards Track
Reference: RFC 9154
Registrant Name and Email Address: IESG (iesg@ietf.org)
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
9. Security Considerations 8. Security Considerations
Section 4.1 defines the use a secure random value for the generation Section 4.1 defines the use of a secure random value for the
of the authorization information. The client SHOULD choose a length generation of authorization information. The client SHOULD choose a
and set of characters that results in at least 128 bits of entropy. length and set of characters that result in at least 128 bits of
entropy.
Section 4.2 defines the use of an authorization information Time-To- Section 4.2 defines the use of an authorization information TTL. The
Live (TTL). The registrar SHOULD only set the authorization registrar SHOULD only set the authorization information during the
information during the transfer process by the server support for transfer process by setting the authorization information at the
setting and unsetting the authorization information. The TTL value start of the transfer process and unsetting the authorization
is up to registrar policy and the sponsoring registrar MUST inform information at the end of the transfer process. The TTL value is
left up to registrar policy, and the sponsoring registrar MUST inform
the registrant of the TTL when providing the authorization the registrant of the TTL when providing the authorization
information to the registrant. information to the registrant.
Section 4.3 defines the storage and transport of authorization Section 4.3 defines the storage and transport of authorization
information. The losing registrar MUST NOT store the authorization information. The losing registrar MUST NOT store the authorization
information and the gaining registrar MUST only store the information and the gaining registrar MUST only store the
authorization information as a "transient" value during the transfer authorization information as a "transient" value during the transfer
process, where the authorization information MUST NOT be stored after process, where the authorization information MUST NOT be stored after
the end of the transfer process. The registry MUST store the the end of the transfer process. The registry MUST store the
authorization information using a one-way cryptographic hash of at authorization information using a one-way cryptographic hash of at
least 256 bits and with a per-authorization information random salt, least 256 bits and with a per-authorization information random salt
with at least 128 bits. All communication that includes the with at least 128 bits. All communication that includes the
authorization information MUST be over an encrypted channel. The authorization information MUST be over an encrypted channel. The
plain text authorization information MUST NOT be written to any logs plain-text authorization information MUST NOT be written to any logs
by the registrar or the registry. by the registrar or the registry.
Section 4.4 defines the matching of the authorization information Section 4.4 defines the matching of the authorization information
values. The registry stores an unset authorization information as a values. The registry stores an unset authorization information value
NULL (undefined) value to ensure that an empty input authorization as a NULL (undefined) value to ensure that an empty input
information never matches it. The method used to define a NULL authorization information value never matches it. The method used to
(undefined) value is database specific. define a NULL (undefined) value is database specific.
10. Acknowledgements
The authors wish to thank the following persons for their feedback
and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew
Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 25, line 37 skipping to change at line 1075
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>. August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734, Transport over TCP", STD 69, RFC 5734,
DOI 10.17487/RFC5734, August 2009, DOI 10.17487/RFC5734, August 2009,
<https://www.rfc-editor.org/info/rfc5734>. <https://www.rfc-editor.org/info/rfc5734>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
11.2. Informative References [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126>.
9.2. Informative References
[FIPS-140-2] [FIPS-140-2]
National Institute of Standards and Technology, U.S. National Institute of Standards and Technology, U.S.
Department of Commerce, "NIST Federal Information Department of Commerce, "NIST Federal Information
Processing Standards (FIPS) Publication 140-2", May 2001, Processing Standards (FIPS) Publication 140-2",
DOI 10.6028/NIST.FIPS.140-2, May 2001,
<https://csrc.nist.gov/publications/detail/fips/140/2/ <https://csrc.nist.gov/publications/detail/fips/140/2/
final>. final>.
[FIPS-180-4] [FIPS-180-4]
National Institute of Standards and Technology, U.S. National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard, NIST Department of Commerce, "Secure Hash Standard, NIST
Federal Information Processing Standards (FIPS) Federal Information Processing Standards (FIPS)
Publication 180-4", August 2015, Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August
2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/ <https://csrc.nist.gov/publications/detail/fips/180/4/
final>. final>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>. February 2015, <https://www.rfc-editor.org/info/rfc7451>.
Appendix A. Change History Acknowledgements
A.1. Change from 00 to 01
1. Filled in the "Implementation Status" section with the inclusion
of the "Verisign EPP SDK" and "RegistryEngine EPP Service"
implementations.
2. Made small wording corrections based on private feedback.
3. Added content to the "Acknowledgements" section.
A.2. Change from 01 to 02
1. Revised the language used for the storage of the authorization
information based on the feedback from Patrick Mevzek and Jody
Kolker.
A.3. Change from 02 to 03
1. Updates based on the feedback from the interim REGEXT meeting
held at ICANN-66:
1. Section 3.3, include a reference to the hash algorithm to
use. Broke the requirements into a list and included a the
reference the text ', with at least a 256-bit hash function,
such as SHA-256'.
2. Add a Transition Considerations section to cover the
transition from the classic authorization information
security model in the EPP RFCs to the model defined in the
document.
3. Add a statement to the Introduction that elements of the
practice can be used for purposes other than transfer, but
with a caveat.
2. Updates based on the review by Michael Bauland, that include:
1. In section 2, change 'there are three actors' to 'there are
three types of actors' to cover the case with transfers that
has two registrar actors (losing and gaining).
2. In section 3.1, change the equations equals to be
approximately equal by using '=~' instead of '=', where
applicable.
3. In section 3.3, change 'MUST be over an encrypted channel,
such as RFC5734' to 'MUST be over an encrypted channel, such
as defined in RFC5734'.
4. In section 4.1, remove the optional RFC 5733 elements from
the contact create, which includes the <contact:voice>,
<contact:fax>, <contact:disclose>, <contact:org>,
<contact:street>, <contact:sp>, and <contact:cc> elements.
5. In section 4.2, changed 'Example of unsetting the
authorization information explicitly in an [RFC5731] domain
name update command.' to 'Example of adding the
"clientTransferProhibited" status and unsetting the
authorization information explicitly in an [RFC5731] domain
name update command.'
6. In section 4.3, cover a corner case of the ability to return
the authorization information when it's passed in the info
command.
7. In section 4.4, change 'If the transfer does not complete
within the time-to-live (TTL)' to 'If the transfer is not
initiated within the time-to-live (TTL)', since the TTL is
the time between setting the authorization information and
when it's successfully used in a transfer request. Added the
case of unsetting the authorization information when the
transfer is cancelled or rejected.
3. Updates based on the authorization information messages by Martin
Casanova on the REGEXT mailing list, that include:
1. Added section 3.4 'Authorization Information Matching' to
clarify how the authorization information is matched, when
there is set and unset authorization information in the
database and empty and non-empty authorization information
passed in the info and transfer commands.
2. Added support for signaling that the authorization
information is set or unset to the sponsoring registrar with
the inclusion of an empty authorization information element
in the response to indicate that the authorization
information is set and the exclusion of the authorization
information element in the response to indicate that the
authorization information is unset.
4. Made the capitalization of command and response references
consistent by uppercasing section and item titles and lowercasing
references elsewhere.
A.4. Change from 03 to REGEXT 00
1. Changed to regext working group draft by changing draft-gould-
regext-secure-authinfo-transfer to draft-ietf-regext-secure-
authinfo-transfer.
A.5. Change from REGEXT 00 to REGEXT 01
1. Added the "Signaling Client and Server Support" section to
describe the mechanism to signal support for the BCP by the
client and the server.
2. Added the "IANA Considerations" section with the registration of
the secure authorization for transfer XML namespace and the
registration of the EPP Best Current Practice (BCP) in the EPP
Extension Registry.
A.6. Change from REGEXT 01 to REGEXT 02
1. Added inclusion of random salt for the hashed authorization
information, based on feedback from Ulrich Wisser.
2. Added clarification that the representation of a NULL (undefined)
value is dependent on the type of database, based on feedback
from Patrick Mevzek.
3. Filled in the Security Considerations section.
A.7. Change from REGEXT 02 to REGEXT 03
1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure-
authinfo-transfer-1.0, which removed bcp from the namespace and
bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML
namespace was discussed at the REGEXT interim meeting.
2. Replaced Auhtorization with Authorization based on a review by
Jody Kolker.
A.8. Change from REGEXT 03 to REGEXT 04
1. Converted from xml2rfc v2 to v3.
2. Updated Acknowledgements to match the approach taken by the RFC
Editor with draft-ietf-regext-login-security.
3. Changed from Best Current Practice (BCP) to Standards Track based
on mailing list discussion.
A.9. Change from REGEXT 04 to REGEXT 05
1. Fixed IDNITS issues, including moving RFC7451 to Informative
References section.
A.10. Change from REGEXT 05 to REGEXT 06
Updates based on the Barry Leiba (AD) feedback:
1. Simplified the abstract based on the proposal provided.
2. In the Introduction, split the first paragraph by starting a new
paragraph at "This document".
3. In section 1.1, updated to use the new BCP 14 boilerplate and
add a normative reference to RFC 8174.
4. In section 4, Updated the phrasing to "For the authorization
information to be secure it must be generated using a strong
random value and have a short time-to-live (TTL).".
5. In section 4.1, removed the first two unnecessary calculations
and condensed the introduction of the section.
6. In section 4.1, added the use of the normative SHOULD for use of
at least 128 bits of entropy.
7. Added an informative reference to FIPS 180-4 for the SHA-256
references.
8. Normalized the way that the "empty and non-empty authorization
information values" are referenced, which a few exceptions.
9. In section 4, revised the first sentence to explicitly reference
the use of the <domain:pw> and <contact:pw> elements for
password-based authorization information.
10. In section 4.4, revised the language associated with the storage
of the authorization information to be cleaner.
11. In section 4.4, added "set" in the sentence "An empty input
authorization information value MUST NOT match any set
authorization information value."
12. In section 5.1 and 5.2, clarified the references to RFC5731 and
RFC5733 as examples of object extensions that use the
"eppcom:pwAuthInfoType" element.
13. In section 5.2, updated language for the validation of the
randomness of the authorization information, based on an offline
review by Barry Leiba, Benjamin Kaduk, and Roman Danyliw.
14. In section 9, changed "49 bits of entropy" to "128 bits of
entropy".
In section 3, replaced the reference to BCP with operational
practice, since the draft is not defined as a BCP.
A.11. Change from REGEXT 06 to REGEXT 07
1. Updates based on the Lars Eggert feedback:
1. Updated Section 1, Paragraph 4 to read "The operational
practice will require the client to not store the
authorization information and".
2. Updated each of the example references to end with a colon
instead of a period.
3. Updated Section 1, Paragraph 3 to read "provide secure
authorization information used for transfers."
4. Updated Section 3, Paragraph 3 to read "extension services
can expect".
5. Updated Section 4, Paragraph 2 to read "authorization
information to be secure, it must".
6. Updated Section 4.2, Paragraph 2 to read "authorization
information by the sponsoring registrar, the".
7. Updated Section 4.2, Paragraph 2 to read "proprietary
registrar-specific criteria, which".
8. Updated Section 4.3, Paragraph 3 to read "256-bit hash
function, such as SHA-256".
9. Updated Section 4.3, Paragraph 3 to read "a NULL (undefined)
value".
10. Updated Section 5, Paragraph 2 to read "To secure the
transfer process using secure authorization".
11. Updated Section 5.2, Paragraph 6 to read "Often, the
registrar has the "clientTransferProhibited" status set".
12. Updated Section 5.2, Paragraph 9 to read "MUST cancel cancel
the transfer process by unsetting the authorization
information value and MAY add back statuses".
13. Updated Section 5.2, Paragraph 9 to read
""eppcom:pwAuthInfoType" element can have".
2. Updated the first sentence of the abstract and introduction based
on the Rob Wilton feedback to help non-EPP readers on the what
and the who for transfers.
3. Removed the duplicate first paragraph of section 5.2 based on
feedback from Francesca Palombini.
4. Updates based on the Benjamin Kaduk feedback:
1. Added the second paragraph in the Introduction to provide
high-level motivation for the work.
2. Updated Section 1, changed "in any way" to "in any
substantial way".
3. Updated Section 1 by adding the sentence "All of these
features are compatible with the EPP RFCs, though not
mandatory to implement." for the "Short-Lived Authorization
Information".
4. Updated the description of "Short-Lived Authorization The authors wish to thank the following persons for their feedback
Information" in Section 1 to reference section 2.6 of and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
RFC5731 and change in nature of the authorization Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew
information. Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.
5. Updated Section 4.1, Paragraph 1 and 2 were merged with
modified language proposed by Benjamin Kaduk, which included
removing the reference to RFC4086 for length and entropy.
6. Updated rule #1 of Section 4.1 to add a second clarifying
sentence for what is meant by input authorization
information.
7. Updated Section 4.1 by replacing the last paragraph "The
strength of the random..." with a revised version.
8. Updated "retrieves the stored authorization information
locally" with "retrieves the locally stored authorization
information".
9. Updated Section 6.1 to include the recommendation that the
registry provide notice of the Info Response change.
10. Updated Section 6.2 to include the sentence "This requires
that the stored values are self-identifying as being in
hashed or encrypted form" for the "Supporting Comparing
Against Encrypted and Hashed Authorization Information"
step.
11. Updated Section 6.3 to include the recommendation that the
registry provide notice of the Create Command change.
12. Updated "written to any logs by the registrar or the
registry" to "written to any logs by a registrar or the
registry" to cover both the losing and the gaining
registrar.
13. Updated references to "with a random salt" to "with a per-
authorization information random salt, with at least 128
bits" to address sharing of salts and the size of the salts.
14. Updated the first paragraph of Section 9 to remove the
reference to defining a server policy for the length and set
of characters that are included in the randomization to
target the target entropy level.
15. Updated Section 9 by removing the sentence "A random number
generator (RNG) is preferable over the use of a pseudorandom
number generator (PRNG) when creating the authorization
information value."
16. Changed FIPS-140-2 from a normative reference to an
informative reference.
Authors' Addresses Authors' Addresses
James Gould James Gould
VeriSign, Inc. Verisign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisign.com URI: https://www.verisign.com
Richard Wilhelm Richard Wilhelm
VeriSign, Inc. Verisign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: rwilhelm@verisign.com Email: 4rickwilhelm@gmail.com
URI: http://www.verisign.com URI: https://www.verisign.com
 End of changes. 148 change blocks. 
823 lines changed or deleted 522 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/