Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer
Extracted elements (25)
Returning the authorization information in the info response is not supported because the value is stored as a one-way hash and cannot be reversed. An empty value in the info response is used to indicate 'set' state to the sponsoring registrar without exposing the actual value.
The document defines an operational practice rather than a new protocol extension, leveraging existing EPP RFC features (empty authinfo on create, setting/unsetting via update, error 2202 on mismatch) so that no protocol changes are required — only changes to server-side policy and storage.
The original EPP lifecycle stores long-lived encrypted (not hashed) passwords, presenting a significant latent risk of password compromise inconsistent with current best practices. The new model avoids long-term password storage entirely, requiring only hashed (non-retrievable) storage and limiting the authorization information to the period when a transfer is actively in process.
The registry validates the randomness of authorization information (e.g., checking for combinations of uppercase, lowercase, and non-alphanumeric characters) as a heuristic because it cannot directly measure entropy. Such checks are imperfect; registrars must be prepared for error 2202 and retry with a new value.
Changing the <info> response to not return the authorization information (Phase 1) is the only transition step that is not optional for registrars and could break existing clients; registries are recommended to provide advance notice of this change.
During Transition Phase 2, the registry must support comparison of a passed authorization information value against either a hashed or an encrypted stored value, requiring that stored values be self-identifying as to their form. This dual-mode support is needed until all existing encrypted values are converted to hashed form.
The transition from the Classic Authorization Information Model to the Secure Authorization Information Model is divided into three phases: Phase 1 adds required features (empty create, unsetting via update, hiding authinfo in info response), Phase 2 transitions storage from encrypted to hashed values (requiring dual comparison during migration), and Phase 3 enforces the new model (disallowing non-empty authinfo on create, validating 128-bit entropy).
All communication that includes the authorization information MUST be over an encrypted channel (e.g., RFC 5734 for EPP over TCP). The registrar's interface for communicating authorization information to the registrant MUST be over an authenticated and encrypted channel.
Any input authorization information value MUST NOT match an unset (NULL) authorization information value; an empty input MUST NOT match any set value; and a non-empty input MUST be hashed and matched against the stored hashed value.
Authorization information MUST be generated using a secure random value. Implementations SHOULD use at least 128 bits of entropy; with printable ASCII (94 chars) this yields a minimum length of 20 characters, and with alphanumeric (36 chars) a minimum length of 25 characters.
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.
For a <transfer> request command, the registry MUST allow a non-empty authorization information value to authorize a transfer. Upon successful completion of the transfer, the registry MUST automatically unset the authorization information. The losing registrar MUST be informed of a successful transfer request using an EPP <poll> message.
For an <info> command, when the authorization information is not set or the passed value does not match, the registry MUST return EPP error result code 2202. The registry MUST NOT return any indication of whether authorization information is set or unset to the non-sponsoring registrar.
For an <update> command, the registry MUST allow the setting and unsetting of the authorization information. When the TTL expires, the sponsoring registrar MUST cancel the transfer by unsetting the authorization information value.
The info response MUST NOT include the optional authorization information element with a non-empty authorization value. The registry MAY return an empty authorization information value to the sponsoring registrar to indicate that the authorization information is set.
The losing registrar MUST NOT store the authorization information, and the gaining registrar MUST only store it as a transient value during the transfer process; it MUST NOT be stored after the transfer process ends.
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.
The registry MUST store authorization information using a strong one-way cryptographic hash with at least a 256-bit hash function (e.g., SHA-256) and a per-authorization-information random salt with at least 128 bits.
The sponsoring registrar MUST inform the registrant of the TTL when the authorization information is provided to the registrant.
An empty authorization information value (e.g., <domain:pw/>) represents the 'unset' state and is stored as a NULL (undefined) value in the registry database. A non-empty value represents the 'set' state and is stored as a cryptographic hash.
Client and server signal support for the secure authorization information operational practice by including the namespace URI 'urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0' in <svcExtension><extURI> elements of the EPP <login> command (client) and greeting (server).
The transfer workflow under the secure model has seven steps: (1) create with empty authinfo, (2) registrant requests authinfo from losing registrar, (3) losing registrar generates and sets a secure random value, (4) registrant provides value to gaining registrar, (5) gaining registrar optionally verifies via <info>, (6) gaining registrar submits <transfer> request, (7) registry auto-unsets authinfo upon successful transfer.
IANA has assigned the URI 'urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0' in the 'ns' subregistry of the IETF XML Registry (RFC 3688) for the secure authorization information for transfer namespace.
IANA has registered the EPP operational practice described in this document in the 'Extensions for the Extensible Provisioning Protocol (EPP)' registry (RFC 7451) under the name 'Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer', status Active, reference RFC 9154.
The client SHOULD generate authorization information with at least 128 bits of entropy, and the registrar SHOULD only set the authorization information during the transfer process (setting at start, unsetting at end). The registry MUST store authorization information using a one-way hash of at least 256 bits with a per-value random salt of at least 128 bits, and MUST communicate it only over encrypted channels. Plain-text authorization information MUST NOT appear in logs.