--- 1/draft-ietf-regext-secure-authinfo-transfer-01.txt 2020-06-12 09:13:03.976838221 -0700 +++ 2/draft-ietf-regext-secure-authinfo-transfer-02.txt 2020-06-12 09:13:04.032839655 -0700 @@ -1,19 +1,19 @@ Network Working Group J. Gould Internet-Draft R. Wilhelm 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 for Transfer - draft-ietf-regext-secure-authinfo-transfer-01 + draft-ietf-regext-secure-authinfo-transfer-02 Abstract The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the use of authorization information to authorize a transfer. The authorization information is object-specific and has been defined in the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact Mapping, in RFC 5733, as password-based authorization information. Other authorization mechanisms can be used, but in practice the password-based authorization information has been used at the time of @@ -37,21 +37,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -82,30 +82,31 @@ 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24 - A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24 - A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24 - A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24 - A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 26 - A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 + 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25 + A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25 + A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25 + A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25 + A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27 + A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27 + A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the use of authorization information to authorize a transfer. The authorization information is object-specific and has been defined in the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact Mapping, in [RFC5733], as password-based authorization information. Other authorization mechanisms can be used, but in practice the password-based authorization information has been used at the time of @@ -156,23 +157,23 @@ automatically unsetting the authorization information upon a successful transfer. All of these features can be supported by the EPP RFCs. "Storing Authorization Information Securely": The EPP RFCs don't specify where and how the authorization information is stored in the client or the server, so there are no restrictions to define an operational practice for storing the authorization information securely. The operational practice will not require the client to store the authorization information and will require the server to store the authorization information using a - cryptographic hash, with at least a 256-bit hash function, such - as SHA-256. Returning the authorization information set in an - EPP info response will not be supported. + cryptographic hash, with at least a 256-bit hash function such as + SHA-256, and with a random salt. Returning the authorization + information set in an EPP info response will not be supported. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming @@ -367,23 +368,25 @@ registrant of the TTL when the authorization information is provided to the registrant. 4.3. Authorization Information Storage and Transport To protect the disclosure of the authorization information, the following requirements apply: 1. The authorization information MUST be stored by the registry using a strong one-way cryptographic hash, with at least a - 256-bit hash function, such as SHA-256. - 2. An empty authorization information MUST be stored with a NULL - (undefined) value. + 256-bit hash function such as SHA-256, and with a random salt. + 2. An empty authorization information MUST be stored as an undefined + 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 registrar. 4. The authorization information MUST only be stored by the gaining registrar as a "transient" value in support of the transfer process. 5. The plain text version of the authorization information MUST NOT be written to any logs by the registrar or the registry. 6. All communication that includes the authorization information MUST be over an encrypted channel, such as defined in [RFC5734] @@ -1011,34 +1014,71 @@ Auhtorization Information in the Info Response. Licensing: Proprietary In-House software Contact: epp@centralnic.com URL: https://www.centralnic.com 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 The authors wish to thank the following persons for their feedback and suggestions: o Michael Bauland 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . @@ -1178,20 +1217,29 @@ A.5. Change from REGEXT 00 to REGEXT 01 1. Added the "Signaling Client and Server Support" section to describe the mechanism to signal support for the BCP by the client and the server. 2. Added the "IANA Considerations" section with the registration of the secure authorization for transfer XML namespace and the registration of the EPP Best Current Practice (BCP) in the EPP 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 James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisign.com