< draft-gould-regext-secure-authinfo-transfer-01.txt   draft-gould-regext-secure-authinfo-transfer-02.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 28, 2019 June 26, 2019 Expires: February 6, 2020 August 5, 2019
Extensible Provisioning Protocol (EPP) Secure Authorization Information Extensible Provisioning Protocol (EPP) Secure Authorization Information
for Transfer for Transfer
draft-gould-regext-secure-authinfo-transfer-01 draft-gould-regext-secure-authinfo-transfer-02
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 41 skipping to change at page 1, line 41
for transfers. for transfers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://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 28, 2019. This Internet-Draft will expire on February 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 44 skipping to change at page 2, line 44
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
5.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 16 5.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 16
5.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 16 5.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 18 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 18
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
object create, managed with the object update, and used to authorize object create, managed with the object update, and used to authorize
an object transfer request. What has not been considered is the an object transfer request. What has not been considered is the
security of the authorization information that includes the security of the authorization information that includes the
complexity of the authorization information, the time-to-live (TTL) complexity of the authorization information, the time-to-live (TTL)
of the authorization information, and where and how the authorization of the authorization information, and where and how the authorization
information is stored. This document defines an operational information is stored. This document defines an operational
practice, using the EPP RFCs, that leverages the use of strong, practice, using the EPP RFCs, that leverages the use of strong,
random authorization information values that are short-lived, that random authorization information values that are short-lived, that
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 3.3. Authorization Information Storage and Transport
To protect the disclosure of the authorization information, the To protect the disclosure of the authorization information, the
authorization information MUST be stored by the registry using a authorization information MUST be stored by the registry using a
strong one-way cryptographic hash and MUST NOT be stored by the strong one-way cryptographic hash, MUST NOT be stored by the losing
registrar. The plain text version of the authorization information registrar, and MUST only be stored by the gaining registrar as a
MUST NOT be written to any logs by the registrar or the registry. "transient" value in support of the transfer process. The plain text
All communication that includes the authorization information MUST be version of the authorization information MUST NOT be written to any
over an encrypted channel, such as [RFC5734] for EPP. The logs by the registrar or the registry. All communication that
registrar's interface for communicating the authorization information includes the authorization information MUST be over an encrypted
with the registrant MUST be over an authenticated and encrypted channel, such as [RFC5734] for EPP. The registrar's interface for
channel. communicating the authorization information with the registrant MUST
be over an authenticated and encrypted channel.
4. Create, Transfer, and Secure Authorization Information 4. 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 3, 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:
skipping to change at page 17, line 25 skipping to change at page 17, line 25
6. Security Considerations 6. Security Considerations
TBD TBD
7. Acknowledgements 7. 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 Scott Hollenbeck o Scott Hollenbeck
o Jody Kolker
o Patrick Mevzek
o Matthew Pozun o Matthew Pozun
o Srikanth Veeramachaneni o Srikanth Veeramachaneni
8. References 8. References
8.1. Normative References 8.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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc- DOI 10.17487/RFC4086, June 2005,
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)
Domain Name Mapping", STD 69, RFC 5731, Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009, <https://www.rfc- DOI 10.17487/RFC5731, August 2009,
editor.org/info/rfc5731>. <https://www.rfc-editor.org/info/rfc5731>.
[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, <https://www.rfc- DOI 10.17487/RFC5734, August 2009,
editor.org/info/rfc5734>. <https://www.rfc-editor.org/info/rfc5734>.
[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>.
skipping to change at page 18, line 37 skipping to change at page 18, line 37
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.
A.2. Change from 01 to 02
1. Revised the language used for the storage of the authorization
information based on the feedback from Patrick Mevzek and 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. 14 change blocks. 
22 lines changed or deleted 31 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/