draft-ietf-regext-secure-authinfo-transfer-03.txt   draft-ietf-regext-secure-authinfo-transfer-04.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: Standards Track VeriSign, Inc.
Expires: February 1, 2021 July 31, 2020 Expires: 24 April 2021 21 October 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-03 draft-ietf-regext-secure-authinfo-transfer-04
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 February 1, 2021. This Internet-Draft will expire on 24 April 2021.
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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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. 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 . . . . . 9
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 . . . . . . . . . . . . . . . . 16 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17
6. Transition Considerations . . . . . . . . . . . . . . . . . . 17 6. Transition Considerations . . . . . . . . . . . . . . . . . . 18
6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 20
6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Normative References . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27
A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27
A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 18 skipping to change at page 6, line 21
over EPP and generally does not interact directly with the over EPP and generally does not interact directly with the
registrant. In the EPP RFCs, the registry is referred to as the registrant. In the EPP RFCs, the registry is referred to as the
"server", since EPP is the protocol used between the registrar "server", since EPP is the protocol used between the registrar
and the registry. The registry has a record of the sponsoring and the registry. The registry has a record of the sponsoring
registrar for each object and provides the mechanism (over EPP) registrar for each object and provides the mechanism (over EPP)
to coordinate a transfer of an object's sponsorship between to coordinate a transfer of an object's sponsorship between
registrars. registrars.
3. Signaling Client and Server Support 3. Signaling Client and Server Support
This document does not define new protocol but a Best Current This document does not define new protocol but an operational
Practice (BCP) using the existing EPP protocol, where the client and practice using the existing EPP protocol, where the client and the
the server can signal support for the BCP using a namespace URI in server can signal support for the BCP using a namespace URI in the
the login and greeting extension services. The namespace URI login and greeting extension services. The namespace URI
"urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to
signal support for the BCP. The client includes the namespace URI in signal support for the BCP. The client includes the namespace URI in
an <svcExtension> <extURI> element of the [RFC5730] <login> Command. an <svcExtension> <extURI> element of the [RFC5730] <login> Command.
The server includes the namespace URI in an <svcExtension> <extURI> The server includes the namespace URI in an <svcExtension> <extURI>
element of the [RFC5730] Greeting. element of the [RFC5730] Greeting.
A client that receives the namespace URI in the server's Greeting A client that receives the namespace URI in the server's Greeting
extension services, can expect the following supported behavior by extension services, can expect the following supported behavior by
the server: the server:
skipping to change at page 8, line 21 skipping to change at page 8, line 26
Calculation of the required length with 128 bits of entropy and with Calculation of the required length with 128 bits of entropy and with
the set of case insensitive alphanumeric characters, which consists the set of case insensitive alphanumeric characters, which consists
of 36 characters (a-z A-Z 0-9). of 36 characters (a-z A-Z 0-9).
ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
The strength of the random authorization information is dependent on The strength of the random authorization information is dependent on
the actual entropy of the underlying random number generator. For the actual entropy of the underlying random number generator. For
the random number generator, the practices defined in [RFC4086] and the random number generator, the practices defined in [RFC4086] and
section 4.7.1 of the NIST Federal Information Processing Standards section 4.7.1 of the NIST Federal Information Processing Standards
(FIPS) Publication 140-2 [1] SHOULD be followed to produce random (FIPS) Publication 140-2
values that will be resistant to attack. A random number generator (https://csrc.nist.gov/publications/detail/fips/140/2/final) SHOULD
(RNG) is preferable over the use of a pseudorandom number generator be followed to produce random values that will be resistant to
(PRNG) to reduce the predictability of the authorization information. attack. A random number generator (RNG) is preferable over the use
The more predictable the random number generator is, the lower the of a pseudorandom number generator (PRNG) to reduce the
true entropy, and the longer the required length for the predictability of the authorization information. The more
authorization information. predictable the random number generator is, 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, then the
sponsoring registrar can apply a TTL based on client policy. The TTL sponsoring registrar can apply a TTL based on client policy. The TTL
skipping to change at page 20, line 13 skipping to change at page 20, line 40
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 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
Change the info command and the transfer request command to be command to be able to compare a passed authorization information
able to compare a passed authorization information value with value with either a hashed or encyrpted authorization information
either a hashed or encyrpted authorization information value. 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.
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
skipping to change at page 21, line 7 skipping to change at page 21, line 35
Registration request for the secure authorization information for Registration request for the secure authorization information for
transfer namespace: transfer namespace:
URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
Registrant Contact: IESG Registrant Contact: IESG
XML: None. Namespace URIs do not represent an XML specification. XML: None. Namespace URIs do not represent an XML specification.
7.2. EPP Extension Registry 7.2. EPP Extension Registry
The EPP Best Current Practice (BCP) described in this document should The EPP operational practice described in this document should be
be registered by the IANA in the EPP Extension Registry described in registered by the IANA in the EPP Extension Registry described in
[RFC7451]. The details of the registration are as follows: [RFC7451]. The details of the registration are as follows:
Name of Extension: "Extensible Provisioning Protocol (EPP) Secure Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
Authorization Information for Transfer" Authorization Information for Transfer"
Document status: Best Current Practice Document status: Standards Track
Reference: (insert reference to RFC version of this document) Reference: (insert reference to RFC version of this document)
Registrant Name and Email Address: IESG, <iesg@ietf.org> Registrant Name and Email Address: IESG, <iesg@ietf.org>
TLDs: Any TLDs: Any
IPR Disclosure: None IPR Disclosure: None
Status: Active Status: Active
skipping to change at page 23, line 48 skipping to change at page 24, line 22
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: and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
Jody Kolker, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni,
o Michael Bauland and Ulrich Wisser.
o Martin Casanova
o Scott Hollenbeck
o Jody Kolker
o Patrick Mevzek
o Matthew Pozun
o Srikanth Veeramachaneni
o Ulrich Wisser
11. References
11.1. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 25, line 14 skipping to change at page 25, line 27
[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>.
11.2. URIs
[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.
2. Made small wording corrections based on private feedback. 2. Made small wording corrections based on private feedback.
3. Added content to the "Acknowledgements" section. 3. Added content to the "Acknowledgements" section.
skipping to change at page 27, line 39 skipping to change at page 27, line 45
A.7. Change from REGEXT 02 to REGEXT 03 A.7. Change from REGEXT 02 to REGEXT 03
1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure- 1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure-
authinfo-transfer-1.0, which removed bcp from the namespace and authinfo-transfer-1.0, which removed bcp from the namespace and
bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML
namespace was discussed at the REGEXT interim meeting. namespace was discussed at the REGEXT interim meeting.
2. Replaced Auhtorization with Authorization based on a review by 2. Replaced Auhtorization with Authorization based on a review by
Jody Kolker. Jody Kolker.
A.8. Change from REGEXT 03 to REGEXT 04
1. Converted from xml2rfc v2 to v3.
2. Updated Acknowledgements to match the approach taken by the RFC
Editor with draft-ietf-regext-login-security.
3. Changed from Best Current Practice (BCP) to Standards Track based
on mailing list discussion.
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 United States of America
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisign.com URI: http://www.verisign.com
Richard Wilhelm Richard Wilhelm
VeriSign, Inc. VeriSign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
US United States of America
Email: rwilhelm@verisign.com Email: rwilhelm@verisign.com
URI: http://www.verisign.com URI: http://www.verisign.com
 End of changes. 24 change blocks. 
66 lines changed or deleted 62 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/