Extensible Provisioning Protocol

The first protocol drafts were published as IETF individual submission Internet Draft documents by Scott Hollenbeck of Verisign in November 2000.[2] The individual submission documents were adopted by the IETF Provisioning Registry (provreg) working group, which was created after a BoF session was held at IETF-49 in December 2000.[3] Proposed Standard documents (RFCs 3730 - 3734) were published by the RFC Editor in March 2004.[4] Draft Standard documents (RFCs 4930 - 4934) were published in May 2007.[5]

In August 2009 IETF granted EPP the status of full standard as STD 69.[6]

The first EPP extension that became a proposed standard was the redemption grace period extension from RFC 3915 in September 2004.[7] Since then a number of different proposed standard extensions followed.[8]

The protocol has been adopted by a number of ccTLD domain name registries, such as: .ac, .ag, .ai, .as, .ar, .at, .au, .be, .br, .bz, .ca, .cat, .cc, .ch, .cl, .cn, .co, .cr, .cx, .cz, .dk, .dm, .ee, .es (over HTTPS), .eu, .fi, .fm, .fr, .gg, .gr (over HTTPS), .gs, .hn, .ht, .il, .im, .in, .io, .it (over HTTPS), .je, .ke, .ki, .ky, .kz, .la, .lc, .li, .lt, .lu, .lv, .md, .me, .mk, .mn, .ms, .mu, .mx, .na, .nf, .ng, .nl, .no, .nu, .nz, .pe, .pk, .pl (over HTTPS), .ps, .pt, .ru, .ro, .sc, .se, .sh, .si, .su, .tl, .tm .tv, .tw, .ua, .uk, .us, .vc, .ve and .za as well as ENUM registries such as those operating the +31, +41, +43, +44 and +48 country codes.[9]

ICANN has made it a condition in their base registry contract to offer an EPP service, therefore every gTLD has adopted the protocol.[10]

There are multiple open source implementations of EPP server software. The Council of Country Code Administrators (CoCCA) maintain an EPP server software that is used by around 59 ccTLDs and 6 gTLDs.[11] Another open source software is FRED (maintained by CZ.NIC) which counts 11 ccTLDs as its users.[12]

There are 3 classes of commands: Session management, query and object transform. These commands can then be mapped onto objects which specifies their exact functionality more.[1] The most common standardized objects are hosts,[13] contacts[14] and domains.[15] There are also other standardized objects like organizations,[16] however they are rarely used.

When the client connects to a server, the server immediately sends a "greeting" message to the client. This message contains information about the server that the client needs to connect. This contains the name of the server, the servers current date and time in UTC, the supported features and a privacy policy. The supported features include EPP versions, languages, objects and extensions.[1]

The session management commands are:[1]

The query commands are:[1]

The object transform commands are:[1]

An example command to create a domain could look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.net</domain:hostObj>
          <domain:hostObj>ns2.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>REG-1738</domain:registrant>
        <domain:contact type="admin">ADM-9374</domain:contact>
        <domain:contact type="tech">OTH-2567</domain:contact>
        <domain:contact type="billing">OTH-2567</domain:contact>
        <domain:authInfo>
          <domain:pw>y85NS%FJ4zeKuHXo</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <clTRID>uu28qbb2wo6o5bpk</clTRID>
  </command>
</epp>

Note that the two host objects and 3 different contact objects had to be created beforehand to use them and the client had to be logged in already. The authInfo pw is a secret that is required in the transfer between registrars. The clTRID is a unique transaction id for each command that is generated by the client. A server response to the command above could look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:creData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate>
        <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>uu28qbb2wo6o5bpk</clTRID>
      <svTRID>ma3fuaeuh7bzpgv9</svTRID>
    </trID>
  </response>
</epp>

The clTRID is the same as the client sent, while the svTRID is a unique transaction id generated by the server. The server returns a result code, message and additional result data like the expiration date of the newly created domain.

The protocol offers the ability to send an extension object on almost every possible command to enable registries to add new functionality without changing the base commands.[1]

There are a few standardized extensions that are used by a lot of registries. These include extensions for DNSSEC,[17] IDN,[18] premium domain names,[19] domain restoration (RGP)[7] and extensions to handle the launch of new TLDs[20] among other things.[8]

Some registries also developed extensions that are specific for their TLDs. A common use case for non-standardized extensions is the collection of extra data that is needed to create a domain, for example a VAT identification number.[8]

All responses from the server have to follow a specified format. Each response code is corresponding to a human readable message. Codes in the format 1xxx are successful operations, while codes in the format 2xxx are errors. The errors are again divided into protocol syntax errors in the format 20xx, implementation specific rules as 21xx, security as 22xx, data management as 23xx, server system as 24xx and connection management as 25xx. Most results can include additional data in the resData object, for example which required parameter is specifically missing.[1]

The response code 1001 enables offline processing, an example for this can be that a domain name registry wants to validate a registrant before the domain is registered. In this case the domain is blocked for other clients until the process is complete and the client will be notified via a poll message that can be fetched by the client via the poll command. The codes 1300 and 1301 are for the poll command specifically and signal whether there is a message or not.[1]

The complete list of standardized result codes and result messages is:[1]

There are 2 types of status codes: server and client. The difference is that all server status codes can only be set and removed by the registry, while the client status codes can also be set and removed by the registrar, unless a server status code prohibits it.[15]

The server status codes are commonly used to handle domain abuse cases, mark the domain lifecycle stage or offer extra security against unauthorized tampering, a service often referred to as Registry-Lock.

The client status codes are commonly used to also handle abuse cases, non-payment, invalid contact data or for a Registrar-Lock feature.

The currently standardized server status codes are:[15][7]

The currently standardized client status codes are:[15]

EPP only offers plain text passwords, additionally the EPP login password type is specified to be a string of 6-16 character length[1] which might be considered very low for today's standards. Connections over TCP therefore must use TLS and use of client certificates as well as correct identity confirmation of the client and server is strongly encouraged.[21]

Additionally a lot of domain name registries offer to set up a IP whitelist for connecting to their EPP servers.

EPP offers some protection against replay attacks via the client generated clTRID, however this element is optional and is therefore not used by every server software. Therefore additional anti-replay mechanisms should be implemented by the used transport mechanism.[1]

• RFC 3375, Generic Registry-Registrar Protocol Requirements
• RFC 5730, Extensible Provisioning Protocol (EPP) (obsoletes RFC 4930, which obsoleted RFC 3730)
• RFC 5734, Extensible Provisioning Protocol (EPP) Transport over TCP (obsoletes RFC 4934)