draft-ietf-regext-secure-authinfo-transfer-02.txt   draft-ietf-regext-secure-authinfo-transfer-03.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: December 14, 2020 June 12, 2020 Expires: February 1, 2021 July 31, 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-02 draft-ietf-regext-secure-authinfo-transfer-03
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 December 14, 2020. This Internet-Draft will expire on February 1, 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/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 3, line 9 skipping to change at page 3, line 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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
skipping to change at page 6, line 18 skipping to change at page 6, line 22
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 a Best Current
Practice (BCP) using the existing EPP protocol, where the client and 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 server can signal support for the BCP using a namespace URI in
the login and greeting extension services. The namespace URI the login and greeting extension services. The namespace URI
"urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1" is used "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to
to signal support for the BCP. The client includes the namespace URI signal support for the BCP. The client includes the namespace URI in
in an <svcExtension> <extURI> element of the [RFC5730] <login> an <svcExtension> <extURI> element of the [RFC5730] <login> Command.
Command. The server includes the namespace URI in an <svcExtension> The server includes the namespace URI in an <svcExtension> <extURI>
<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:
1. Support empty authorization information with a create command. 1. Support empty authorization information with a create command.
2. Support unsetting authorization information with an update 2. Support unsetting authorization information with an update
command. command.
3. Support validating authorization information with an info 3. Support validating authorization information with an info
command. command.
skipping to change at page 20, line 47 skipping to change at page 20, line 47
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
assignment is requested of IANA: assignment is requested of IANA:
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:bcp:secure-authinfo-transfer-0.1 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 Best Current Practice (BCP) described in this document should
be registered by the IANA in the EPP Extension Registry described in be 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
skipping to change at page 22, line 39 skipping to change at page 22, line 39
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
systems. systems.
Coverage: Auhtorization Information is "write only" in that the Coverage: Authorization Information is "write only" in that the
registrars can set the Auhtorization Information, but not get the registrars can set the Authorization Information, but not get the
Auhtorization 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
skipping to change at page 27, line 30 skipping to change at page 27, line 30
A.6. Change from REGEXT 01 to REGEXT 02 A.6. Change from REGEXT 01 to REGEXT 02
1. Added inclusion of random salt for the hashed authorization 1. Added inclusion of random salt for the hashed authorization
information, based on feedback from Ulrich Wisser. information, based on feedback from Ulrich Wisser.
2. Added clarification that the representation of a NULL (undefined) 2. Added clarification that the representation of a NULL (undefined)
value is dependent on the type of database, based on feedback value is dependent on the type of database, based on feedback
from Patrick Mevzek. from Patrick Mevzek.
3. Filled in the Security Considerations section. 3. Filled in the Security Considerations section.
A.7. Change from REGEXT 02 to REGEXT 03
1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure-
authinfo-transfer-1.0, which removed bcp from the namespace and
bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML
namespace was discussed at the REGEXT interim meeting.
2. Replaced Auhtorization with Authorization based on a review by
Jody Kolker.
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. 8 change blocks. 
12 lines changed or deleted 22 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/