--- 1/draft-ietf-regext-secure-authinfo-transfer-03.txt 2020-10-21 13:13:15.803664349 -0700 +++ 2/draft-ietf-regext-secure-authinfo-transfer-04.txt 2020-10-21 13:13:15.903666881 -0700 @@ -1,19 +1,19 @@ Network Working Group J. Gould Internet-Draft R. Wilhelm -Intended status: Best Current Practice VeriSign, Inc. -Expires: February 1, 2021 July 31, 2020 +Intended status: Standards Track VeriSign, Inc. +Expires: 24 April 2021 21 October 2020 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer - draft-ietf-regext-secure-authinfo-transfer-03 + draft-ietf-regext-secure-authinfo-transfer-04 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,77 +37,75 @@ 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 February 1, 2021. + This Internet-Draft will expire on 24 April 2021. 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 - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. + 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 carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Simplified BSD License text + as described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 3. Signaling Client and Server Support . . . . . . . . . . . . . 6 4. Secure Authorization Information . . . . . . . . . . . . . . 7 4.1. Secure Random Authorization Information . . . . . . . . . 7 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 - 4.3. Authorization Information Storage and Transport . . . . . 8 + 4.3. Authorization Information Storage and Transport . . . . . 9 4.4. Authorization Information Matching . . . . . . . . . . . 9 - 5. Create, Transfer, and Secure Authorization Information . . . 9 + 5. Create, Transfer, and Secure Authorization Information . . . 10 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 - 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 16 - 6. Transition Considerations . . . . . . . . . . . . . . . . . . 17 + 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17 + 6. Transition Considerations . . . . . . . . . . . . . . . . . . 18 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19 - 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19 - 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20 + 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 20 + 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 - 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 + 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 - 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22 + 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 - 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 24 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 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 + A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 @@ -245,24 +241,24 @@ over EPP and generally does not interact directly with the registrant. In the EPP RFCs, the registry is referred to as the "server", since EPP is the protocol used between the registrar and the registry. The registry has a record of the sponsoring registrar for each object and provides the mechanism (over EPP) to coordinate a transfer of an object's sponsorship between registrars. 3. Signaling Client and Server Support - This document does not define new protocol but a Best Current - 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 login and greeting extension services. The namespace URI + This document does not define new protocol but an operational + practice using the existing EPP protocol, where the client and the + server can signal support for the BCP using a namespace URI in the + login and greeting extension services. The namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to signal support for the BCP. The client includes the namespace URI in an element of the [RFC5730] Command. The server includes the namespace URI in an element of the [RFC5730] Greeting. A client that receives the namespace URI in the server's Greeting extension services, can expect the following supported behavior by the server: @@ -342,27 +336,29 @@ Calculation of the required length with 128 bits of entropy and with the set of case insensitive alphanumeric characters, which consists of 36 characters (a-z A-Z 0-9). ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 The strength of the random authorization information is dependent on the actual entropy of the underlying random number generator. For the random number generator, the practices defined in [RFC4086] and section 4.7.1 of the NIST Federal Information Processing Standards - (FIPS) Publication 140-2 [1] SHOULD be followed to produce random - values that will be resistant to attack. A random number generator - (RNG) is preferable over the use of a pseudorandom number generator - (PRNG) to reduce the predictability of the authorization information. - The more predictable the random number generator is, the lower the - true entropy, and the longer the required length for the - authorization information. + (FIPS) Publication 140-2 + (https://csrc.nist.gov/publications/detail/fips/140/2/final) SHOULD + be followed to produce random values that will be resistant to + attack. A random number generator (RNG) is preferable over the use + of a pseudorandom number generator (PRNG) to reduce the + predictability of the authorization information. The more + predictable the random number generator is, the lower the true + entropy, and the longer the required length for the authorization + information. 4.2. Authorization Information Time-To-Live (TTL) The authorization information SHOULD only be set when there is a transfer in process. This implies that the authorization information has a Time-To-Live (TTL) by which the authorization information is cleared when the TTL expires. The EPP RFCs have no definition of TTL, but since the server supports the setting and unsetting of the authorization information by the sponsoring registrar, then the sponsoring registrar can apply a TTL based on client policy. The TTL @@ -886,24 +880,24 @@ registrars, since the only visible indication that the authorization information has been hashed is by not returning the set authorization information in the info response, which is addressed in Transition Phase 1 - Features (Section 6.1). There are three steps to transition the authorization information storage, which includes: Hash New Authorization Information Values: Change the create command and the update command to hash instead of encyrpting the authorization information. Supporting Comparing Against Encrypted and Hashed Authorization - Information: - Change the info command and the transfer request command to be - able to compare a passed authorization information value with - either a hashed or encyrpted authorization information value. + Information: Change the info command and the transfer request + command to be able to compare a passed authorization information + value with either a hashed or encyrpted authorization information + value. Hash Existing Encrypted Authorization Information Values: Convert the encrypted authorization information values stored in the registry database to hashed values. The update is not a visible change to the registrar. The conversion can be done over a period of time depending on registry policy. 6.3. Transition Phase 3 - Enforcement The goal of the "Transition Phase 3 - Enforcement" is to complete the implementation of the "Secure Authorization Information Model", by @@ -926,28 +920,28 @@ Registration request for the secure authorization information for transfer namespace: URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. 7.2. EPP Extension Registry - The EPP Best Current Practice (BCP) described in this document should - be registered by the IANA in the EPP Extension Registry described in + The EPP operational practice described in this document should be + registered by the IANA in the EPP Extension Registry described in [RFC7451]. The details of the registration are as follows: Name of Extension: "Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer" - Document status: Best Current Practice + Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, TLDs: Any IPR Disclosure: None Status: Active @@ -1059,34 +1052,25 @@ 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 + and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, + Jody Kolker, Patrick Mevzek, Matthew Pozun, Srikanth Veeramachaneni, + and Ulrich Wisser. -11.1. Normative References +11. 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, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . @@ -1119,24 +1103,20 @@ [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . -11.2. URIs - - [1] https://csrc.nist.gov/publications/detail/fips/140/2/final - Appendix A. Change History A.1. Change from 00 to 01 1. Filled in the "Implementation Status" section with the inclusion of the "Verisign EPP SDK" and "RegistryEngine EPP Service" implementations. 2. Made small wording corrections based on private feedback. 3. Added content to the "Acknowledgements" section. @@ -1239,28 +1217,37 @@ 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. +A.8. Change from REGEXT 03 to REGEXT 04 + + 1. Converted from xml2rfc v2 to v3. + 2. Updated Acknowledgements to match the approach taken by the RFC + Editor with draft-ietf-regext-login-security. + 3. Changed from Best Current Practice (BCP) to Standards Track based + on mailing list discussion. + Authors' Addresses James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 - US + United States of America Email: jgould@verisign.com URI: http://www.verisign.com + Richard Wilhelm VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 - US + United States of America Email: rwilhelm@verisign.com URI: http://www.verisign.com