draft-ietf-regext-secure-authinfo-transfer-05.txt   draft-ietf-regext-secure-authinfo-transfer-06.txt 
Network Working Group J. Gould Network Working Group J. Gould
Internet-Draft R. Wilhelm Internet-Draft R. Wilhelm
Intended status: Standards Track VeriSign, Inc. Intended status: Standards Track VeriSign, Inc.
Expires: 8 July 2021 4 January 2021 Expires: 9 September 2021 8 March 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-05 draft-ietf-regext-secure-authinfo-transfer-06
Abstract Abstract
The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
use of authorization information to authorize a transfer. The use of authorization information to authorize a transfer. Object-
authorization information is object-specific and has been defined in specific, password-based authorization information (see RFC 5731 and
the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact RFC 5733) is commonly used, but raises issues related to the
Mapping, in RFC 5733, as password-based authorization information. security, complexity, storage, and lifetime of authentication
Other authorization mechanisms can be used, but in practice the information. This document defines an operational practice, using
password-based authorization information has been used at the time of the EPP RFCs, that leverages the use of strong random authorization
object create, managed with the object update, and used to authorize information values that are short-lived, not stored by the client,
an object transfer request. What has not been fully considered is and stored by the server using a cryptographic hash that provides for
the security of the authorization information that includes the secure authorization information that can safely be used for object
complexity of the authorization information, the time-to-live (TTL) transfers.
of the authorization information, and where and how the authorization
information is stored. This document defines an operational
practice, using the EPP RFCs, that leverages the use of strong random
authorization information values that are short-lived, that are not
stored by the client, and that are stored using a cryptographic hash
by the server to provide for secure authorization information used
for transfers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 July 2021. This Internet-Draft will expire on 9 September 2021.
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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 23
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5
3. Signaling Client and Server Support . . . . . . . . . . . . . 6 3. Signaling Client and Server Support . . . . . . . . . . . . . 6
4. Secure Authorization Information . . . . . . . . . . . . . . 7 4. Secure Authorization Information . . . . . . . . . . . . . . 7
4.1. Secure Random Authorization Information . . . . . . . . . 7 4.1. Secure Random Authorization Information . . . . . . . . . 7
4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8
4.3. Authorization Information Storage and Transport . . . . . 9 4.3. Authorization Information Storage and Transport . . . . . 8
4.4. Authorization Information Matching . . . . . . . . . . . 9 4.4. Authorization Information Matching . . . . . . . . . . . 9
5. Create, Transfer, and Secure Authorization Information . . . 10 5. Create, Transfer, and Secure Authorization Information . . . 9
5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10
5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12
5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15
5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17
6. Transition Considerations . . . . . . . . . . . . . . . . . . 18 6. Transition Considerations . . . . . . . . . . . . . . . . . . 18
6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 20
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 20 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 21
6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 22
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28
A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28
A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28
A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 27 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28
A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 28 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the
use of authorization information to authorize a transfer. The use of authorization information to authorize a transfer. The
authorization information is object-specific and has been defined in authorization information is object-specific and has been defined in
the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact
Mapping, in [RFC5733], as password-based authorization information. Mapping, in [RFC5733], as password-based authorization information.
Other authorization mechanisms can be used, but in practice the Other authorization mechanisms can be used, but in practice the
password-based authorization information has been used at the time of password-based authorization information has been used at the time of
object create, managed with the object update, and used to authorize object create, managed with the object update, and used to authorize
an object transfer request. What has not been considered is the an object transfer request. What has not been considered is the
security of the authorization information that includes the security of the authorization information that includes the
complexity of the authorization information, the time-to-live (TTL) complexity of the authorization information, the time-to-live (TTL)
of the authorization information, and where and how the authorization of the authorization information, and where and how the authorization
information is stored. This document defines an operational information is stored.
practice, using the EPP RFCs, that leverages the use of strong,
random authorization information values that are short-lived, that This document defines an operational practice, using the EPP RFCs,
are not stored by the client, and that are stored by the server using that leverages the use of strong, random authorization information
a cryptographic hash to provide, for secure authorization information values that are short-lived, that are not stored by the client, and
used for transfers. This operational practice can be used to support that are stored by the server using a cryptographic hash to provide,
transfers of any EPP object, where the domain name object defined in for secure authorization information used for transfers. This
[RFC5731] is used in this document for illustration purposes. operational practice can be used to support transfers of any EPP
Elements of the practice may be used to support the secure use of the object, where the domain name object defined in [RFC5731] is used in
authorization information for purposes other than transfer, but any this document for illustration purposes. Elements of the practice
other purposes and the applicable elements are out-of-scope for this may be used to support the secure use of the authorization
document. information for purposes other than transfer, but any other purposes
and the applicable elements are out-of-scope for this document.
The overall goal is to have strong, random authorization information 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 that are either not stored or
stored as a cryptographic hash values by the non-responsible parties. stored as a cryptographic hash values by the non-responsible parties.
In a registrant, registrar, and registry model, the registrant In a registrant, registrar, and registry model, the registrant
registers the object through the registrar to the registry. The registers the object through the registrar to the registry. The
registrant is the responsible party and the registrar and the registrant is the responsible party and the registrar and the
registry are the non-responsible parties. EPP is a protocol between registry are the non-responsible parties. EPP is a protocol between
the registrar and the registry, where the registrar is referred to as the registrar and the registry, where the registrar is referred to as
the client and the registry is referred to as the server. The the client and the registry is referred to as the server. The
skipping to change at page 4, line 17 skipping to change at page 4, line 15
schema "normalizedString" type, so they don't restrict what can schema "normalizedString" type, so they don't restrict what can
be used in any way. This operational practice defines the be used in any way. This operational practice defines the
recommended mechanism for creating a strong random authorization recommended mechanism for creating a strong random authorization
value, that would be generated by the client. value, that would be generated by the client.
"Short-Lived Authorization Information": The EPP RFCs don't "Short-Lived Authorization Information": The EPP RFCs don't
explicitly support short-lived authorization information or a explicitly support short-lived authorization information or a
time-to-live (TTL) for authorization information, but there are time-to-live (TTL) for authorization information, but there are
EPP RFC features that can be leveraged to support short-lived EPP RFC features that can be leveraged to support short-lived
authorization information. If authorization information is set authorization information. If authorization information is set
only when there is a transfer in process, the server needs to only when there is a transfer in process, the server needs to
support empty authorization information on create, support support an empty authorization information value on create,
setting and unsetting authorization information, and support support setting and unsetting authorization information, and
automatically unsetting the authorization information upon a support automatically unsetting the authorization information
successful transfer. All of these features can be supported by upon a successful transfer. All of these features can be
the EPP RFCs. 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 to define
an operational practice for storing the authorization information an operational practice for storing the authorization information
securely. The operational practice will not require the client securely. The operational practice will not require the client
to store the authorization information and will require the to store the authorization information and will require the
server to store the authorization information using a server to store the authorization information using a
cryptographic hash, with at least a 256-bit hash function such as cryptographic hash, with at least a 256-bit hash function such as
SHA-256, and with a random salt. Returning the authorization SHA-256 [FIPS-180-4], and with a random salt. Returning the
information set in an EPP info response will not be supported. authorization 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
implementation. 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 white 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.
skipping to change at page 6, line 23 skipping to change at page 6, line 23
"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 new protocol but an operational
practice using the existing EPP protocol, where the client and the practice using the existing EPP protocol, where the client and the
server can signal support for the BCP using a namespace URI in the server can signal support for the operational practice using a
login and greeting extension services. The namespace URI namespace URI in the login and greeting extension services. The
"urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-
signal support for the BCP. The client includes the namespace URI in 1.0" is used to signal support for the operational practice. The
an <svcExtension> <extURI> element of the [RFC5730] <login> Command. client includes the namespace URI in an <svcExtension> <extURI>
The server includes the namespace URI in an <svcExtension> <extURI> element of the [RFC5730] <login> Command. The server includes the
element of the [RFC5730] Greeting. namespace URI in an <svcExtension> <extURI> element of the [RFC5730]
Greeting.
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 extension services, can expect the following supported behavior by
the server: the server:
1. Support empty authorization information with a create command. 1. Support an empty authorization information value with a create
command.
2. Support unsetting authorization information with an update 2. Support unsetting authorization information with an update
command. command.
3. Support validating authorization information with an info 3. Support validating authorization information with an info
command. command.
4. Support not returning an indication whether the authorization 4. Support not returning an indication whether the authorization
information is set or unset to the non-sponsoring registrar. information is set or unset to the non-sponsoring registrar.
5. Support returning empty authorization information to sponsoring 5. Support returning an empty authorization information value to the
registrar when the authorization information is set in an info sponsoring registrar when the authorization information is set in
response. an info response.
6. Support allowing for the passing of a matching non-empty 6. Support allowing for the passing of a matching non-empty
authorization information to authorize a transfer. authorization information value to authorize a transfer.
7. Support automatically unsetting the authorization information 7. Support automatically unsetting the authorization information
upon a successful completion of transfer. upon a successful completion of 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 generation of authorization information using a secure
random value. random value.
2. Support only setting the authorization information when there is 2. Support only setting the authorization information when there is
a transfer in process. a transfer in process.
4. Secure Authorization Information 4. Secure Authorization Information
The authorization information in the EPP RFCs ([RFC5731] and The authorization information in the EPP RFCs ([RFC5731] and
[RFC5733]) that support transfer use password-based authorization [RFC5733]) that support transfer use password-based authorization
information. Other EPP objects that support password-based information ([RFC5731] with the <domain:pw> element and [RFC5733]
authorization information for transfer can use the Secure with the <contact:pw> element). Other EPP objects that support
Authorization Information defined in this document. For the password-based authorization information for transfer can use the
authorization information to be secure it must be a strong random Secure Authorization Information defined in this document. For the
value and must have a short time-to-live (TTL). The security of the authorization information to be secure it must be generated using a
authorization information is defined in the following sections. strong random value and have a short time-to-live (TTL). The
security of the authorization information is defined in the following
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, where according to [RFC4086] a high-security treated as a password, where according to [RFC4086] a high-security
password must have at least 49 bits of randomness or entropy. The password must have at least 49 bits of randomness or entropy. The
required length L of a password, rounded up to the largest whole required length L of a password, rounded up to the largest whole
number, is based on the set of characters N and the desired entropy number, is based on the set of characters N and the desired entropy
H, in the equation L = ROUNDUP(H / log2 N). With a target entropy of H, in the equation L = ROUNDUP(H / log2 N). Given a target entropy,
49, the required length can be calculated after deciding on the set the required length can be calculated after deciding on the set of
of characters that will be randomized. The following are a set of characters that will be randomized.
possible character sets and the calculation of the required length.
Calculation of the required length with 49 bits of entropy and with
the set of all printable ASCII characters except space (0x20), which
consists of the 94 characters 0x21-0x7E.
ROUNDUP(49 / log2 94) =~ ROUNDUP(49 / 6.55) =~ ROUNDUP(7.48) = 8
Calculation of the required length with 49 bits of entropy and with
the set of case-insensitive alphanumeric characters, which consists
of 36 characters (a-z A-Z 0-9).
ROUNDUP(49 / log2 36) =~ ROUNDUP(49 / 5.17) =~ ROUNDUP(9.48) = 10
Considering the age of [RFC4086], the evolution of security Considering the age of [RFC4086], the evolution of security
practices, and that the authorization information is a machine- practices, and that the authorization information is a machine-
generated value, the recommendation is to use at least 128 bits of generated value, the implementation SHOULD use at least 128 bits of
entropy. The lengths are recalculated below using 128 bits of entropy. The lengths are calculated below using that value.
entropy.
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 / log2 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 / log2 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 actual entropy of the underlying random number generator. For the actual entropy of the underlying random number generator. For
the random number generator, the practices defined in [RFC4086] and the random number generator, the practices defined in [RFC4086] and
section 4.7.1 of the NIST Federal Information Processing Standards section 4.7.1 of the NIST Federal Information Processing Standards
(FIPS) Publication 140-2 (FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to produce
(https://csrc.nist.gov/publications/detail/fips/140/2/final) SHOULD random values that will be resistant to attack. A random number
be followed to produce random values that will be resistant to generator (RNG) is preferable over the use of a pseudorandom number
attack. A random number generator (RNG) is preferable over the use generator (PRNG) to reduce the predictability of the authorization
of a pseudorandom number generator (PRNG) to reduce the information. The more predictable the random number generator is,
predictability of the authorization information. The more the lower the true entropy, and the longer the required length for
predictable the random number generator is, the lower the true the authorization information.
entropy, and the longer the required length for the authorization
information.
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 there is a
transfer in process. This implies that the authorization information transfer in process. This implies that the authorization information
has a Time-To-Live (TTL) by which the authorization information is has a Time-To-Live (TTL) by which the authorization information is
cleared when the TTL expires. The EPP RFCs have no definition of cleared when the TTL expires. The EPP RFCs have no definition of
TTL, but since the server supports the setting and unsetting of the TTL, but since the server supports the setting and unsetting of the
authorization information by the sponsoring registrar, then the authorization information by the sponsoring registrar, then the
sponsoring registrar can apply a TTL based on client policy. The TTL sponsoring registrar can apply a TTL based on client policy. The TTL
skipping to change at page 9, line 12 skipping to change at page 8, line 42
registrant of the TTL when the authorization information is provided registrant of the TTL when 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 hash function such as SHA-256, and with a random salt. 256-bit hash function such as SHA-256 [FIPS-180-4], and with a
2. An empty authorization information MUST be stored as an undefined random salt.
2. Empty authorization information MUST be stored as an undefined
value that is referred to as a NULL value. The representation of value that is referred to as a NULL value. The representation of
an NULL (undefined) value is dependent on the type of database an NULL (undefined) value is dependent on the type of database
used. 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 the registrar or the registry. be written to any logs by the registrar or the registry, nor
otherwise recorded where it will persist beyond the transfer
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, such as defined in [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 defined 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. The unset authorization information is stored with a unset state. Authorization information that is unset is stored with
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, a set authorization information is stored as defined in Section 4.3, authorization information that is set is
with a non-NULL hashed value. The empty authorization information is stored with a non-NULL hashed value. The empty authorization
used as input in both the create command (Section 5.1) and the update information is used as input in both the create command (Section 5.1)
command (Section 5.2) to define the unset state. The matching of the and the update command (Section 5.2) to define the unset state. The
authorization information in the info command (Section 5.3) and the matching of the authorization information in the info command
transfer request command (Section 5.4) is based on the following (Section 5.3) and the transfer request command (Section 5.4) is based
rules: 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. authorization information value.
2. An empty input authorization information value MUST NOT match any 2. An empty input authorization information value MUST NOT match any
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 make the transfer process secure using secure authorization To make the transfer process secure using secure authorization
information, as defined in Section 4, the client and server need to information, as defined in Section 4, the client and server need to
implement steps where the authorization information is set only when implement steps where the authorization information is set only when
a transfer is actively in process and ensure that the authorization a transfer is actively in process and ensure that the authorization
information is stored securely and transported only over secure information is stored securely and transported only over secure
channels. The steps in management of the authorization information channels. The steps in management of the authorization information
for transfers include: for transfers include:
1. Registrant requests to register the object with the registrar. 1. Registrant requests to register the object with the registrar.
Registrar sends the create command, with empty authorization Registrar sends the create command, with an empty authorization
information, to the registry, as defined in Section 5.1. information value, to the registry, as defined in Section 5.1.
2. Registrant requests from the losing registrar the authorization 2. Registrant requests from the losing registrar the authorization
information to provide to the gaining registrar. information to provide to the gaining registrar.
3. Losing registrar generates a secure random authorization 3. Losing registrar generates a secure random authorization
information value, sends it to the registry as defined in information value, sends it to the registry as defined in
Section 5.2, and provides it to the registrant. Section 5.2, and provides it to the registrant.
4. Registrant provides the authorization information value to the 4. Registrant provides the authorization information value to the
gaining registrar. gaining registrar.
5. Gaining registrar optionally verifies the authorization 5. Gaining registrar optionally verifies the authorization
information with the info command to the registry, as defined in information with the info command to the registry, as defined in
Section 5.3. Section 5.3.
skipping to change at page 10, line 43 skipping to change at page 10, line 30
losing registrar unsets the authorization information when the losing registrar unsets the authorization information when the
TTL expires, as defined in Section 5.2. TTL expires, as defined in 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 for the passing of an
empty authorization information and MAY disallow for the passing of a empty authorization information value and MAY disallow for the
non-empty authorization information. By having an empty passing of a non-empty authorization information value. By having an
authorization information on create, the object is initially not in empty authorization information value on create, the object is
the transfer process. Any EPP object extension that supports setting initially not in the transfer process. Any EPP object extension that
the authorization information with a "eppcom:pwAuthInfoType" element, supports setting the authorization information with a
can have an empty authorization information passed, such as [RFC5731] "eppcom:pwAuthInfoType" element, can have an empty authorization
information value passed. Examples of such extensions are [RFC5731]
and [RFC5733]. and [RFC5733].
Example of passing empty authorization information in an [RFC5731] Example of passing an empty authorization information value in an
domain name create command. [RFC5731] domain name create command.
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 empty authorization information in an [RFC5733] Example of passing an empty authorization information value in an
contact create command. [RFC5733] contact create command.
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 11 skipping to change at page 12, line 11
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 for 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 Section 4.1, and setting it
in the registry in the update command. The registry SHOULD validate in the registry in the update command.
the randomness of the authorization information based on the length
and character set required by the registry. For example, a registry For an update command, the registry MUST allow for the setting and
that requires 20 random printable ASCII characters except space unsetting of the authorization information. The registrar sets the
(0x20), should validate that the authorization information contains authorization information by first generating a strong, random
at least one upper case alpha character, one lower case alpha authorization information value, based on Section 4.1, and setting it
character, and one non-alpha numeric character. If the authorization in the registry in the update command. The importance of generating
information fails the randomness validation, the registry MUST return strong authorization information values cannot be overstated: secure
an EPP error result code of 2202. transfers are very important to the Internet to mitigate damage in
the form of theft, fraud, and other abuse. It is critical that
registrars only use strong, randomly generated authorization
information values.
Because of this, registries may validate the randomness of the
authorization information based on the length and character set
required by the registry. For example, validating an authorization
value contains a combination of upper-case, lower-case, and non-
alphanumeric characters, in an attempt to assess the strength of the
value, and return an EPP error result of 2202 if the check fails.
Such checks are, by their nature, heuristic and imperfect, and may
identify well-chosen authorization information values as being not
sufficiently strong. Registrars, therefore, must be prepared for an
error response of 2202, "Invalid authorization information", and
respond by generating a new value and trying again, possibly more
than once.
Often the registrar has the "clientTransferProhibited" status set, so Often the registrar has the "clientTransferProhibited" status set, so
to start the transfer process, the "clientTransferProhibited" status to start the transfer process, the "clientTransferProhibited" status
needs to be removed, and the strong, random authorization information needs to be removed, and the strong, random authorization information
value needs to be set. The registrar MUST define a time-to-live value needs to be set. The registrar MUST define a time-to-live
(TTL), as defined in Section 4.2, where if the TTL expires the (TTL), as defined in Section 4.2, where if the TTL expires the
registrar will unset the authorization information. registrar 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 an [RFC5731] domain name update
skipping to change at page 13, line 4 skipping to change at page 13, line 26
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C: </domain:pw> C: </domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:chg> C: </domain:chg>
C: </domain:update> C: </domain:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
When the registrar-defined TTL expires, the sponsoring registrar When the registrar-defined TTL expires, the sponsoring registrar
cancels the transfer process by unsetting the authorization cancels 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 "clientTransferProbited" status. Any EPP object extension that
supports setting the authorization information with a supports setting the authorization information with a
"eppcom:pwAuthInfoType" element, can have an empty authorization "eppcom:pwAuthInfoType" element, can have an empty authorization
information passed, such as [RFC5731] and [RFC5733]. Setting an information value passed. Examples of such extensions are [RFC5731]
empty authorization information unsets the value. [RFC5731] supports and [RFC5733]. Setting an empty authorization information value
an explicit mechanism of unsetting the authorization information, by unsets the authorization information. [RFC5731] supports an explicit
passing the <domain:null> authorization information value. The mechanism of unsetting the authorization information, by passing the
registry MUST support unsetting the authorization information by <domain:null> authorization information value. The registry MUST
accepting an empty authorization information value and accepting an support unsetting the authorization information by accepting an empty
explicit unset element if it is supported by the object extension. authorization information value and accepting an explicit unset
element if it is supported by the object extension.
Example of adding the "clientTransferProhibited" status and unsetting Example of adding the "clientTransferProhibited" status and unsetting
the authorization information explicitly in an [RFC5731] domain name the authorization information explicitly in an [RFC5731] domain name
update command. update command.
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
skipping to change at page 13, line 44 skipping to change at page 14, line 27
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 in an [RFC5731] domain name update command. authorization information value in an [RFC5731] domain name update
command.
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 25 skipping to change at page 15, line 4
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 in an [RFC5733] contact update command. authorization information value in an [RFC5733] contact update
command.
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>
skipping to change at page 15, line 8 skipping to change at page 15, line 29
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 for the passing of a
non-empty authorization information for verification. The gaining non-empty authorization information value for verification. The
registrar can pre-verify the authorization information provided by gaining registrar can pre-verify the authorization information
the registrant prior to submitting the transfer request with the use provided by the registrant prior to submitting the transfer request
of the info command. The registry compares the hash of the passed with the use of the info command. The registry compares the hash of
authorization information with the hashed authorization information the passed authorization information with the hashed authorization
value stored for the object. When the authorization information is information value stored for the object. When the authorization
not set or the passed authorization information does not match the information is not set or the passed authorization information does
previously set value, the registry MUST return an EPP error result not match the previously set value, the registry MUST return an EPP
code of 2202 [RFC5730]. error result code of 2202 [RFC5730].
Example of passing a non-empty authorization information in an Example of passing a non-empty authorization information value in an
[RFC5731] domain name info command to verify the authorization [RFC5731] domain name info command 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>
skipping to change at page 16, line 20 skipping to change at page 16, line 38
The registry MUST NOT return any indication of whether the The registry MUST NOT return any indication of whether the
authorization information is set or unset to the non-sponsoring authorization information is set or unset to the non-sponsoring
registrar by not returning the authorization information element in registrar by not returning the authorization information element in
the response. The registry MAY return an indication to the the response. The registry MAY return an indication to the
sponsoring registrar that the authorization information is set by 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 in an Example of returning an empty authorization information value in an
[RFC5731] domain name info response to indicate to the sponsoring [RFC5731] domain name info response 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>
skipping to change at page 17, line 8 skipping to change at page 17, line 33
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 for the
passing of a non-empty authorization information to authorize a passing 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 and when the
transfer is pending, the registry MUST return the EPP success result transfer is pending, the registry MUST return the EPP success result
code of 1001. The losing registrar MUST be informed of a successful code of 1001. The losing registrar MUST be informed of a successful
transfer request using an EPP poll message. transfer request using an EPP poll message.
Example of passing a non-empty authorization information in an Example of passing a non-empty authorization information value in an
[RFC5731] domain name transfer request command to authorize the [RFC5731] domain name transfer request command 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>
skipping to change at page 18, line 21 skipping to change at page 18, line 44
the starting point of the registry. Registries may have different the starting point of the registry. Registries may have different
starting points, since some of the elements of the Secure starting points, since some of the elements of the Secure
Authorization Information Model may have already been implemented. Authorization Information Model may have already been implemented.
The considerations assume a starting point, referred to as the The considerations assume a starting point, referred to as the
Classic Authorization Information Model, that have the following Classic Authorization Information Model, that have the following
steps in the management of the authorization information for steps in the management of the authorization information for
transfers: transfers:
1. Registrant requests to register the object with the registrar. 1. Registrant requests to register the object with the registrar.
Registrar sends the create command, with a non-empty Registrar sends the create command, with a non-empty
authorization information, to the registry. The registry stores authorization information value, to the registry. The registry
the authorization information as an encrypted value and requires stores the authorization information as an encrypted value and
a non-empty authorization information for the life of the object. requires a non-empty authorization information value for the life
The registrar may store the long-lived authorization information. of the object. The registrar may store the long-lived
authorization information.
2. At the time of transfer, Registrant requests from the losing 2. At the time of transfer, 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 stored authorization information 3. Losing registrar retrieves the stored authorization information
locally or queries the registry for authorization information locally 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 4. Registrant provides the authorization information value to the
gaining registrar. gaining registrar.
5. Gaining registrar optionally verifies the authorization 5. Gaining registrar optionally verifies the authorization
information with the info command to the registry, by passing the information with the info command to the registry, by passing the
skipping to change at page 19, line 5 skipping to change at page 19, line 29
passed authorization information. passed authorization information.
7. If the transfer successfully completes, the authorization 7. If the transfer successfully completes, 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 transfer
is cancelled or rejected, the losing registrar may reset the is cancelled or rejected, the losing registrar may reset the
authorization information using the update command. 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:
1. Registry requirement for a non-empty authorization information on 1. Registry requirement for a non-empty authorization information
create and for the life of the object versus the authorization value on create and for the life of the object versus the
information not being set on create and only being set when a authorization information not being set on create and only being
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 supporting the authorization to be unset in the update
command. 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 as 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
skipping to change at page 23, line 34 skipping to change at page 24, line 11
Contact: epp@centralnic.com Contact: epp@centralnic.com
URL: https://www.centralnic.com URL: https://www.centralnic.com
9. Security Considerations 9. Security Considerations
Section 4.1 defines the use a secure random value for the generation Section 4.1 defines the use a secure random value for the generation
of the authorization information. The server SHOULD define policy of the authorization information. The server SHOULD define policy
related to the length and set of characters that are included in the related to the length and set of characters that are included in the
randomization to target the desired entropy level, with the randomization to target the desired entropy level, with the
recommendation of at least 49 bits for entropy. The authorization recommendation of at least 128 bits for entropy. The authorization
information server policy is communicated to the client using an out- information server policy is communicated to the client using an out-
of-band process. The client SHOULD choose a length and set of of-band process. The client SHOULD choose a length and set of
characters that results in entropy that meets or exceeds the server characters that results in entropy that meets or exceeds the server
policy. A random number generator (RNG) is preferable over the use policy. A random number generator (RNG) is preferable over the use
of a pseudorandom number generator (PRNG) when creating the of a pseudorandom number generator (PRNG) when creating the
authorization information value. authorization information value.
Section 4.2 defines the use of an authorization information Time-To- Section 4.2 defines the use of an authorization information Time-To-
Live (TTL). The registrar SHOULD only set the authorization Live (TTL). The registrar SHOULD only set the authorization
information during the transfer process by the server support for information during the transfer process by the server support for
skipping to change at page 24, line 23 skipping to change at page 24, line 49
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 as a
NULL (undefined) value to ensure that an empty input authorization NULL (undefined) value to ensure that an empty input authorization
information never matches it. The method used to define a NULL information never matches it. The method used to define a NULL
(undefined) value is database specific. (undefined) value is database specific.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank the following persons for their feedback The authors wish to thank the following persons for their feedback
and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
Jody Kolker, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew Pozun, Srikanth
and Ulrich Wisser. Veeramachaneni, and Ulrich Wisser.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS-140-2]
National Institute of Standards and Technology, U.S.
Department of Commerce, "NIST Federal Information
Processing Standards (FIPS) Publication 140-2", May 2001,
<https://csrc.nist.gov/publications/detail/fips/140/2/
final>.
[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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
skipping to change at page 25, line 19 skipping to change at page 26, line 5
[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 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [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 11.2. Informative References
[FIPS-180-4]
National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard, NIST
Federal Information Processing Standards (FIPS)
Publication 180-4", August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/
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 Appendix A. Change History
A.1. Change from 00 to 01 A.1. Change from 00 to 01
1. Filled in the "Implementation Status" section with the inclusion 1. Filled in the "Implementation Status" section with the inclusion
of the "Verisign EPP SDK" and "RegistryEngine EPP Service" of the "Verisign EPP SDK" and "RegistryEngine EPP Service"
skipping to change at page 28, line 10 skipping to change at page 29, line 10
2. Updated Acknowledgements to match the approach taken by the RFC 2. Updated Acknowledgements to match the approach taken by the RFC
Editor with draft-ietf-regext-login-security. Editor with draft-ietf-regext-login-security.
3. Changed from Best Current Practice (BCP) to Standards Track based 3. Changed from Best Current Practice (BCP) to Standards Track based
on mailing list discussion. on mailing list discussion.
A.9. Change from REGEXT 04 to REGEXT 05 A.9. Change from REGEXT 04 to REGEXT 05
1. Fixed IDNITS issues, including moving RFC7451 to Informative 1. Fixed IDNITS issues, including moving RFC7451 to Informative
References section. References section.
Authors' Addresses 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 Barrry 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.
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: http://www.verisign.com
Richard Wilhelm Richard Wilhelm
 End of changes. 56 change blocks. 
176 lines changed or deleted 248 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/