draft-ietf-regext-secure-authinfo-transfer-01.txt   draft-ietf-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: October 25, 2020 April 23, 2020 Expires: December 14, 2020 June 12, 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-01 draft-ietf-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 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 October 25, 2020. This Internet-Draft will expire on December 14, 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 48 skipping to change at page 2, line 48
6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19
6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21
8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22
8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25
A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25
A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25
A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25
A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 26 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27
A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 26 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 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
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 4, line 25 skipping to change at page 4, line 26
automatically unsetting the authorization information upon a automatically unsetting the authorization information upon a
successful transfer. All of these features can be supported by successful transfer. All of these features can be supported by
the EPP RFCs. the EPP RFCs.
"Storing Authorization Information Securely": The EPP RFCs don't "Storing Authorization Information Securely": The EPP RFCs don't
specify where and how the authorization information is stored in specify where and how the authorization information is stored in
the client or the server, so there are no restrictions to define the client or the server, so there are no restrictions to define
an operational practice for storing the authorization information an operational practice for storing the authorization information
securely. The operational practice will not require the client securely. The operational practice will not require the client
to store the authorization information and will require the to store the authorization information and will require the
server to store the authorization information using a server to store the authorization information using a
cryptographic hash, with at least a 256-bit hash function, such cryptographic hash, with at least a 256-bit hash function such as
as SHA-256. Returning the authorization information set in an SHA-256, and with a random salt. Returning the authorization
EPP info response will not be supported. information set in an EPP info response will not be supported.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be interpreted in the and examples provided in this document MUST be interpreted in the
character case presented in order to develop a conforming character case presented in order to develop a conforming
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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.
4.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, and with a random salt.
2. An empty authorization information MUST be stored with a NULL 2. An empty authorization information MUST be stored as an undefined
(undefined) value. value that is referred to as a NULL value. The representation of
an NULL (undefined) value is dependent on the type of database
used.
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]
skipping to change at page 23, line 7 skipping to change at page 23, line 7
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
9. Security Considerations 9. Security Considerations
TBD Section 4.1 defines the use a secure random value for the generation
of the authorization information. The server SHOULD define policy
related to the length and set of characters that are included in the
randomization to target the desired entropy level, with the
recommendation of at least 49 bits for entropy. The authorization
information server policy is communicated to the client using an out-
of-band process. The client SHOULD choose a length and set of
characters that results in entropy that meets or exceeds the server
policy. A random number generator (RNG) is preferable over the use
of a pseudorandom number generator (PRNG) when creating the
authorization information value.
Section 4.2 defines the use of an authorization information Time-To-
Live (TTL). The registrar SHOULD only set the authorization
information during the transfer process by the server support for
setting and unsetting the authorization information. The TTL value
is up to registrar policy and the sponsoring registrar MUST inform
the registrant of the TTL when providing the authorization
information to the registrant.
Section 4.3 defines the storage and transport of authorization
information. The losing registrar MUST NOT store the authorization
information and the gaining registrar MUST only store the
authorization information as a "transient" value during the transfer
process, where the authorization information MUST NOT be stored after
the end of the transfer process. The registry MUST store the
authorization information using a one-way cryptographic hash of at
least 256 bits and with a random salt. All communication that
includes the authorization information MUST be over an encrypted
channel. The plain text authorization information MUST NOT be
written to any logs by the registrar or the registry.
Section 4.4 defines the matching of the authorization information
values. The registry stores an unset authorization information as a
NULL (undefined) value to ensure that an empty input authorization
information never matches it. The method used to define a NULL
(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:
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
o Ulrich Wisser
11. References 11. References
11.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>.
skipping to change at page 26, line 29 skipping to change at page 27, line 21
A.5. Change from REGEXT 00 to REGEXT 01 A.5. Change from REGEXT 00 to REGEXT 01
1. Added the "Signaling Client and Server Support" section to 1. Added the "Signaling Client and Server Support" section to
describe the mechanism to signal support for the BCP by the describe the mechanism to signal support for the BCP by the
client and the server. client and the server.
2. Added the "IANA Considerations" section with the registration of 2. Added the "IANA Considerations" section with the registration of
the secure authorization for transfer XML namespace and the the secure authorization for transfer XML namespace and the
registration of the EPP Best Current Practice (BCP) in the EPP registration of the EPP Best Current Practice (BCP) in the EPP
Extension Registry. Extension Registry.
A.6. Change from REGEXT 01 to REGEXT 02
1. Added inclusion of random salt for the hashed authorization
information, based on feedback from Ulrich Wisser.
2. Added clarification that the representation of a NULL (undefined)
value is dependent on the type of database, based on feedback
from Patrick Mevzek.
3. Filled in the Security Considerations 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
US US
Email: jgould@verisign.com Email: jgould@verisign.com
URI: http://www.verisign.com URI: http://www.verisign.com
 End of changes. 9 change blocks. 
20 lines changed or deleted 69 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/