draft-ietf-regext-secure-authinfo-transfer-00.txt   draft-ietf-regext-secure-authinfo-transfer-01.txt 
Network Working Group J. Gould Network Working Group J. Gould
Internet-Draft R. Wilhelm Internet-Draft R. Wilhelm
Intended status: Best Current Practice VeriSign, Inc. Intended status: Best Current Practice VeriSign, Inc.
Expires: August 17, 2020 February 14, 2020 Expires: October 25, 2020 April 23, 2020
Extensible Provisioning Protocol (EPP) Secure Authorization Information Extensible Provisioning Protocol (EPP) Secure Authorization Information
for Transfer for Transfer
draft-ietf-regext-secure-authinfo-transfer-00 draft-ietf-regext-secure-authinfo-transfer-01
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. 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 RFC 5731, and the EPP Contact the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
Mapping, in RFC 5733, as password-based authorization information. Mapping, in RFC 5733, 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
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 17, 2020. This Internet-Draft will expire on October 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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. Secure Authorization Information . . . . . . . . . . . . . . 6 3. Signaling Client and Server Support . . . . . . . . . . . . . 6
3.1. Secure Random Authorization Information . . . . . . . . . 6 4. Secure Authorization Information . . . . . . . . . . . . . . 7
3.2. Authorization Information Time-To-Live (TTL) . . . . . . 7 4.1. Secure Random Authorization Information . . . . . . . . . 7
3.3. Authorization Information Storage and Transport . . . . . 7 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8
3.4. Authorization Information Matching . . . . . . . . . . . 8 4.3. Authorization Information Storage and Transport . . . . . 8
4. Create, Transfer, and Secure Authorization Information . . . 8 4.4. Authorization Information Matching . . . . . . . . . . . 9
4.1. Create Command . . . . . . . . . . . . . . . . . . . . . 9 5. Create, Transfer, and Secure Authorization Information . . . 9
4.2. Update Command . . . . . . . . . . . . . . . . . . . . . 11 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10
4.3. Info Command and Response . . . . . . . . . . . . . . . . 14 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12
4.4. Transfer Request Command . . . . . . . . . . . . . . . . 15 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15
5. Transition Considerations . . . . . . . . . . . . . . . . . . 16 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 16
5.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 18 6. Transition Considerations . . . . . . . . . . . . . . . . . . 17
5.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 18 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19
5.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 19 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20
6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 20 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 22 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 24 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 26
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 6, line 9 skipping to change at page 6, line 12
operation of a zone that allows registration of names within the operation of a zone that allows registration of names within the
zone". The registry typically interfaces with the registrars zone". The registry typically interfaces with the registrars
over EPP and generally does not interact directly with the over EPP and generally does not interact directly with the
registrant. In the EPP RFCs, the registry is referred to as the registrant. In the EPP RFCs, the registry is referred to as the
"server", since EPP is the protocol used between the registrar "server", since EPP is the protocol used between the registrar
and the registry. The registry has a record of the sponsoring and the registry. The registry has a record of the sponsoring
registrar for each object and provides the mechanism (over EPP) registrar for each object and provides the mechanism (over EPP)
to coordinate a transfer of an object's sponsorship between to coordinate a transfer of an object's sponsorship between
registrars. registrars.
3. Secure Authorization Information 3. Signaling Client and Server Support
This document does not define new protocol but a Best Current
Practice (BCP) using the existing EPP protocol, where the client and
the server can signal support for the BCP using a namespace URI in
the login and greeting extension services. The namespace URI
"urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1" is used
to signal support for the BCP. The client includes the namespace URI
in an <svcExtension> <extURI> element of the [RFC5730] <login>
Command. The server includes the namespace URI in an <svcExtension>
<extURI> element of the [RFC5730] Greeting.
A client that receives the namespace URI in the server's Greeting
extension services, can expect the following supported behavior by
the server:
1. Support empty authorization information with a create command.
2. Support unsetting authorization information with an update
command.
3. Support validating authorization information with an info
command.
4. Support not returning an indication whether the authorization
information is set or unset to the non-sponsoring registrar.
5. Support returning empty authorization information to sponsoring
registrar when the authorization information is set in an info
response.
6. Support allowing for the passing of a matching non-empty
authorization information to authorize a transfer.
7. Support automatically unsetting the authorization information
upon a successful completion of transfer.
A server that receives the namespace URI in the client's <login>
Command extension services, can expect the following supported
behavior by the client:
1. Support generation of authorization information using a secure
random value.
2. Support only setting the authorization information when there is
a transfer in process.
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. Other EPP objects that support password-based
authorization information for transfer can use the Secure authorization information for transfer can use the Secure
Authorization Information defined in this document. For the Authorization Information defined in this document. For the
authorization information to be secure it must be a strong random authorization information to be secure it must be a strong random
value and must have a short time-to-live (TTL). The security of the value and must have a short time-to-live (TTL). The security of the
authorization information is defined in the following sections. authorization information is defined in the following sections.
3.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). With a target entropy of
49, the required length can be calculated after deciding on the set 49, the required length can be calculated after deciding on the set
of characters that will be randomized. The following are a set of of characters that will be randomized. The following are a set of
skipping to change at page 7, line 29 skipping to change at page 8, line 22
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 [1] SHOULD be followed to produce random (FIPS) Publication 140-2 [1] SHOULD be followed to produce random
values that will be resistant to attack. A random number generator values that will be resistant to attack. A random number generator
(RNG) is preferable over the use of a pseudorandom number generator (RNG) is preferable over the use of a pseudorandom number generator
(PRNG) to reduce the predictability of the authorization information. (PRNG) to reduce the predictability of the authorization information.
The more predictable the random number generator is, the lower the The more predictable the random number generator is, the lower the
true entropy, and the longer the required length for the true entropy, and the longer the required length for the
authorization information. authorization information.
3.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
client policy may be based on proprietary registrar-specific criteria client policy may be based on proprietary registrar-specific criteria
which provides for a transfer-specific TTL tuned for the particular which 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.
3.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. 256-bit hash function, such as SHA-256.
2. An empty authorization information MUST be stored with a NULL 2. An empty authorization information MUST be stored with a NULL
(undefined) value. (undefined) value.
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.
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
skipping to change at page 8, line 21 skipping to change at page 9, line 17
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.
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.
3.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 3.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. The unset authorization information is stored with a
NULL (undefined) value. Based on the requirement to store the 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 3.3, a set authorization information is stored as defined in Section 4.3, a set authorization information is stored
with a non-NULL hashed value. The empty authorization information is with a non-NULL hashed value. The empty authorization information is
used as input in both the create command (Section 4.1) and the update used as input in both the create command (Section 5.1) and the update
command (Section 4.2) to define the unset state. The matching of the command (Section 5.2) to define the unset state. The matching of the
authorization information in the info command (Section 4.3) and the authorization information in the info command (Section 5.3) and the
transfer request command (Section 4.4) is based on the following transfer request command (Section 5.4) is based on the following
rules: 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. 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.
4. 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 3, 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 empty authorization
information, to the registry, as defined in Section 4.1. information, 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 4.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 4.3. Section 5.3.
6. Gaining registrar sends the transfer request with the 6. Gaining registrar sends the transfer request with the
authorization information to the registry, as defined in authorization information to the registry, as defined in
Section 4.4. Section 5.4.
7. If the transfer successfully completes, the registry 7. If the transfer successfully completes, the registry
automatically unsets the authorization information; otherwise the automatically unsets the authorization information; otherwise the
losing registrar unsets the authorization information when the losing registrar unsets the authorization information when the
TTL expires, as defined in Section 4.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.
4.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 and MAY disallow for the passing of a
non-empty authorization information. By having an empty non-empty authorization information. By having an empty
authorization information on create, the object is initially not in authorization information on create, the object is initially not in
the transfer process. Any EPP object extension that supports setting the transfer process. Any EPP object extension that supports setting
the authorization information with a "eppcom:pwAuthInfoType" element, the authorization information with a "eppcom:pwAuthInfoType" element,
can have an empty authorization information passed, such as [RFC5731] can have an empty authorization information passed, such as [RFC5731]
and [RFC5733]. and [RFC5733].
skipping to change at page 11, line 5 skipping to change at page 12, line 5
C: <contact:email>jdoe@example.com</contact:email> C: <contact:email>jdoe@example.com</contact:email>
C: <contact:authInfo> C: <contact:authInfo>
C: <contact:pw/> C: <contact:pw/>
C: </contact:authInfo> C: </contact:authInfo>
C: </contact:create> C: </contact:create>
C: </create> C: </create>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
4.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 3.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 registry SHOULD validate
the randomness of the authorization information based on the length the randomness of the authorization information based on the length
and character set required by the registry. For example, a registry and character set required by the registry. For example, a registry
that requires 20 random printable ASCII characters except space that requires 20 random printable ASCII characters except space
(0x20), should validate that the authorization information contains (0x20), should validate that the authorization information contains
at least one upper case alpha character, one lower case alpha at least one upper case alpha character, one lower case alpha
character, and one non-alpha numeric character. If the authorization character, and one non-alpha numeric character. If the authorization
information fails the randomness validation, the registry MUST return information fails the randomness validation, the registry MUST return
an EPP error result code of 2202. an EPP error result code of 2202.
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 3.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
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>
skipping to change at page 14, line 5 skipping to change at page 15, line 5
C: <contact:authInfo> C: <contact:authInfo>
C: <contact:pw/> C: <contact:pw/>
C: </contact:authInfo> C: </contact:authInfo>
C: </contact:chg> C: </contact:chg>
C: </contact:update> C: </contact:update>
C: </update> C: </update>
C: <clTRID>ABC-12345-XYZ</clTRID> C: <clTRID>ABC-12345-XYZ</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
4.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 for verification. The gaining
registrar can pre-verify the authorization information provided by registrar can pre-verify the authorization information provided by
the registrant prior to submitting the transfer request with the use the registrant prior to submitting the transfer request with the use
of the info command. The registry compares the hash of the passed of the info command. The registry compares the hash of the passed
authorization information with the hashed authorization information authorization information with the hashed authorization information
value stored for the object. When the authorization information is value stored for the object. When the authorization information is
not set or the passed authorization information does not match the not set or the passed authorization information does not match the
previously set value, the registry MUST return an EPP error result previously set value, the registry MUST return an EPP error result
skipping to change at page 15, line 36 skipping to change at page 16, line 36
S: </domain:authInfo> S: </domain:authInfo>
S: </domain:infData> S: </domain:infData>
S: </resData> S: </resData>
S: <trID> S: <trID>
S: <clTRID>ABC-12345</clTRID> S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID> S: <svTRID>54322-XYZ</svTRID>
S: </trID> S: </trID>
S: </response> S: </response>
S:</epp> S:</epp>
4.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 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
skipping to change at page 16, line 28 skipping to change at page 17, line 28
C: </domain:pw> C: </domain:pw>
C: </domain:authInfo> C: </domain:authInfo>
C: </domain:transfer> C: </domain:transfer>
C: </transfer> C: </transfer>
C: <clTRID>ABC-12345</clTRID> C: <clTRID>ABC-12345</clTRID>
C: </command> C: </command>
C:</epp> C:</epp>
Upon successful completion of the transfer, the registry MUST Upon successful completion of the transfer, the registry MUST
automatically unset the authorization information. If the transfer automatically unset the authorization information. If the transfer
request is not submitted within the time-to-live (TTL) (Section 3.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 4.2. the authorization information as defined in Section 5.2.
5. 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 transtion 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
skipping to change at page 18, line 6 skipping to change at page 19, line 6
response. response.
5. Registry not touching the authorization information versus the 5. Registry not touching the authorization information versus the
registry automatically unsetting the authorization information registry automatically unsetting the authorization information
upon a successful transfer. upon a successful transfer.
6. Registry may validate a shorter authorization information value 6. Registry may validate a shorter authorization information value
using password complexity rules versus validating the randomness using password complexity rules versus validating the randomness
of a longer authorization information value that meets the of a longer authorization information value that meets the
required bits of entropy. required bits of entropy.
The transition can be handled in the three phases defined in the sub- The transition can be handled in the three phases defined in the sub-
sections Section 5.1, Section 5.2, Section 5.3. sections Section 6.1, Section 6.2, Section 6.3.
5.1. Transition Phase 1 - Features 6.1. Transition Phase 1 - Features
The goal of the "Transition Phase 1 - Features" is to implement the The goal of the "Transition Phase 1 - Features" is to implement the
needed features in EPP so that the registrar can optionally implement needed features in EPP so that the registrar can optionally implement
the Secure Authorization Information Model. The features to the Secure Authorization Information Model. The features to
implement are broken out by the command and responses below: implement are broken out by the command and responses below:
Create Command: Change the create command to make the authorization Create Command: Change the create command to make the authorization
information optional, by allowing both a non-empty value and an information optional, by allowing both a non-empty value and an
empty value. This enables a registrar to optionally create empty value. This enables a registrar to optionally create
objects without an authorization information value, as defined in objects without an authorization information value, as defined in
Section 4.1. Section 5.1.
Update Command: Change the update command to allow unsetting the Update Command: Change the update command to allow unsetting the
authorization information, as defined in Section 4.2. This authorization information, as defined in Section 5.2. This
enables the registrar to optionally unset the authorization enables the registrar to optionally unset the authorization
information when the TTL expires or when the transfer is cancelled information when the TTL expires or when the transfer is cancelled
or rejected. or rejected.
Transfer Approve Command and Transfer Auto-Approve: Change the Transfer Approve Command and Transfer Auto-Approve: Change the
transfer approve command and the transfer auto-approve to transfer approve command and the transfer auto-approve to
automatically unset the authorization information. This sets the automatically unset the authorization information. This sets the
default state of the object to not have the authorization default state of the object to not have the authorization
information set. The registrar implementing the Secure information set. The registrar implementing the Secure
Authorization Information Model will not set the authorization Authorization Information Model will not set the authorization
information for an inbound transfer and the registrar implementing information for an inbound transfer and the registrar 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 4.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.
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.
5.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 5.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 encyrpting the
authorization information. authorization information.
Supporting Comparing Against Encrypted and Hashed Authorization Supporting Comparing Against Encrypted and Hashed Authorization
Information: Information:
Change the info command and the transfer request command to be Change the info command and the transfer request command to be
able to compare a passed authorization information value with able to compare a passed authorization information value with
either a hashed or encyrpted authorization information value. either a hashed or encyrpted authorization information value.
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.
5.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.
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.
6. Implementation Status 7. IANA Considerations
7.1. XML Namespace
This document uses URNs to describe XML namespaces conforming to a
registry mechanism described in [RFC3688]. The following URI
assignment is requested of IANA:
Registration request for the secure authorization information for
transfer namespace:
URI: urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1
Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification.
7.2. EPP Extension Registry
The EPP Best Current Practice (BCP) described in this document should
be registered by the IANA in the EPP Extension Registry described in
[RFC7451]. The details of the registration are as follows:
Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
Authorization Information for Transfer"
Document status: Best Current Practice
Reference: (insert reference to RFC version of this document)
Registrant Name and Email Address: IESG, <iesg@ietf.org>
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None
8. Implementation Status
Note to RFC Editor: Please remove this section and the reference to Note to RFC Editor: Please remove this section and the reference to
RFC 7942 [RFC7942] before publication. RFC 7942 [RFC7942] before publication.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942 Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is [RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual drafts to RFCs. Please note that the listing of any individual
skipping to change at page 20, line 14 skipping to change at page 22, line 5
implementations or their features. Readers are advised to note that implementations or their features. Readers are advised to note that
other implementations may exist. other implementations may exist.
According to RFC 7942 [RFC7942], "this will allow reviewers and According to RFC 7942 [RFC7942], "this will allow reviewers and
working groups to assign due consideration to documents that have the working groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented protocols experimentation and feedback that have made the implemented protocols
more mature. It is up to the individual working groups to use this more mature. It is up to the individual working groups to use this
information as they see fit". information as they see fit".
6.1. Verisign EPP SDK 8.1. Verisign EPP SDK
Organization: Verisign Inc. Organization: Verisign Inc.
Name: Verisign EPP SDK Name: Verisign EPP SDK
Description: The Verisign EPP SDK includes both a full client Description: The Verisign EPP SDK includes both a full client
implementation and a full server stub implementation of draft-ietf- implementation and a full server stub implementation of draft-ietf-
regext-secure-authinfo-transfer. regext-secure-authinfo-transfer.
Level of maturity: Development Level of maturity: Development
Coverage: All aspects of the protocol are implemented. Coverage: All aspects of the protocol are implemented.
Licensing: GNU Lesser General Public License Licensing: GNU Lesser General Public License
Contact: jgould@verisign.com Contact: jgould@verisign.com
URL: https://www.verisign.com/en_US/channel-resources/domain- URL: https://www.verisign.com/en_US/channel-resources/domain-
registry-products/epp-sdks registry-products/epp-sdks
6.2. RegistryEngine EPP Service 8.2. RegistryEngine EPP Service
Organization: CentralNic Organization: CentralNic
Name: RegistryEngine EPP Service Name: RegistryEngine EPP Service
Description: Generic high-volume EPP service for gTLDs, ccTLDs and Description: Generic high-volume EPP service for gTLDs, ccTLDs and
SLDs SLDs
Level of maturity: Deployed in CentralNic's production environment as Level of maturity: Deployed in CentralNic's production environment as
well as two other gTLD registry systems, and two ccTLD registry well as two other gTLD registry systems, and two ccTLD registry
skipping to change at page 21, line 11 skipping to change at page 23, line 5
Coverage: Auhtorization Information is "write only" in that the Coverage: Auhtorization Information is "write only" in that the
registrars can set the Auhtorization Information, but not get the registrars can set the Auhtorization Information, but not get the
Auhtorization Information in the Info Response. Auhtorization 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
7. Security Considerations 9. Security Considerations
TBD TBD
8. 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: and suggestions:
o Michael Bauland o Michael Bauland
o Martin Casanova o Martin Casanova
o Scott Hollenbeck o Scott Hollenbeck
o Jody Kolker o Jody Kolker
o Patrick Mevzek o Patrick Mevzek
o Matthew Pozun o Matthew Pozun
o Srikanth Veeramachaneni o Srikanth Veeramachaneni
9. References 11. References
9.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<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,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
<https://www.rfc-editor.org/info/rfc5730>. <https://www.rfc-editor.org/info/rfc5730>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
skipping to change at page 22, line 14 skipping to change at page 24, line 10
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
August 2009, <https://www.rfc-editor.org/info/rfc5733>. August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Transport over TCP", STD 69, RFC 5734, Transport over TCP", STD 69, RFC 5734,
DOI 10.17487/RFC5734, August 2009, DOI 10.17487/RFC5734, August 2009,
<https://www.rfc-editor.org/info/rfc5734>. <https://www.rfc-editor.org/info/rfc5734>.
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[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>.
[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>.
9.2. URIs 11.2. URIs
[1] https://csrc.nist.gov/publications/detail/fips/140/2/final [1] https://csrc.nist.gov/publications/detail/fips/140/2/final
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"
implementations. implementations.
skipping to change at page 24, line 19 skipping to change at page 26, line 19
4. Made the capitalization of command and response references 4. Made the capitalization of command and response references
consistent by uppercasing section and item titles and lowercasing consistent by uppercasing section and item titles and lowercasing
references elsewhere. references elsewhere.
A.4. Change from 03 to REGEXT 00 A.4. Change from 03 to REGEXT 00
1. Changed to regext working group draft by changing draft-gould- 1. Changed to regext working group draft by changing draft-gould-
regext-secure-authinfo-transfer to draft-ietf-regext-secure- regext-secure-authinfo-transfer to draft-ietf-regext-secure-
authinfo-transfer. authinfo-transfer.
A.5. Change from REGEXT 00 to REGEXT 01
1. Added the "Signaling Client and Server Support" section to
describe the mechanism to signal support for the BCP by the
client and the server.
2. Added the "IANA Considerations" section with the registration of
the secure authorization for transfer XML namespace and the
registration of the EPP Best Current Practice (BCP) in the EPP
Extension Registry.
Authors' Addresses Authors' Addresses
James Gould James Gould
VeriSign, Inc. VeriSign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US US
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisign.com URI: http://www.verisign.com
 End of changes. 49 change blocks. 
75 lines changed or deleted 177 lines changed or added

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