draft-ietf-regext-secure-authinfo-transfer-06.txt   draft-ietf-regext-secure-authinfo-transfer-07.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: 9 September 2021 8 March 2021 Expires: 30 December 2021 28 June 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-06 draft-ietf-regext-secure-authinfo-transfer-07
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. Object- use of authorization information to authorize a transfer of an EPP
specific, password-based authorization information (see RFC 5731 and object, such as a domain name, between clients that are referred to
RFC 5733) is commonly used, but raises issues related to the as registrars. Object-specific, password-based authorization
security, complexity, storage, and lifetime of authentication information (see RFC 5731 and RFC 5733) is commonly used, but raises
information. This document defines an operational practice, using issues related to the security, complexity, storage, and lifetime of
the EPP RFCs, that leverages the use of strong random authorization authentication information. This document defines an operational
information values that are short-lived, not stored by the client, practice, using the EPP RFCs, that leverages the use of strong random
and stored by the server using a cryptographic hash that provides for authorization information values that are short-lived, not stored by
secure authorization information that can safely be used for object the client, and stored by the server using a cryptographic hash that
transfers. provides for secure authorization information that can safely be used
for object 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 9 September 2021. This Internet-Draft will expire on 30 December 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 25 skipping to change at page 2, line 25
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 . . . . . 8 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 . . . 9 5. Create, Transfer, and Secure Authorization Information . . . 10
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 . . . . . . . . . . . . . . 20 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 20
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . 22 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 22
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28
A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28
A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28
A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28
A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 29 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 28
A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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), in [RFC5730], defines the
use of authorization information to authorize a transfer. The use of authorization information to authorize a transfer of an EPP
authorization information is object-specific and has been defined in object, such as a domain name, between clients that are referred to
the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact as registrars. The authorization information is object-specific and
Mapping, in [RFC5733], as password-based authorization information. has been defined in the EPP Domain Name Mapping, in [RFC5731], and
Other authorization mechanisms can be used, but in practice the the EPP Contact Mapping, in [RFC5733], as password-based
password-based authorization information has been used at the time of authorization information. Other authorization mechanisms can be
object create, managed with the object update, and used to authorize used, but in practice the password-based authorization information
an object transfer request. What has not been considered is the has been used at the time of object create, managed with the object
security of the authorization information that includes the update, and used to authorize an object transfer request. What has
complexity of the authorization information, the time-to-live (TTL) not been considered is the security of the authorization information
of the authorization information, and where and how the authorization that includes the complexity of the authorization information, the
information is stored. time-to-live (TTL) of the authorization information, and where and
how the authorization information is stored.
The current/original lifecycle for authorization information involves
long-term storage of encrypted (not hashed) passwords, which presents
a significant latent risk of password compromise and is not
consistent with current best practices. The mechanisms in this
document provide a way to avoid long-term password storage entirely,
and to only require the storage of hashed (not retrievable) passwords
instead of encrypted passwords.
This document defines an operational practice, using the EPP RFCs, 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, that are not stored by the client, and
that are stored by the server using a cryptographic hash to provide, that are stored by the server using a cryptographic hash to provide
for secure authorization information used for transfers. This secure authorization information used for transfers. This
operational practice can be used to support transfers of any EPP operational practice can be used to support transfers of any EPP
object, where the domain name object defined in [RFC5731] is used in object, where the domain name object defined in [RFC5731] is used in
this document for illustration purposes. Elements of the practice this document for illustration purposes. Elements of the practice
may be used to support the secure use of the authorization may be used to support the secure use of the authorization
information for purposes other than transfer, but any other purposes information for purposes other than transfer, but any other purposes
and the applicable elements are out-of-scope for this document. 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.
skipping to change at page 4, line 6 skipping to change at page 4, line 14
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
following are the elements of the operational practice and how the following are the elements of the operational practice and how the
existing features of the EPP RFCs can be leveraged to satisfy them: existing features of 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 way. This operational practice defines the be used in any substantial way. This operational practice
recommended mechanism for creating a strong random authorization defines the recommended mechanism for creating a strong random
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 "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. All of these features are compatible
only when there is a transfer in process, the server needs to with the EPP RFCs, though not mandatory to implement. In section
support an empty authorization information value on create, 2.6 of [RFC5731] it states that authorization information is
support setting and unsetting authorization information, and assigned when a domain object is created, which results in long-
support automatically unsetting the authorization information lived authorization information. This specification changes the
upon a successful transfer. All of these features can be nature of the authorization information to be short-lived. If
supported by the EPP RFCs. authorization information is set only when there is a transfer in
process, the server needs to support an empty authorization
information value on create, support setting and unsetting
authorization information, and support automatically unsetting
the authorization information upon a successful transfer. All of
these features can be supported by the EPP RFCs.
"Storing Authorization Information Securely": The EPP RFCs don't "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 require the client to
to store the authorization information and will require the not 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
SHA-256 [FIPS-180-4], and with a random salt. Returning the as SHA-256 [FIPS-180-4], and with a per-authorization information
authorization information set in an EPP info response will not be random salt, with at least 128 bits. Returning the authorization
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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 is case sensitive. Unless stated otherwise, XML specifications
skipping to change at page 6, line 33 skipping to change at page 6, line 43
server can signal support for the operational practice using a server can signal support for the operational practice using a
namespace URI in the login and greeting extension services. The 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 [RFC5730] <login> Command. The server includes the
namespace URI in an <svcExtension> <extURI> element of the [RFC5730] namespace URI in an <svcExtension> <extURI> element of the [RFC5730]
Greeting. 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
the server: server:
1. Support an empty authorization information value with a create 1. Support an empty authorization information value with a create
command. 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 an empty authorization information value to the 5. Support returning an empty authorization information value to the
sponsoring registrar when the authorization information is set in sponsoring registrar when the authorization information is set in
an info 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 value 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.
skipping to change at page 7, line 22 skipping to change at page 7, line 32
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 ([RFC5731] with the <domain:pw> element and [RFC5733] information ([RFC5731] with the <domain:pw> element and [RFC5733]
with the <contact:pw> element). Other EPP objects that support with the <contact:pw> element). Other EPP objects that support
password-based authorization information for transfer can use the password-based authorization information for transfer can use the
Secure Authorization Information defined in this document. For the Secure Authorization Information defined in this document. For the
authorization information to be secure it must be generated using a authorization information to be secure, it must be generated using a
strong random value and have a short time-to-live (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, where according to [RFC4086] a high-security treated as a password, and the required length L of a password,
password must have at least 49 bits of randomness or entropy. The rounded up to the largest whole number, is based on the size N of the
required length L of a password, rounded up to the largest whole set of characters and the desired entropy H, in the equation L =
number, is based on the set of characters N and the desired entropy ROUNDUP(H / log2 N). Given a target entropy, the required length can
H, in the equation L = ROUNDUP(H / log2 N). Given a target entropy, be calculated after deciding on the set of characters that will be
the required length can be calculated after deciding on the set of randomized. In accordance with current best practices and noting
characters that will be randomized. that the authorization information is a machine-generated value, the
implementation SHOULD use at least 128 bits of entropy as the value
Considering the age of [RFC4086], the evolution of security of H. The lengths below are calculated using that value.
practices, and that the authorization information is a machine-
generated value, the implementation SHOULD use at least 128 bits of
entropy. The lengths are calculated below 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 / 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 random number generator. Suitably strong random number
the random number generator, the practices defined in [RFC4086] and generators are available in a wide variety of implementation
section 4.7.1 of the NIST Federal Information Processing Standards environments, including the interfaces listed in Sections 7.1.2 and
(FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to produce 7.1.3 of [RFC4086]. In environments that do not provide interfaces
random values that will be resistant to attack. A random number to strong random number generators, the practices defined in
generator (RNG) is preferable over the use of a pseudorandom number [RFC4086] and section 4.7.1 of the NIST Federal Information
generator (PRNG) to reduce the predictability of the authorization Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be
information. The more predictable the random number generator is, followed to produce random values that will be resistant to attack.
the lower the true 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, the sponsoring
sponsoring registrar can apply a TTL based on client policy. The TTL registrar can apply a TTL based on client policy. The TTL client
client policy may be based on proprietary registrar-specific criteria policy may be based on proprietary registrar-specific criteria, which
which provides for a transfer-specific TTL tuned for the particular provides for a transfer-specific TTL tuned for the particular
circumstances of the transaction. The sponsoring registrar will be circumstances of the transaction. The sponsoring registrar will be
aware of the TTL and the sponsoring registrar MUST inform the aware of the TTL and the sponsoring registrar MUST inform the
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 [FIPS-180-4], and with a 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a
random salt. per-authorization information random salt, with at least 128
bits.
2. Empty authorization information MUST be stored as an undefined 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 a 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, 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, 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
skipping to change at page 9, line 32 skipping to change at page 9, line 41
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 defined 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 is used as input in both the create command (Section 5.1)
and the update command (Section 5.2) to define the unset state. The and the update command (Section 5.2) to define the unset state. The
matching of the authorization information in the info command matching of the authorization information in the info command
(Section 5.3) and the transfer request command (Section 5.4) is based (Section 5.3) and the transfer request command (Section 5.4) is based
on the following 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. This includes empty
authorization information, such as <domain:null/> or <domain:pw/>
in [RFC5731], and non-empty authorization information, such as
<domain:pw>2fooBAR</domain:pw> in [RFC5731].
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 make the transfer process secure using secure authorization To secure the transfer process 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 an empty authorization Registrar sends the create command, with an empty authorization
information value, to the registry, as defined in Section 5.1. information value, to the registry, as defined in Section 5.1.
skipping to change at page 10, line 35 skipping to change at page 10, line 48
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 value and MAY disallow for the empty authorization information value and MAY disallow for the
passing of a non-empty authorization information value. By having an passing of a non-empty authorization information value. By having an
empty authorization information value on create, the object is empty authorization information value on create, the object is
initially not in the transfer process. Any EPP object extension that initially not in the transfer process. 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 value passed. Examples of such extensions are [RFC5731] information value passed. Examples of such extensions are [RFC5731]
and [RFC5733]. and [RFC5733].
Example of passing an empty authorization information value in an Example of passing an empty authorization information value in an
[RFC5731] 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 an empty authorization information value in an Example of passing an empty authorization information value in an
[RFC5733] 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.
For an update command, the registry MUST allow for the setting and
unsetting of the authorization information. The registrar sets the
authorization information by first generating a strong, random
authorization information value, based on Section 4.1, and setting it
in the registry in the update command. The importance of generating in the registry in the update command. The importance of generating
strong authorization information values cannot be overstated: secure strong authorization information values cannot be overstated: secure
transfers are very important to the Internet to mitigate damage in transfers are very important to the Internet to mitigate damage in
the form of theft, fraud, and other abuse. It is critical that the form of theft, fraud, and other abuse. It is critical that
registrars only use strong, randomly generated authorization registrars only use strong, randomly generated authorization
information values. 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 an authorization
skipping to change at page 12, line 38 skipping to change at page 12, line 32
alphanumeric characters, in an attempt to assess the strength of the alphanumeric characters, in an attempt to assess the strength of the
value, and return an EPP error result of 2202 if the check fails. value, and return an EPP error result of 2202 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, "Invalid authorization information", and
respond by generating a new value and trying again, possibly more respond by generating a new value and trying again, possibly more
than once. than once.
Often the registrar has the "clientTransferProhibited" status set, so Often, the registrar has the "clientTransferProhibited" status set,
to start the transfer process, the "clientTransferProhibited" status so to start the transfer process, the "clientTransferProhibited"
needs to be removed, and the strong, random authorization information status needs to be removed, and the strong, random authorization
value needs to be set. The registrar MUST define a time-to-live information value needs to be set. The registrar MUST define a time-
(TTL), as defined in Section 4.2, where if the TTL expires the to-live (TTL), as defined in Section 4.2, where if the TTL expires
registrar will unset the authorization information. the 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
command. 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:rem> C: <domain:rem>
C: <domain:status s="clientTransferProhibited"/> C: <domain:status s="clientTransferProhibited"/>
skipping to change at page 13, line 27 skipping to change at page 13, line 27
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 MUST
cancels 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 "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 value passed. Examples of such extensions are [RFC5731] information value passed. Examples of such extensions are [RFC5731]
and [RFC5733]. Setting an empty authorization information value and [RFC5733]. Setting an empty authorization information value
unsets the authorization information. [RFC5731] supports an explicit unsets the authorization information. [RFC5731] supports an explicit
mechanism of unsetting the authorization information, by passing the mechanism of unsetting the authorization information, by passing the
<domain:null> authorization information value. The registry MUST <domain:null> authorization information value. The registry MUST
support unsetting the authorization information by accepting an empty support unsetting the authorization information by accepting an empty
authorization information value and accepting an explicit unset authorization information value and accepting an explicit unset
element if it is supported by the object extension. 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
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 28 skipping to change at page 14, line 28
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 an [RFC5731] domain name update
command. 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 15, line 6 skipping to change at page 15, line 6
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 an [RFC5733] contact update
command. 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 41 skipping to change at page 15, line 41
provided by the registrant prior to submitting the transfer request provided by the registrant prior to submitting the transfer request
with the use of the info command. The registry compares the hash of with the use of the info command. The registry compares the hash of
the passed authorization information with the hashed authorization the passed authorization information with the hashed authorization
information value stored for the object. When the authorization information value stored for the object. When the authorization
information is not set or the passed authorization information does information is not set or the passed authorization information does
not match the previously set value, the registry MUST return an EPP not match the previously set value, the registry MUST return an EPP
error result code of 2202 [RFC5730]. error result 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 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>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
skipping to change at page 16, line 40 skipping to change at page 16, line 40
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 value 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>
S: <domain:infData S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
skipping to change at page 17, line 48 skipping to change at page 17, line 48
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 value 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>
C: <domain:authInfo> C: <domain:authInfo>
C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
skipping to change at page 18, line 33 skipping to change at page 18, line 33
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 time-to-live (TTL) (Section 4.2)
or the transfer is cancelled or rejected, the registrar MUST unset or the transfer is cancelled or rejected, the registrar MUST unset
the authorization information as defined in Section 5.2. the authorization information as defined 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 to the practice defined in
this document, referred to as the Secure Authorization Information this document, referred to as the Secure Authorization Information
Model, is to minimize the impact to the registrars by supporting Model, is to minimize the impact to the registrars by supporting
incremental steps of adoption. The transtion steps are dependent on incremental steps of adoption. The transition steps are dependent on
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 value, to the registry. The registry authorization information value, to the registry. The registry
stores the authorization information as an encrypted value and stores the authorization information as an encrypted value and
requires a non-empty authorization information value for the life requires a non-empty authorization information value for the life
of the object. The registrar may store the long-lived of the object. The registrar may store the long-lived
authorization information. 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 locally stored authorization
locally 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 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
authorization information in the info command to the registry. authorization information in the info command to the registry.
6. Gaining registrar sends the transfer request with the 6. Gaining registrar sends the transfer request with the
skipping to change at page 20, line 36 skipping to change at page 20, line 36
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 implementing
the Classic Authorization Information Model will set the new the Classic Authorization Information Model will set the new
authorization information upon the successful transfer. authorization information upon the successful transfer.
Info Response: Change the info command to not return the Info Response: Change the info command to not return the
authorization information in the info response, as defined in authorization information in the info response, as defined 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", since the dependency in returning the authorization
information in the info response will be removed. This feature is information in the info response will be removed. This feature is
the only one that is not an optional change to the registrar. the only one that is not an optional change to the registrar that
has the potential of breaking the client, so it's recommended that
the registry provide notice of the change.
Info Command and Transfer Request: Change the info command and the Info Command and Transfer Request: Change the info command and the
transfer request to ensure that a registrar cannot get an 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 the "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 to 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 by not returning the set authorization
information in the info response, which is addressed in Transition information in the info response, which is addressed in Transition
Phase 1 - Features (Section 6.1). There are three steps to Phase 1 - Features (Section 6.1). There are three steps to
transition the authorization information storage, which includes: transition the authorization information storage, which includes:
Hash New Authorization Information Values: Change the create command Hash New Authorization Information Values: Change the create command
and the update command to hash instead of encyrpting the and the update command to hash instead of encrypting the
authorization information. authorization information.
Supporting Comparing Against Encrypted and Hashed Authorization Supporting Comparing Against Encrypted and Hashed Authorization
Information: Change the info command and the transfer request 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 encyrpted authorization information value with either a hashed or encrypted authorization information
value. value. This requires that the stored values are self-identifying
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. The update is not a visible
change to the registrar. The conversion can be done over a period change to the registrar. The conversion can be done over a period
of time depending on registry policy. 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 the "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 for the passing of a non-empty
authorization information value. authorization information value. This behavior has the potential
of breaking the client, so it's recommended that the registry
provide notice of the 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 command
to ensure at least 128 bits of entropy. 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 a
registry mechanism described in [RFC3688]. The following URI registry mechanism described in [RFC3688]. The following URI
skipping to change at page 23, line 49 skipping to change at page 24, line 4
well as two other gTLD registry systems, and two ccTLD registry well as two other gTLD registry systems, and two ccTLD registry
systems. systems.
Coverage: Authorization Information is "write only" in that the Coverage: Authorization Information is "write only" in that the
registrars can set the Authorization Information, but not get the registrars can set the Authorization Information, but not get the
Authorization Information in the Info Response. Authorization Information in the Info Response.
Licensing: Proprietary In-House software Licensing: Proprietary In-House software
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 client SHOULD choose a length
related to the length and set of characters that are included in the and set of characters that results in at least 128 bits of entropy.
randomization to target the desired entropy level, with the
recommendation of at least 128 bits for entropy. The authorization
information server policy is communicated to the client using an out-
of-band process. The client SHOULD choose a length and set of
characters that results in entropy that meets or exceeds the server
policy. A random number generator (RNG) is preferable over the use
of a pseudorandom number generator (PRNG) when creating the
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
setting and unsetting the authorization information. The TTL value setting and unsetting the authorization information. The TTL value
is up to registrar policy and the sponsoring registrar MUST inform is 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 random salt. All communication that least 256 bits and with a per-authorization information random salt,
includes the authorization information MUST be over an encrypted with at least 128 bits. All communication that includes the
channel. The plain text authorization information MUST NOT be authorization information MUST be over an encrypted channel. The
written to any logs by the registrar or the registry. plain text authorization information MUST NOT be written to any logs
by the registrar or the registry.
Section 4.4 defines the matching of the authorization information 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, Barry Leiba, Patrick Mevzek, Matthew Pozun, Srikanth Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew
Veeramachaneni, and Ulrich Wisser. Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.
11. References 11. References
11.1. Normative References
[FIPS-140-2] 11.1. Normative References
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>.
skipping to change at page 26, line 15 skipping to change at page 26, line 5
[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 11.2. Informative References
[FIPS-140-2]
National Institute of Standards and Technology, U.S.
Department of Commerce, "NIST Federal Information
Processing Standards (FIPS) Publication 140-2", May 2001,
<https://csrc.nist.gov/publications/detail/fips/140/2/
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", 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,
skipping to change at page 29, line 43 skipping to change at page 29, line 40
10. In section 4.4, revised the language associated with the storage 10. In section 4.4, revised the language associated with the storage
of the authorization information to be cleaner. of the authorization information to be cleaner.
11. In section 4.4, added "set" in the sentence "An empty input 11. In section 4.4, added "set" in the sentence "An empty input
authorization information value MUST NOT match any set authorization information value MUST NOT match any set
authorization information value." authorization information value."
12. In section 5.1 and 5.2, clarified the references to RFC5731 and 12. In section 5.1 and 5.2, clarified the references to RFC5731 and
RFC5733 as examples of object extensions that use the RFC5733 as examples of object extensions that use the
"eppcom:pwAuthInfoType" element. "eppcom:pwAuthInfoType" element.
13. In section 5.2, updated language for the validation of the 13. In section 5.2, updated language for the validation of the
randomness of the authorization information, based on an offline randomness of the authorization information, based on an offline
review by Barrry Leiba, Benjamin Kaduk, and Roman Danyliw. review by Barry Leiba, Benjamin Kaduk, and Roman Danyliw.
14. In section 9, changed "49 bits of entropy" to "128 bits of 14. In section 9, changed "49 bits of entropy" to "128 bits of
entropy". entropy".
In section 3, replaced the reference to BCP with operational In section 3, replaced the reference to BCP with operational
practice, since the draft is not defined as a BCP. 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
Information" in Section 1 to reference section 2.6 of
RFC5731 and change in nature of the authorization
information.
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: http://www.verisign.com
 End of changes. 54 change blocks. 
142 lines changed or deleted 243 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/