draft-ietf-regext-secure-authinfo-transfer-04.txt   draft-ietf-regext-secure-authinfo-transfer-05.txt 
Network Working Group J. Gould Network Working Group J. Gould
Internet-Draft R. Wilhelm Internet-Draft R. Wilhelm
Intended status: Standards Track VeriSign, Inc. Intended status: Standards Track VeriSign, Inc.
Expires: 24 April 2021 21 October 2020 Expires: 8 July 2021 4 January 2021
Extensible Provisioning Protocol (EPP) Secure Authorization Information Extensible Provisioning Protocol (EPP) Secure Authorization Information
for Transfer for Transfer
draft-ietf-regext-secure-authinfo-transfer-04 draft-ietf-regext-secure-authinfo-transfer-05
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 24 April 2021. This Internet-Draft will expire on 8 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
skipping to change at page 2, line 47 skipping to change at page 2, line 47
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 20 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 20
6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
11. Normative References . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 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
A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 27 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 27
A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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
skipping to change at page 24, line 26 skipping to change at page 24, line 26
information never matches it. The method used to define a NULL information never matches it. The method used to define a NULL
(undefined) value is database specific. (undefined) value is database specific.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank the following persons for their feedback The authors wish to thank the following persons for their feedback
and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
Jody Kolker, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni, Jody Kolker, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni,
and Ulrich Wisser. and Ulrich Wisser.
11. Normative References 11. 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, [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 14
[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>.
11.2. Informative References
[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>.
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 26, line 20 skipping to change at page 26, line 20
practice can be used for purposes other than transfer, but practice can be used for purposes other than transfer, but
with a caveat. with a caveat.
2. Updates based on the review by Michael Bauland, that include: 2. Updates based on the review by Michael Bauland, that include:
1. In section 2, change 'there are three actors' to 'there are 1. In section 2, change 'there are three actors' to 'there are
three types of actors' to cover the case with transfers that three types of actors' to cover the case with transfers that
has two registrar actors (losing and gaining). has two registrar actors (losing and gaining).
2. In section 3.1, change the equations equals to be 2. In section 3.1, change the equations equals to be
approximately equal by using '=~' instead of '=', where approximately equal by using '=~' instead of '=', where
applicable. applicable.
3. In section 3.3, change 'MUST be over an encrypted channel, 3. In section 3.3, change 'MUST be over an encrypted channel,
such as [RFC5734]'' to 'MUST be over an encrypted channel, such as RFC5734' to 'MUST be over an encrypted channel, such
such as defined in [RFC5734]''. as defined in RFC5734'.
4. In section 4.1, remove the optional RFC 5733 elements from 4. In section 4.1, remove the optional RFC 5733 elements from
the contact create, which includes the <contact:voice>, the contact create, which includes the <contact:voice>,
<contact:fax>, <contact:disclose>, <contact:org>, <contact:fax>, <contact:disclose>, <contact:org>,
<contact:street>, <contact:sp>, and <contact:cc> elements. <contact:street>, <contact:sp>, and <contact:cc> elements.
5. In section 4.2, changed 'Example of unsetting the 5. In section 4.2, changed 'Example of unsetting the
authorization information explicitly in an [RFC5731] domain authorization information explicitly in an [RFC5731] domain
name update command.' to 'Example of adding the name update command.' to 'Example of adding the
"clientTransferProhibited" status and unsetting the "clientTransferProhibited" status and unsetting the
authorization information explicitly in an [RFC5731] domain authorization information explicitly in an [RFC5731] domain
name update command.' name update command.'
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Jody Kolker. Jody Kolker.
A.8. Change from REGEXT 03 to REGEXT 04 A.8. Change from REGEXT 03 to REGEXT 04
1. Converted from xml2rfc v2 to v3. 1. Converted from xml2rfc v2 to v3.
2. Updated Acknowledgements to match the approach taken by the RFC 2. Updated Acknowledgements to match the approach taken by the RFC
Editor with draft-ietf-regext-login-security. Editor with draft-ietf-regext-login-security.
3. Changed from Best Current Practice (BCP) to Standards Track based 3. Changed from Best Current Practice (BCP) to Standards Track based
on mailing list discussion. on mailing list discussion.
A.9. Change from REGEXT 04 to REGEXT 05
1. Fixed IDNITS issues, including moving RFC7451 to Informative
References section.
Authors' Addresses Authors' Addresses
James Gould James Gould
VeriSign, Inc. VeriSign, Inc.
12061 Bluemont Way 12061 Bluemont Way
Reston, VA 20190 Reston, VA 20190
United States of America United States of America
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisign.com URI: http://www.verisign.com
 End of changes. 11 change blocks. 
12 lines changed or deleted 24 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/