RFC 9154

Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer

📅 published December 2021, from ietf

RFC 9154: Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer 💖

Authors: J. Gould and R. Wilhelm, Verisign, Inc. 👯‍♀️ Category: Standards Track 🎀 ISSN: 2070-1721 Date: December 2021 📅 Obsoletes / Updates: none listed in this title block 🙈

Abstract 🌸

okay so the Extensible Provisioning Protocol (EPP) (RFC 5730) has this way to use authorization info to approve moving an EPP object, like a domain name, between clients called "registrars" 🦋. The usual move is password-based authorization info (see RFCs 5731 and 5733), and ngl it's a whole mess. It brings up problems with security, complexity, storage, and how long the info lasts 😭. This doc defines an operational practice, using the EPP RFCs, that makes the info strong and random ✨, short-lived 🕐, not stored by the client 🙅‍♀️, and stored by the server as a cryptographic hash 🔐. That's how you get secure authorization info that can actually be used for object transfers, and it's giving main character energy 👑.

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 (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.  <Create> Command
  5.2.  <Update> Command
  5.3.  <Info> Command and Response
  5.4.  <Transfer> 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 ✨

okay so EPP's RFCs keep saying "client" and "server", but when it comes to transfers there are actually three actors in the mix 🫶 this doc calls them "registrant", "registrar", and "registry". [RFC8499] formally defines these terms for the Domain Name System (DNS). Below is how each one works as an actor when authorization information is used in a transfer of any object in the registry, like 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 own any object in the registry, like a domain name or a contact. They talk to the registrar to provision their objects. A transfer is coordinated by the registrant to move the sponsorship of the object from one registrar to another. The authorization information is there to prove to the non-sponsoring registrar that the registrant really owns the object, 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 talks to the registrant to provision objects like domain names and contacts, and it talks to the registries to make the registrant's provisioning requests happen. A registrar may (1) directly interface with the registrant or (2) indirectly interface with the registrant, usually through one or more resellers. Using secure authorization information in a transfer stretches all the way through the registrar's reseller channel up to the direct interface with the registrant 🌈 The registrar's connection to the registries uses EPP. The connection to its reseller channel or the registrant is registrar-specific. In the EPP RFCs the registrar is called the "client", since EPP is the protocol between the registrar and the registry. The sponsoring registrar is the one authorized to manage objects on the registrant's behalf. A non-sponsoring registrar is not authorized to manage objects on the registrant's behalf. A transfer of an object's sponsorship goes from one registrar, the "losing registrar", to another registrar, 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 usually talks to the registrars over EPP and generally doesn't interact directly with the registrant. In the EPP RFCs the registry is called the "server", since EPP is the protocol between the registrar and the registry. The registry keeps 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 🌸

Okay, this doc doesn't invent a brand new protocol 🙈 instead it defines an operational practice using EPP features that already exist. The client and the server can signal that they support this practice by 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 what signals support for the practice. The client puts the namespace URI in an <svcExtension> <extURI> element of the <login> command [RFC5730]. The server puts the namespace URI in an <svcExtension> <extURI> element of the greeting [RFC5730] ✨

If a client sees the namespace URI in the server's greeting extension services, it can expect the following supported behavior from the server:

  1. Support for an empty authorization information value with a <create> command.
  2. Support for unsetting authorization information with an <update> command.
  3. Support for validating authorization information with an <info> 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.

If a server sees the namespace URI in the client's <login> command extension services, it can expect the following supported behavior from 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 🔐

Okay, the EPP RFCs ([RFC5731] and [RFC5733]) use password-based authorization information for transfers, through the <domain:pw> element [RFC5731] and the <contact:pw> element [RFC5733]. Other EPP objects that support password-based authorization information for transfer can use the secure authorization information 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 rules are spelled out in the sections below 🦋

4.1. Secure Random Authorization Information 🎲

For authorization information to be secure, it MUST be generated using a secure random value. Treat the authorization information like a password. The required length L of a password, rounded up to the largest whole number, depends on the size N of the character set and the entropy H you want, using the equation L = ROUNDUP(H / log_2 N). So once you've picked your target entropy, you can work out the required length after deciding which characters will be randomized 💅 Since this is a machine-generated value, and that matches current best practices, the implementation SHOULD use at least 128 bits of entropy as the value of H. The lengths below are calculated with that value 🌈

Here's the calculation with 128 bits of entropy and the set of all printable ASCII characters except space (0x20), which is the 94 characters 0x21-0x7E:

ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20

And here's the calculation with 128 bits of entropy and the set of case-insensitive alphanumeric characters, which is 36 characters (a-z A-Z 0-9):

ROUNDUP(128 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
The strength of your random authorization information depends on the random number generator, so this part really matters 😭 Suitably strong random number generators are available in lots of implementation environments, including the interfaces listed in Sections 7.1.2 and 7.1.3 of [RFC4086]. In environments that don't provide interfaces to strong random number generators, you can follow the practices defined in [RFC4086] and Section 4.7.1 of the NIST Federal Information Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] to produce random values that resist attack. (Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3 doesn't contain information about 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 means the authorization information has a TTL, and it gets cleared when that TTL expires 🙈 The EPP RFCs don't define TTL. But since the server supports setting and unsetting the authorization information by the sponsoring registrar, the sponsoring registrar can apply a TTL based on client policy. That client policy may be based on proprietary, registrar-specific criteria, which allows a transfer-specific TTL tuned to the particular circumstances of the transaction 🎀 The sponsoring registrar will know the TTL, and the sponsoring registrar MUST inform the registrant of the TTL when the authorization information is given 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. How a NULL (undefined) value is represented depends on the type of database being 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. Because the authorization information has to be stored 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 <create> command (Section 5.1) and the <update> command (Section 5.2) to define the unset state. Matching of the authorization information in the <info> command (Section 5.3) and the <transfer> request command (Section 5.4) follows these rules:

  1. Any input authorization information value MUST NOT match an unset authorization information value. For example, in [RFC5731] the input <domain:pw>2fooBAR</domain:pw> must not match an unset authorization information value that used <domain:null/> or <domain:pw/>. 💅
  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 ✨

Okay bestie, this is where we actually make the secure transfer happen 🦋 To lock down a transfer with the secure authorization info from Section 4, the client and server both need to make sure the authorization info is only set while a transfer is actively in process 💅 It also has to be stored securely and only sent over secure channels 🔒 Here's the step-by-step:

  1. The registrant requests to register the object with the registrar. The registrar sends the <create> 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 <info> 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 how the EPP commands and responses between the registrar and the registry support secure authorization information for transfer 🌸

5.1. <Create> Command 🎀

For a <create> 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. Passing an empty value on create means 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 <create> command [RFC5731]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <domain:create
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw/>
C:        </domain:authInfo>
C:      </domain:create>
C:    </create>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

Example of passing an empty authorization information value in a contact <create> command [RFC5733]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <create>
C:      <contact:create
C:       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:        <contact:id>sh8013</contact:id>
C:        <contact:postalInfo type="int">
C:          <contact:name>John Doe</contact:name>
C:          <contact:addr>
C:            <contact:city>Dulles</contact:city>
C:            <contact:cc>US</contact:cc>
C:          </contact:addr>
C:        </contact:postalInfo>
C:        <contact:email>jdoe@example.com</contact:email>
C:        <contact:authInfo>
C:          <contact:pw/>
C:        </contact:authInfo>
C:      </contact:create>
C:    </create>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

5.2. <Update> Command 🔥

For an <update> 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 then setting it in the registry in the <update> command. Generating strong authorization information values is a huge deal ngl: secure transfers are very important to the Internet, because they help stop 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, a registry might check that a value contains a combination of uppercase, lowercase, and non-alphanumeric characters, in an attempt to assess the strength of the value. If the check fails, the registry returns an EPP error result of 2202 ("Invalid authorization information") [RFC5730] 🙈

These checks are, by their nature, heuristic and imperfect, and they may flag well-chosen authorization information values as 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. 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 <update> command [RFC5731]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <domain:update
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:rem>
C:          <domain:status s="clientTransferProhibited"/>
C:        </domain:rem>
C:        <domain:chg>
C:          <domain:authInfo>
C:            <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C:            </domain:pw>
C:          </domain:authInfo>
C:        </domain:chg>
C:      </domain:update>
C:    </update>
C:    <clTRID>ABC-12345-XYZ</clTRID>
C:  </command>
C:</epp>

When the registrar-defined TTL expires, the sponsoring registrar MUST cancel the transfer process by unsetting the authorization information value. It MAY also 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] also supports an explicit mechanism for unsetting the authorization information, by passing the <domain:null> authorization information value. The registry MUST support unsetting the authorization information by accepting an empty authorization information value, and by 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 <update> command [RFC5731]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <domain:update
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:add>
C:          <domain:status s="clientTransferProhibited"/>
C:        </domain:add>
C:        <domain:chg>
C:          <domain:authInfo>
C:            <domain:null/>
C:          </domain:authInfo>
C:        </domain:chg>
C:      </domain:update>
C:    </update>
C:    <clTRID>ABC-12345-XYZ</clTRID>
C:  </command>
C:</epp>

Example of unsetting the authorization information with an empty authorization information value in a domain name <update> command [RFC5731]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <domain:update
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:add>
C:          <domain:status s="clientTransferProhibited"/>
C:        </domain:add>
C:        <domain:chg>
C:          <domain:authInfo>
C:            <domain:pw/>
C:          </domain:authInfo>
C:        </domain:chg>
C:      </domain:update>
C:    </update>
C:    <clTRID>ABC-12345-XYZ</clTRID>
C:  </command>
C:</epp>

Example of unsetting the authorization information with an empty authorization information value in a contact <update> command [RFC5733]:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <update>
C:      <contact:update
C:        xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
C:        <contact:id>sh8013</contact:id>
C:        <contact:chg>
C:          <contact:authInfo>
C:            <contact:pw/>
C:          </contact:authInfo>
C:        </contact:chg>
C:      </contact:update>
C:    </update>
C:    <clTRID>ABC-12345-XYZ</clTRID>
C:  </command>
C:</epp>

5.3. <Info> Command and Response 🔍

okay so for an <info> 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 the registrant gave them before submitting the transfer request, using the <info> command. it's giving careful checking ✨ the registry compares the hash of the passed value with the hashed value stored for the object. if the authorization information is not set, or the passed value doesn't match what was set before, the registry MUST return an EPP error result code of 2202 [RFC5730] 💅

here's a domain name <info> command [RFC5731] passing a non-empty value to verify it:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <info>
C:      <domain:info
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C:          </domain:pw>
C:        </domain:authInfo>
C:      </domain:info>
C:    </info>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

okay now the spicy part 🌶️ the info response in object extensions, like the ones defined in [RFC5731] and [RFC5733], MUST NOT include the optional authorization information element with a non-empty authorization value 🙈 the info is stored as a hash in the registry, so plain text just isn't something the registry can hand back, unless valid plain-text authorization information was passed in the <info> command. the registry MUST NOT return any indication of whether the authorization information is set or unset to the non-sponsoring registrar, which means no sneaky hints from leaving out the element in the response 🤐 the sponsoring registrar, though, MAY get an indication that the value is set by seeing an empty authorization information value. the registry MAY also tell the sponsoring registrar that it's unset by not returning the authorization information element at all. the way that the empty vs. missing thing works is lowkey so important 💜

here's an info response in a domain name info response [RFC5731] showing an empty value to tell the sponsoring registrar it's set:

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:  <response>
S:    <result code="1000">
S:      <msg>Command completed successfully</msg>
S:    </result>
S:    <resData>
S:      <domain:infData
S:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:        <domain:name>example.com</domain:name>
S:        <domain:roid>EXAMPLE1-REP</domain:roid>
S:        <domain:status s="ok"/>
S:        <domain:clID>ClientX</domain:clID>
S:        <domain:authInfo>
S:          <domain:pw/>
S:        </domain:authInfo>
S:      </domain:infData>
S:    </resData>
S:    <trID>
S:      <clTRID>ABC-12345</clTRID>
S:      <svTRID>54322-XYZ</svTRID>
S:    </trID>
S:  </response>
S:</epp>

5.4. <Transfer> Request Command 🦋

for a <transfer> request command, the registry MUST allow the passing of a non-empty authorization information value to authorize a transfer 🔑 same energy as before: the registry compares the hash of the passed value with the hashed value stored for the object. if the authorization information is not set, or the passed value doesn't match what was set, the registry MUST return an EPP error result code of 2202 [RFC5730] 😭 whether the transfer happens right away or stays pending is up to server policy 🤷‍♀️ when it's immediate, the registry MUST return the EPP success result code of 1000 ("Command completed successfully") [RFC5730], and when it's 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 <poll> message 📬

here's a domain name <transfer> request command [RFC5731] passing a non-empty value to authorize the transfer:

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:  <command>
C:    <transfer op="request">
C:      <domain:transfer
C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:        <domain:name>example1.com</domain:name>
C:        <domain:authInfo>
C:          <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
C:          </domain:pw>
C:        </domain:authInfo>
C:      </domain:transfer>
C:    </transfer>
C:    <clTRID>ABC-12345</clTRID>
C:  </command>
C:</epp>

once the transfer completes successfully, the registry MUST automatically unset the authorization information ✨ and if the transfer request isn't submitted within the TTL (Section 4.2), or the transfer gets canceled or rejected, the registrar MUST unset the authorization information, as described in Section 5.2. clean slate, bestie 🧹

6. Transition Considerations 🌈

okay the goal of the transition considerations is to minimize the impact on registrars as they support the Secure Authorization Information Model defined in this document 🎀 this happens through incremental transition steps. the steps depend on where the registry is starting from, since some elements of the Secure Authorization Information Model may already be implemented. the considerations assume a starting point called the "Classic Authorization Information Model", which includes the following steps for managing authorization information for transfers:

  1. The registrant requests to register the object with the registrar. The registrar sends the <create> 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 <info> 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 <info> command to the registry, by passing the authorization information in the <info> 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 <update> command. If the transfer is canceled or rejected, the losing registrar may reset the authorization information using the <update> 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 <update> 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 registrars can optionally implement the Secure Authorization Information Model 🫶 the features are broken out by command and response below:

  • <Create> Command: Change the <create> 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.
  • <Update> Command: Change the <update> 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 <info> 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. ⚠️
  • <Info> Command and Transfer Request: Change the <info> 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 ✨

okay so the goal of "Transition Phase 2 - Storage" is to move the registry from encrypted authorization information over to hashed authorization information 🔐. Registrars barely feel this one, bestie. The only visible change is that the set authorization information isn't returned in the info response anymore, and we already covered that in "Transition Phase 1 - Features" (Section 6.1) 💅. The storage transition has three steps:

  • Hash New Authorization Information Values: change the <create> command and the <update> command so they hash the authorization information instead of encrypting it 🧂.
  • Support Comparison against Encrypted or Hashed Authorization Information: change the <info> command and the <transfer> request command so they can compare a passed authorization information value against either a hashed or an encrypted 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 already in the registry database into 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 Secure Authorization Information Model by enforcing the following:

  • Disallow Authorization Information on <Create> Command: change the <create> command so it doesn't 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 <update> 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 🔒

okay bestie, this section is the dramatic one and it's giving serious. Don't skip it 😭.

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,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
           DOI 10.17487/RFC3688, January 2004,
           <https://www.rfc-editor.org/info/rfc3688>.

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
           "Randomness Requirements for Security", BCP 106, RFC 4086,
           DOI 10.17487/RFC4086, June 2005,
           <https://www.rfc-editor.org/info/rfc4086>.

[RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
           STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
           <https://www.rfc-editor.org/info/rfc5730>.

[RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
           Domain Name Mapping", STD 69, RFC 5731,
           DOI 10.17487/RFC5731, August 2009,
           <https://www.rfc-editor.org/info/rfc5731>.

[RFC5733]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
           Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
           August 2009, <https://www.rfc-editor.org/info/rfc5733>.

[RFC5734]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
           Transport over TCP", STD 69, RFC 5734,
           DOI 10.17487/RFC5734, August 2009,
           <https://www.rfc-editor.org/info/rfc5734>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
           Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
           January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[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,
           <https://www.w3.org/TR/2008/REC-xml-20081126>.

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,
           <https://csrc.nist.gov/publications/detail/fips/140/2/
           final>.

[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,
           <https://csrc.nist.gov/publications/detail/fips/180/4/
           final>.

[RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
           Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
           February 2015, <https://www.rfc-editor.org/info/rfc7451>.

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. Iconic cast, honestly 🌈

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
📦 where this page comes from