From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9154.txt | 1143 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1143 insertions(+) create mode 100644 doc/rfc/rfc9154.txt (limited to 'doc/rfc/rfc9154.txt') diff --git a/doc/rfc/rfc9154.txt b/doc/rfc/rfc9154.txt new file mode 100644 index 0000000..cbe5879 --- /dev/null +++ b/doc/rfc/rfc9154.txt @@ -0,0 +1,1143 @@ + + + + +Internet Engineering Task Force (IETF) J. Gould +Request for Comments: 9154 R. Wilhelm +Category: Standards Track Verisign, Inc. +ISSN: 2070-1721 December 2021 + + +Extensible Provisioning Protocol (EPP) Secure Authorization Information + for Transfer + +Abstract + + The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use + of authorization information to authorize a transfer of an EPP + object, such as a domain name, between clients that are referred to + as "registrars". Object-specific, password-based authorization + information (see RFCs 5731 and 5733) is commonly used but raises + issues related to the security, complexity, storage, and lifetime of + authentication information. This document defines an operational + practice, using the EPP RFCs, that leverages the use of strong random + authorization information values that are short lived, not stored by + the client, and stored by the server using a cryptographic hash that + provides for secure authorization information that can safely be used + for object transfers. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9154. + +Copyright Notice + + Copyright (c) 2021 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 Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Conventions Used in This Document + 2. Registrant, Registrar, Registry + 3. Signaling Client and Server Support + 4. Secure Authorization Information + 4.1. Secure Random Authorization Information + 4.2. Authorization Information Time To Live (TTL) + 4.3. Authorization Information Storage and Transport + 4.4. Authorization Information Matching + 5. Create, Transfer, and Secure Authorization Information + 5.1. Command + 5.2. Command + 5.3. Command and Response + 5.4. Request Command + 6. Transition Considerations + 6.1. Transition Phase 1 - Features + 6.2. Transition Phase 2 - Storage + 6.3. Transition Phase 3 - Enforcement + 7. IANA Considerations + 7.1. XML Namespace + 7.2. EPP Extension Registry + 8. Security Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + The Extensible Provisioning Protocol (EPP) [RFC5730] defines the use + of authorization information to authorize a transfer of an EPP + object, such as a domain name, between clients that are referred to + as "registrars". The authorization information is object specific + and has been defined in "Extensible Provisioning Protocol (EPP) + Domain Name Mapping" [RFC5731] and "Extensible Provisioning Protocol + (EPP) Contact Mapping" [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 object creation, managed with the object update, and + used to authorize an object transfer request. What has not been + considered is the security of the authorization information, which + includes the complexity of the authorization information, the Time To + Live (TTL) of the authorization information, and where and how the + authorization information is stored. + + The current/original lifecycle for authorization information involves + long-term storage of encrypted (not hashed) passwords, which presents + a significant latent risk of password compromise and is not + consistent with current best practices. The mechanisms in this + document provide a way to avoid long-term password storage entirely + and to only require the storage of hashed (not retrievable) passwords + instead of encrypted passwords. + + This document defines an operational practice, using the EPP RFCs, + that leverages the use of strong, random authorization information + values that are short lived, not stored by the client, and stored by + the server using a cryptographic hash to provide secure authorization + information used for transfers. This operational practice can be + used to support transfers of any EPP object, where the domain name + object as defined in [RFC5731] is used in this document for + illustration purposes. Elements of the practice may be used to + support the secure use of the authorization information for purposes + other than transfer, but any other purposes and the applicable + elements are out of scope for this document. + + The overall goal is to have strong, random authorization information + values that are short lived and are either not stored or stored as + cryptographic hash values by the non-responsible parties. In a + registrant, registrar, and registry model, the registrant registers + the object through the registrar to the registry. The registrant is + the responsible party, and the registrar and the registry are the + non-responsible parties. EPP is a protocol between the registrar and + the registry, where the registrar is referred to as the "client" and + the registry is referred to as the "server". The following are the + elements of the operational practice and how the existing features of + the EPP RFCs can be leveraged to satisfy them: + + Strong Random Authorization Information: The EPP RFCs define the + password-based authorization information value using an XML + schema "normalizedString" type, so they don't restrict what can + be used in any substantial way. This operational practice + defines the recommended mechanism for creating a strong random + authorization value that would be generated by the client. + + Short-Lived Authorization Information: The EPP RFCs don't explicitly + support short-lived authorization information or a TTL for + authorization information, but there are EPP RFC features that + can be leveraged to support short-lived authorization + information. All of these features are compatible with the EPP + RFCs, though not mandatory to implement. As stated in + Section 2.6 of [RFC5731], authorization information is assigned + when a domain object is created, which results in long-lived + authorization information. This specification changes the nature + of the authorization information from long lived to short lived. + If authorization information is set only when a transfer is in + process, the server needs to support an empty authorization + information value on create, support setting and unsetting + authorization information, and support 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 on + defining an operational practice for storing the authorization + information securely. The operational practice will require the + client to not 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 [FIPS-180-4], and with a per-authorization information + random salt with at least 128 bits. 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", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + XML [W3C.REC-xml-20081126] 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 implementation. + + In examples, "C:" represents lines sent by a protocol client and "S:" + represents lines returned by a protocol server. Indentation and + empty space in examples are provided only to illustrate element + relationships and are not a required feature of this protocol. + + The examples reference XML namespace prefixes that are used for the + associated XML namespaces. Implementations MUST NOT depend on the + example XML namespaces and instead employ a proper namespace-aware + XML parser and serializer to interpret and output the XML documents. + The example namespace prefixes used and their associated XML + namespaces include the following: + + domain: urn:ietf:params:xml:ns:domain-1.0 + + contact: urn:ietf:params:xml:ns:contact-1.0 + +2. Registrant, Registrar, Registry + + The EPP RFCs refer to "client" and "server", but when it comes to + transfers, there are three types of actors that are involved. This + document will refer to these actors as "registrant", "registrar", and + "registry". [RFC8499] defines these terms formally for the Domain + Name System (DNS). The terms are further described below to cover + their roles as actors using the authorization information in the + transfer process of any object in the registry, such as a domain name + or a contact: + + Registrant: [RFC8499] defines the registrant as "an individual or + organization on whose behalf a name in a zone is registered by + the registry." The registrant can be the owner of any object in + the registry, such as a domain name or a contact. The registrant + interfaces with the registrar for provisioning the objects. A + transfer is coordinated by the registrant to transfer the + sponsorship of the object from one registrar to another. The + authorization information is meant to authenticate the registrant + as the owner of the object to the non-sponsoring registrar and to + authorize the transfer. + + Registrar: [RFC8499] defines the registrar as "a service provider + that acts as a go-between for registrants and registries." The + registrar interfaces with the registrant for the provisioning of + objects, such as domain names and contacts, and with the + registries to satisfy the registrant's provisioning requests. A + registrar may (1) directly interface with the registrant or + (2) indirectly interface with the registrant, typically through + one or more resellers. Implementing a transfer using secure + authorization information extends through the registrar's + reseller channel up to the direct interface with the registrant. + The registrar's interface with the registries uses EPP. The + registrar's interface with its reseller channel or the registrant + is registrar specific. In the EPP RFCs, the registrar is + referred to as the "client", since EPP is the protocol used + between the registrar and the registry. The sponsoring registrar + is the authorized registrar to manage objects on behalf of the + registrant. A non-sponsoring registrar is not authorized to + manage objects on behalf of the registrant. A transfer of an + object's sponsorship is from one registrar, referred to as the + "losing registrar", to another registrar, referred to as the + "gaining registrar". + + Registry: [RFC8499] defines the registry as "the administrative + operation of a zone that allows registration of names within that + zone." The registry typically interfaces with the registrars + 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 a new protocol; rather, it defines an + operational practice using existing EPP features, where the client + and the server can signal support for the operational practice 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 operational practice. The + client includes the namespace URI in an + element of the command [RFC5730]. The server includes the + namespace URI in an element of the greeting + [RFC5730]. + + A client that receives the namespace URI in the server's greeting + extension services can expect the following supported behavior by the + server: + + 1. Support for an empty authorization information value with a + command. + + 2. Support for unsetting authorization information with an + command. + + 3. Support for validating authorization information with an + command. + + 4. Support for not returning an indication of whether the + authorization information is set or unset to the non-sponsoring + registrar. + + 5. Support for returning an empty authorization information value to + the sponsoring registrar when the authorization information is + set in an info response. + + 6. Support for allowing the passing of a matching non-empty + authorization information value to authorize a transfer. + + 7. Support for automatically unsetting the authorization information + upon successful completion of a transfer. + + A server that receives the namespace URI in the client's + command extension services can expect the following supported + behavior by the client: + + 1. Support for the generation of authorization information using a + secure random value. + + 2. Support for only setting the authorization information when a + transfer is in process. + +4. Secure Authorization Information + + The EPP RFCs ([RFC5731] and [RFC5733]) use password-based + authorization information to support transfer with the + element [RFC5731] and with the element [RFC5733]. Other + EPP objects that support password-based authorization information for + transfer can use secure authorization information as defined in this + document. For authorization information to be secure, it must be + generated using a strong random value and have a short TTL. The + security of the authorization information is defined in the following + sections. + +4.1. Secure Random Authorization Information + + For authorization information to be secure, it MUST be generated + using a secure random value. The authorization information is + treated as a password, and the required length L of a password, + rounded up to the largest whole number, is based on the size N of the + set of characters and the desired entropy H, in the equation L = + ROUNDUP(H / log_2 N). Given a target entropy, the required length + can be calculated after deciding on the set of characters that will + be randomized. In accordance with current best practices and noting + that the authorization information is a machine-generated value, the + implementation SHOULD use at least 128 bits of entropy as the value + of H. The lengths below are calculated using that value. + + Calculation of the required length with 128 bits of entropy and with + the set of all printable ASCII characters except space (0x20), which + consists of the 94 characters 0x21-0x7E: + + ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 + + 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 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 + + The strength of the random authorization information is dependent on + the random number generator. Suitably strong random number + generators are available in a wide variety of implementation + environments, including the interfaces listed in Sections 7.1.2 and + 7.1.3 of [RFC4086]. In environments that do not provide interfaces + to strong random number generators, the practices defined in + [RFC4086] and Section 4.7.1 of the NIST Federal Information + Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be + followed to produce random values that will be resistant to attack. + (Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3 + does not contain information regarding random number generators.) + +4.2. Authorization Information Time To Live (TTL) + + The authorization information SHOULD only be set when a transfer is + in process. This implies that the authorization information has a + TTL by which the authorization information is cleared when the TTL + expires. The EPP RFCs do not provide definitions for TTL, but since + the server supports the setting and unsetting of the authorization + information by the sponsoring registrar, the sponsoring registrar can + apply a TTL based on client policy. The TTL client policy may be + based on proprietary registrar-specific criteria, which provides for + a transfer-specific TTL tuned for the particular circumstances of the + transaction. The sponsoring registrar will be aware of the TTL, and + the sponsoring registrar MUST inform the 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 [FIPS-180-4], and with a per- + authorization information random salt with at least 128 bits. + + 2. An empty authorization information value MUST be stored as an + undefined value that is referred to as a "NULL" value. The + representation of a 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 a registrar or the registry, nor + otherwise recorded where it will persist beyond the transfer + process. + + 6. All communication that includes the authorization information + MUST be over an encrypted channel (for example, see [RFC5734]) + for EPP. + + 7. The registrar's interface for communicating the authorization + information with the registrant MUST be over an authenticated and + encrypted channel. + +4.4. Authorization Information Matching + + To support the authorization information TTL, as described in + Section 4.2, the authorization information must have either a set or + unset state. Authorization information that is unset is stored with + a NULL (undefined) value. Based on the requirement to store the + authorization information using a strong one-way cryptographic hash, + as described in Section 4.3, authorization information that is set is + stored with a non-NULL hashed value. The empty authorization + information value is used as input in both the command + (Section 5.1) and the command (Section 5.2) to define the + unset state. The matching of the authorization information in the + command (Section 5.3) and the request command + (Section 5.4) is based on the following rules: + + 1. Any input authorization information value MUST NOT match an unset + authorization information value. For example, in [RFC5731] the + input 2fooBAR must not match an unset + authorization information value that used or + . + + 2. An empty input authorization information value MUST NOT match any + set authorization information value. + + 3. A non-empty input authorization information value MUST be hashed + and matched against the set authorization information value, + which is stored using the same hash algorithm. + +5. Create, Transfer, and Secure Authorization Information + + To secure the transfer process using secure authorization information + as described in Section 4, the client and server need to implement + steps where the authorization information is set only when a transfer + is actively in process and ensure that the authorization information + is stored securely and transported only over secure channels. The + steps for management of the authorization information for transfers + include the following: + + 1. The registrant requests to register the object with the + registrar. The registrar sends the command with an + empty authorization information value to the registry, as + described in Section 5.1. + + 2. The registrant requests from the losing registrar the + authorization information to provide to the gaining registrar. + + 3. The losing registrar generates a secure random authorization + information value and sends it to the registry, as described in + Section 5.2, and then provides it to the registrant. + + 4. The registrant provides the authorization information value to + the gaining registrar. + + 5. The gaining registrar optionally verifies the authorization + information with the command to the registry, as described + in Section 5.3. + + 6. The gaining registrar sends the transfer request with the + authorization information to the registry, as described in + Section 5.4. + + 7. If the transfer completes successfully, the registry + automatically unsets the authorization information; otherwise, + the losing registrar unsets the authorization information when + the TTL expires; see Section 5.2. + + The following sections outline the practices of the EPP commands and + responses between the registrar and the registry that supports secure + authorization information for transfer. + +5.1. Command + + For a command, the registry MUST allow the passing of an + empty authorization information value and MAY disallow the passing of + a non-empty authorization information value. By having an empty + authorization information value on create, the object is initially + not involved in the transfer process. Any EPP object extension that + supports setting the authorization information with an + "eppcom:pwAuthInfoType" element can pass an empty authorization + information value. Examples of such extensions are found in + [RFC5731] and [RFC5733]. + + Example of passing an empty authorization information value in a + domain name command [RFC5731]: + + C: + C: + C: + C: + C: + C: example.com + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + Example of passing an empty authorization information value in a + contact command [RFC5733]: + + C: + C: + C: + C: + C: + C: sh8013 + C: + C: John Doe + C: + C: Dulles + C: US + C: + C: + C: jdoe@example.com + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + +5.2. Command + + For an command, the registry MUST allow the setting and + unsetting of the authorization information. The registrar sets the + authorization information by first generating a strong, random + authorization information value, based on the information provided in + Section 4.1, and setting it in the registry in the command. + The importance of generating strong authorization information values + cannot be overstated: secure transfers are very important to the + Internet to mitigate damage in the form of theft, fraud, and other + abuse. It is critical that registrars only use strong, randomly + generated authorization information values. + + Because of this, registries may validate the randomness of the + authorization information based on the length and character set + required by the registry -- for example, validating that an + authorization value contains a combination of uppercase, lowercase, + and non-alphanumeric characters in an attempt to assess the strength + of the value and returning an EPP error result of 2202 ("Invalid + authorization information") [RFC5730] if the check fails. + + Such checks are, by their nature, heuristic and imperfect, and may + identify well-chosen authorization information values as being not + sufficiently strong. Registrars, therefore, must be prepared for an + error response of 2202 and respond by generating a new value and + trying again, possibly more than once. + + Often, the registrar has the "clientTransferProhibited" status set, + so to start the transfer process, the "clientTransferProhibited" + status needs to be removed, and the strong, random authorization + information value needs to be set. The registrar MUST define a TTL, + as described in Section 4.2, and if the TTL expires, the registrar + will unset the authorization information. + + Example of removing the "clientTransferProhibited" status and setting + the authorization information in a domain name command + [RFC5731]: + + C: + C: + C: + C: + C: + C: example.com + C: + C: + C: + C: + C: + C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP + C: + C: + C: + C: + C: + C: ABC-12345-XYZ + C: + C: + + When the registrar-defined TTL expires, the sponsoring registrar MUST + cancel the transfer process by unsetting the authorization + information value and MAY add back statuses like the + "clientTransferProhibited" status. Any EPP object extension that + supports setting the authorization information with an + "eppcom:pwAuthInfoType" element can pass an empty authorization + information value. Examples of such extensions are found in + [RFC5731] and [RFC5733]. Setting an empty authorization information + value unsets the authorization information. [RFC5731] supports an + explicit mechanism of unsetting the authorization information, by + passing the authorization information value. The + registry MUST support unsetting the authorization information by + accepting an empty authorization information value and accepting an + explicit unset element if it is supported by the object extension. + + Example of adding the "clientTransferProhibited" status and unsetting + the authorization information explicitly in a domain name + command [RFC5731]: + + C: + C: + C: + C: + C: + C: example.com + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: ABC-12345-XYZ + C: + C: + + Example of unsetting the authorization information with an empty + authorization information value in a domain name command + [RFC5731]: + + C: + C: + C: + C: + C: + C: example.com + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: + C: ABC-12345-XYZ + C: + C: + + Example of unsetting the authorization information with an empty + authorization information value in a contact command + [RFC5733]: + + C: + C: + C: + C: + C: + C: sh8013 + C: + C: + C: + C: + C: + C: + C: + C: ABC-12345-XYZ + C: + C: + +5.3. Command and Response + + For an command, the registry MUST allow the passing of a non- + empty authorization information value for verification. The gaining + registrar can pre-verify the authorization information provided by + the registrant prior to submitting the transfer request with the use + of the command. The registry compares the hash of the passed + authorization information with the hashed authorization information + value stored for the object. When the authorization information is + not set or the passed authorization information does not match the + previously set value, the registry MUST return an EPP error result + code of 2202 [RFC5730]. + + Example of passing a non-empty authorization information value in a + domain name command [RFC5731] to verify the authorization + information value: + + C: + C: + C: + C: + C: + C: example.com + C: + C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + The info response in object extensions, such as those defined in + [RFC5731] and [RFC5733], MUST NOT include the optional authorization + information element with a non-empty authorization value. The + authorization information is stored as a hash in the registry, so + returning the plain-text authorization information is not possible, + unless valid plain-text authorization information is passed in the + command. The registry MUST NOT return any indication of + whether the authorization information is set or unset to the non- + sponsoring registrar by not returning the authorization information + element in the response. The registry MAY return an indication to + the sponsoring registrar that the authorization information is set by + using an empty authorization information value. The registry MAY + return an indication to the sponsoring registrar that the + authorization information is unset by not returning the authorization + information element. + + Example of returning an empty authorization information value in a + domain name info response [RFC5731] to indicate to the sponsoring + registrar that the authorization information is set: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: example.com + S: EXAMPLE1-REP + S: + S: ClientX + S: + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + +5.4. Request Command + + For a request command, the registry MUST allow the passing + of a non-empty authorization information value to authorize a + transfer. The registry compares the hash of the passed authorization + information with the hashed authorization information value stored + for the object. When the authorization information is not set or the + passed authorization information does not match the previously set + value, the registry MUST return an EPP error result code of 2202 + [RFC5730]. Whether the transfer occurs immediately or is pending is + up to server policy. When the transfer occurs immediately, the + registry MUST return the EPP success result code of 1000 ("Command + completed successfully") [RFC5730], and when the transfer is pending, + the registry MUST return the EPP success result code of 1001 + ("Command completed successfully; action pending"). The losing + registrar MUST be informed of a successful transfer request using an + EPP message. + + Example of passing a non-empty authorization information value in a + domain name request command [RFC5731] to authorize the + transfer: + + C: + C: + C: + C: + C: + C: example1.com + C: + C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + Upon successful completion of the transfer, the registry MUST + automatically unset the authorization information. If the transfer + request is not submitted within the TTL (Section 4.2) or the transfer + is canceled or rejected, the registrar MUST unset the authorization + information, as described in Section 5.2. + +6. Transition Considerations + + The goal of the transition considerations is to minimize the impact + to the registrars in supporting the Secure Authorization Information + Model defined in this document by supporting incremental transition + steps. The transition steps are dependent on the starting point of + the registry. Registries may have different starting points, since + some of the elements of the Secure Authorization Information Model + may have already been implemented. The considerations assume a + starting point, referred to as the "Classic Authorization Information + Model", which incorporates the following steps for management of the + authorization information for transfers: + + 1. The registrant requests to register the object with the + registrar. The registrar sends the command, with a non- + empty authorization information value, to the registry. The + registry stores the authorization information as an encrypted + value and requires a non-empty authorization information value + for the life of the object. The registrar may store the long- + lived authorization information. + + 2. At the time of transfer, the registrant requests from the losing + registrar the authorization information to provide to the gaining + registrar. + + 3. The losing registrar retrieves the locally stored authorization + information or queries the registry for authorization information + using the command, and provides it to the registrant. If + the registry is queried, the authorization information is + decrypted and the plain-text authorization information is + returned in the info response to the registrar. + + 4. The registrant provides the authorization information value to + the gaining registrar. + + 5. The gaining registrar optionally verifies the authorization + information with the command to the registry, by passing + the authorization information in the command to the + registry. + + 6. The gaining registrar sends the transfer request with the + authorization information to the registry. The registry will + decrypt the stored authorization information to compare to the + passed authorization information. + + 7. If the transfer completes successfully, the authorization + information is not touched by the registry and may be updated by + the gaining registrar using the command. If the + transfer is canceled or rejected, the losing registrar may reset + the authorization information using the command. + + The gaps between the Classic Authorization Information Model and the + Secure Authorization Information Model include the following: + + 1. Registry requirement for a non-empty authorization information + value on create and for the life of the object versus the + authorization information not being set on create and only being + set when a transfer is in process. + + 2. Registry not allowing the authorization information to be unset + versus providing support for unsetting the authorization + information in the command. + + 3. Registry storing the authorization information as an encrypted + value versus a hashed value. + + 4. Registry support for returning the authorization information + versus not returning the authorization information in the info + response. + + 5. Registry not touching the authorization information versus the + registry automatically unsetting the authorization information + upon a successful transfer. + + 6. Registry possibly validating a shorter authorization information + value using password complexity rules versus validating the + randomness of a longer authorization information value that meets + the required bits of entropy. + + The transition can be handled in the three phases defined in + Sections 6.1, 6.2, and 6.3. + +6.1. Transition Phase 1 - Features + + The goal of "Transition Phase 1 - Features" is to implement the + needed features in EPP so that the registrar can optionally implement + the Secure Authorization Information Model. The features to + implement are broken out by the commands and responses below: + + Command: Change the command to make the + authorization information optional, by allowing both a non-empty + value and an empty value. This enables a registrar to optionally + create objects without an authorization information value, as + described in Section 5.1. + + Command: Change the command to allow unsetting the + authorization information, as described in Section 5.2. This + enables the registrar to optionally unset the authorization + information when the TTL expires or when the transfer is canceled + or rejected. + + Transfer Approve Command and Transfer Auto-Approve: Change the + transfer approve command and the transfer auto-approve to + automatically unset the authorization information. This sets the + default state of the object to not have the authorization + information set. The registrar implementing the Secure + Authorization Information Model will not set the authorization + information for an inbound transfer, and the registrar + implementing the Classic Authorization Information Model will set + the new authorization information upon a successful transfer. + + Info Response: Change the command to not return the + authorization information in the info response, as described in + Section 5.3. This sets up the implementation of "Transition Phase + 2 - Storage" (Section 6.2), since the dependency on returning the + authorization information in the info response will be removed. + This feature is the only one that is not an optional change to the + registrar, and this change could potentially break the client, so + it's recommended that the registry provide notice of the change. + + Command and Transfer Request: Change the command and + the transfer request to ensure that a registrar cannot get an + indication that the authorization information is set or not set by + returning the EPP error result code of 2202 when comparing a + passed authorization to a non-matching set authorization + information value or an unset value. + +6.2. Transition Phase 2 - Storage + + The goal of "Transition Phase 2 - Storage" is to transition the + registry to use hashed authorization information instead of encrypted + authorization information. There is no direct impact on the + registrars, since the only visible indication that the authorization + information has been hashed is that the set authorization information + is not returned in the info response, as addressed in "Transition + Phase 1 - Features" (Section 6.1). Transitioning the authorization + information storage includes the following three steps: + + Hash New Authorization Information Values: Change the + command and the command to hash rather than encrypt the + authorization information. + + Support Comparison against Encrypted or Hashed Authorization + Information: Change the command and the request + command to be able to compare a passed authorization information + value with either a hashed or encrypted authorization information + value. This requires that the stored values be self-identifying + as being in hashed or encrypted form. + + Hash Existing Encrypted Authorization Information Values: Convert + the encrypted authorization information values stored in the + registry database to hashed values. This update will not be + visible 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 "Transition Phase 3 - Enforcement" is to complete the + implementation of the Secure Authorization Information Model, by + enforcing the following: + + Disallow Authorization Information on Command: Change the + command to not allow the passing of a non-empty + authorization information value. This behavior could potentially + break the client, so it's recommended that the registry provide + notice of this change. + + Validate the Strong Random Authorization Information: Change the + validation of the authorization information in the + command to ensure at least 128 bits of entropy. + +7. IANA Considerations + +7.1. XML Namespace + + This document uses URNs to describe XML namespaces conforming to the + registry mechanism described in [RFC3688]. IANA has assigned the + following URI in the "ns" subregistry within the "IETF XML Registry" + for secure authorization information for the 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 + + IANA has registered the EPP operational practice described in this + document in the "Extensions for the Extensible Provisioning Protocol + (EPP)" registry as defined in [RFC7451]. The details of the + registration are as follows: + + Name of Extension: "Extensible Provisioning Protocol (EPP) Secure + Authorization Information for Transfer" + Document status: Standards Track + Reference: RFC 9154 + Registrant Name and Email Address: IESG (iesg@ietf.org) + TLDs: Any + IPR Disclosure: None + Status: Active + Notes: None + +8. Security Considerations + + Section 4.1 defines the use of a secure random value for the + generation of authorization information. The client SHOULD choose a + length and set of characters that result in at least 128 bits of + entropy. + + Section 4.2 defines the use of an authorization information TTL. The + registrar SHOULD only set the authorization information during the + transfer process by setting the authorization information at the + start of the transfer process and unsetting the authorization + information at the end of the transfer process. The TTL value is + left 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 per-authorization information random salt + with at least 128 bits. 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 value + as a NULL (undefined) value to ensure that an empty input + authorization information value never matches it. The method used to + define a NULL (undefined) value is database specific. + +9. References + +9.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, + . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + . + + [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, + August 2009, . + + [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Transport over TCP", STD 69, RFC 5734, + DOI 10.17487/RFC5734, August 2009, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + + [W3C.REC-xml-20081126] + Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and + F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth + Edition)", World Wide Web Consortium Recommendation REC- + xml-20081126, November 2008, + . + +9.2. Informative References + + [FIPS-140-2] + National Institute of Standards and Technology, U.S. + Department of Commerce, "NIST Federal Information + Processing Standards (FIPS) Publication 140-2", + DOI 10.6028/NIST.FIPS.140-2, May 2001, + . + + [FIPS-180-4] + National Institute of Standards and Technology, U.S. + Department of Commerce, "Secure Hash Standard, NIST + Federal Information Processing Standards (FIPS) + Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August + 2015, + . + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, . + +Acknowledgements + + The authors wish to thank the following persons for their feedback + and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, + Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew + Pozun, Srikanth Veeramachaneni, and Ulrich Wisser. + +Authors' Addresses + + James Gould + Verisign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: jgould@verisign.com + URI: https://www.verisign.com + + + Richard Wilhelm + Verisign, Inc. + 12061 Bluemont Way + Reston, VA 20190 + United States of America + + Email: 4rickwilhelm@gmail.com + URI: https://www.verisign.com -- cgit v1.2.3