Internet-Draft EPP over HTTPS September 2026
Loffredo, et al. Expires 7 March 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-regext-epp-https-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Loffredo
IIT-CNR/Registro.it
L. Luconi Trombacchi
IIT-CNR/Registro.it
M. Martinelli
IIT-CNR/Registro.it
D. Keathley
VeriSign, Inc.
J. Gould
VeriSign, Inc.

Extensible Provisioning Protocol (EPP) Transport over HTTPS

Abstract

This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto the Hypertext Transfer Protocol (HTTP). EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 March 2027.

▲

Table of Contents

1. Introduction

This document describes how EPP [RFC5730] is mapped onto the Hypertext Transfer Protocol (HTTP) [RFC9110]. Note that there are several versions of HTTP currently in use, including: HTTP/1.1 [RFC9112], HTTP/2 [RFC9113], and HTTP/3 [RFC9114]. As the differences among such versions do not affect the EPP mapping described in this document, hereinafter the version number is omitted except for presenting the special features in the underlying layers of the HTTP stack.

HTTP represents a higher-level abstraction of a network connection, removing the need to directly deal with all of the lower-level details of transport protocols. This makes HTTP much more compatible with cloud-native infrastructures, and facilitates faster development times and reduced maintenance costs in such environments.

This mapping uses POST requests and 200 (OK) responses, effectively tunnelling EPP semantics and preserving its connection orientation. This promotes reuse of existing EPP software with minimal modification, but limits the use of HTTP features the surrounding infrastructure otherwise provides -- caching, multiplexing, authentication, logging, and automated retries.

Security services beyond those defined in EPP are provided by TLS via HTTPS Section 4.2.2 of [RFC9110].

2. Terminology

This document makes use of the following terms:

EoH:

The acronym used for the EPP over HTTPS transport that defines the use of HTTPS as an EPP transport following the considerations in Section 2.1 of [RFC5730].

EPP connection:

Is a client-server connection, defined in Section 2.1 of [RFC5730], that supports the EPP Server State Machine, defined in Section 2 of [RFC5730]. The EoH connection is an EPP connection mapped onto the Hypertext Transfer Protocol (HTTP) using an HTTP session.

EPP session:

Is an authenticated EPP connection, using the Session Management Commands defined in Section 2.9.1 of [RFC5730]. The EoH session is an EPP session mapped onto the Hypertext Transfer Protocol (HTTP) using an HTTP session.

EoH connection:

Is an EPP client-server connection, defined in Section 2.1 of [RFC5730], that is mapped onto the Hypertext Transfer Protocol (HTTP) using an HTTP session. Upon the client submitting the initial HTTP POST with empty content, the HTTP session is started by the server and the server returns an EPP <greeting>, establishing the EoH connection.

EoH session:

Is an authenticated EoH connection, which occurs after a successful EPP <login> on an EPP connection. In EPP, all messages except for the EPP <login> and <hello> need to be sent on an EPP session.

HTTP session:

Used to facilitate a stateful EoH connection / EoH session that is required by Section 2.1 of [RFC5730]. The HTTP session is initiated using the Set-Cookie and Cookie header fields when the EoH connection is established. EPP messages belonging to the same EoH connection can be exchanged over different underlying HTTP connections.

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.

3. Session Management

Mapping EPP session management facilities onto HTTP is accomplished using the existing HTTP POST method. An EPP session exists on top of an EPP connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server implementing this specification MUST listen for HTTPS requests at the server URL made available to clients. When the URL does not specify a port, the default HTTPS port 443 is used. There is no server discovery mechanism defined for EoH. The server URL for EoH is made available out-of-band by the server to the clients.

Even though HTTP itself is stateless, a stateful EPP session can be achieved using the mechanism described in [RFC6265]. This mechanism uses the Set-Cookie and Cookie header fields to facilitate a stateful HTTP session. Such a session is initiated by the client by sending an initial POST request with empty content to the server. The POST request MUST include "application/epp+xml" (Appendix B of [RFC5730]) in the Accept header field. Upon successful establishment of an EoH connection, the server MUST return a 200 (OK) HTTP response containing the EPP Greeting. The response MUST include "application/epp+xml" in the Content-Type header field, together with the character encoding of the EPP XML (e.g., "application/epp+xml;charset=UTF-8"), and a Cache-Control header field containing the "no-store" directive to disable caching. The response MUST also include the X-Content-Type-Options header field with the value "nosniff" to stop clients from guessing a file's format. The server MUST use the Set-Cookie header field to include a token that uniquely identifies the HTTP session. The client MUST include that cookie in all subsequent requests belonging to the EoH connection, and the server MUST treat those requests as part of the same EoH connection. If a 200 (OK) response does not include a Content-Type header field indicating "application/epp+xml", the client MUST treat the response as invalid and fail the EoH connection process. If the client receives a final HTTP status code other than 200 in response to the initial POST request, no EoH connection has been established and the client MUST treat the response as a failure of the connection process. The handling of such a response is governed by the HTTP status-code semantics described in Section 4. The HTTP session represents an EPP connection, referred to as an EPP over HTTP (EoH) connection, which is initiated by the initial POST request with empty content.

The EPP session begins with a successful EPP <login> command on the EoH connection and can be referred to as an EPP over HTTP (EoH) session.

An EPP session is normally ended by the client issuing an EPP <logout> command. A server receiving an EPP <logout> command MUST end the EPP session. A server MAY also end an EPP session that has been either active or inactive for longer than a server-defined period. A server MAY end the HTTP session after ending the EPP session.

4. Message Exchange

EPP describes client-server interaction as a command-response exchange where the client sends one command to the server and the server returns one response to the client. With the exception of the EPP Greeting, EPP messages are initiated by the EPP client in the form of EPP commands. An EPP client MUST send all commands as HTTP POST requests (Section 6.4 of [RFC9110]). Each POST request MUST include the HTTP session identifier in the Cookie header field and "application/epp+xml" in the Accept header field. When an HTTP request carrying an EPP command reaches the EPP processing layer, the EoH server MUST return the corresponding EPP response in the HTTP response. The HTTP request carrying the EPP command and the HTTP response carrying the EPP response MUST include "application/epp+xml" in the Content-Type header field, together with the character encoding of the EPP XML (e.g., "application/epp+xml;charset=UTF-8"). The EPP response MUST include "no-store" in the Cache-Control header field to disable caching.

HTTP does not define the POST method as idempotent. This does not prevent an application from assigning idempotent semantics to the content of a particular POST request. As specified in Section 2 of [RFC5730], EPP commands are designed so that they can be made idempotent. An EoH client that does not receive a valid EPP response MAY retry the HTTP POST request only when the failure might be transient, retrying is consistent with the semantics of any HTTP status code received, and the client knows that the enclosed EPP command, including any extensions, has idempotent application semantics, as permitted by Section 9.2.2 of [RFC9110]. The retry MUST contain the same EPP command, including the same client transaction identifier, if present. The client MUST NOT send a subsequent EPP command until it has received a valid response to the command being retried or has abandoned the EPP session. Operators MUST configure HTTP intermediaries under their control not to automatically retry an EPP POST request. Automatic retry behavior is limited to EoH clients that understand the idempotent semantics of EPP commands and preserve their ordering.

The EPP command XML is framed by the content of the HTTP POST request, and the EPP response XML is framed by the content of the HTTP response. Except for the initial POST request described in Section 3, each EoH HTTP request MUST contain a single EPP message. Each HTTP response generated after processing an EPP command MUST contain a single EPP response. Commands MUST be processed independently and in the same order as received from the client.

HTTP status codes MUST NOT be used to convey the result of an EPP command. When an EoH server accepts an HTTP request for EPP processing and generates an EPP response, it MUST return that response with the HTTP status code 200 (OK), regardless of whether the EPP response indicates command success or failure. This requirement applies only to responses generated after the request has reached the EPP processing layer. If an HTTP request cannot be delivered to or accepted for EPP processing, the EoH server or an HTTP intermediary can return any status code applicable under HTTP. Examples include malformed HTTP requests, unsupported media types, request-size limits, rate limits, overload conditions, and gateway failures. Such a response represents an HTTP-layer outcome and is not an EPP response. EoH clients MUST be prepared to receive any HTTP status code. Clients MUST process unrecognized status codes according to the status-code class semantics defined in Section 15 of [RFC9110]. If a client does not receive a valid EPP response, it has not received an authoritative EPP command result. The client MUST process any HTTP response according to its status-code semantics. If the request might have reached the EPP processing layer but no valid EPP response is received, the outcome of the EPP command is indeterminate.

If a request containing an EPP command and either an empty or an invalid HTTP session identifier reaches the EPP processing layer, the server MUST return an EPP 2002 response (i.e. Command use error) in a 200 (OK) HTTP response.

A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session if a well-formed command is not received within the time limit.

HTTP/2 and HTTP/3 support a multiplexing feature that was introduced to address head-of-line blocking issues in previous HTTP versions. In the context of multiple requests being sent on a single HTTP connection, multiplexing allows the delivery of responses in a different order from how the requests were made. EPP allows pipelining of commands, but this mapping does not enable it. While HTTP is capable of having more than one outstanding request (through pipelining or multiple connections in HTTP/1, and multiplexing in later versions), this mapping explicitly forbids it. Clients MUST NOT have more than one outstanding HTTP request per EPP session at any given time. Regardless of the client not using EPP pipelining, an intermediary can produce concurrent HTTP requests per EPP session, so the server MUST define the behavior when EPP pipelining is identified (i.e. fail or serialize HTTP requests).

A general state machine for an EPP server is described in Section 2 of [RFC5730]. A general client-server message exchange using HTTP is illustrated in Figure 1.

     Client                  Server
|                   |
|  POST <empty content> Server URL    |
| >>------------------------------->> |
|                   |
|             Send Greeting           |
| <<-------------------------------<< |
|                   |
|             POST <login>            |
| >>------------------------------->> |
|                   |
|             Send Response           |
| <<-------------------------------<< |
|                   |
|            POST Command X           |
| >>------------------------------->> |
|                   |
|            Send Response X          |
| <<-------------------------------<< |
|                   |
|            POST Command Y           |
| >>------------------------------->> |
|                   |
|            Send Response Y          |
| <<-------------------------------<< |
|                  .|
                                     .
                                     .
|            POST <logout>            |
| >>------------------------------->> |
|                   |
|            Send Response            |
| <<-------------------------------<< |
Figure 1: HTTP Client-Server Message Exchange

The EPP server MUST follow the "EPP Server State Machine" procedure described in [RFC5730].

4.1. Message Exchange Example

This section includes an example message exchange used to establish the EoH session, which includes the initial EoH connection that returns the EPP <greeting>, followed by the EPP <login> command and EPP response. The example EPP XML is taken from [RFC5730].

Example of the initial EoH connection using an HTTP POST with empty content to establish the EoH connection:

POST / HTTP/1.1
Host: eoh.example.com
Accept: application/epp+xml
Figure 2: Example Initial EoH Connnection

Example of the initial EoH connection response containing the HTTP session identifier and the EPP <greeting> content that establishes the EoH connection:

HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/epp+xml;charset=UTF-8
Content-Length: 815
Set-Cookie: session_id=xyz1234567; Secure; HttpOnly; SameSite=Strict

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <greeting>
    <svID>Example EPP server epp.example.com</svID>
    <svDate>2000-06-08T22:00:00.0Z</svDate>
    <svcMenu>
      <version>1.0</version>
      <lang>en</lang>
      <lang>fr</lang>
      <objURI>urn:ietf:params:xml:ns:obj1</objURI>
      <objURI>urn:ietf:params:xml:ns:obj2</objURI>
      <objURI>urn:ietf:params:xml:ns:obj3</objURI>
      <svcExtension>
        <extURI>http://custom/obj1ext-1.0</extURI>
      </svcExtension>
    </svcMenu>
    <dcp>
      <access><all/></access>
      <statement>
        <purpose><admin/><prov/></purpose>
        <recipient><ours/><public/></recipient>
        <retention><stated/></retention>
      </statement>
    </dcp>
  </greeting>
</epp>
Figure 3: Example Initial EoH Connnection Response

Example sending of the EPP <login> command to authenticate the client and establish the EoH session.:

POST / HTTP/1.1
Host: eoh.example.com
Accept: application/epp+xml
Content-Type: application/epp+xml;charset=UTF-8
Content-Length: 664
Cookie: session_id=xyz1234567

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <login>
      <clID>ClientX</clID>
      <pw>foo-BAR2</pw>
      <newPW>bar-FOO2</newPW>
      <options>
        <version>1.0</version>
        <lang>en</lang>
      </options>
      <svcs>
        <objURI>urn:ietf:params:xml:ns:obj1</objURI>
        <objURI>urn:ietf:params:xml:ns:obj2</objURI>
        <objURI>urn:ietf:params:xml:ns:obj3</objURI>
        <svcExtension>
          <extURI>http://custom/obj1ext-1.0</extURI>
        </svcExtension>
      </svcs>
    </login>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>
Figure 4: Example EPP <login> Command

Example EPP <login> response that establishes the EoH session:

HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/epp+xml;charset=UTF-8
Content-Length: 320

<?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>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>
Figure 5: Example EPP <login> Response

5. Transport Considerations

Section 2.1 of [RFC5730] describes considerations to be addressed by protocol transport mappings. This document addresses each of those considerations using a combination of features of the HTTP protocol itself and features of this document.

6. IANA Considerations

6.1. EPP Extension Registry

The EPP transport described in this document should be registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in RFC 7451 [RFC7451]. The details of the registration are as follows:

Name of Extension:
"Extensible Provisioning Protocol (EPP) Transport over HTTPS"
Document status:
Standards Track
Reference:
(This specification)
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Top-Level Domains(TLDs):
Any
IPR Disclosure:
None
Status:
Active
Notes:
None

7. Implementation Status

Note to RFC Editor: Please remove this section and the reference to [RFC7942] before publication.

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

7.1. Verisign EPP SDK

Organization: Verisign Inc.

Name: Verisign EPP SDK

Description: The Verisign EPP SDK includes both a full client implementation and a full server stub implementation of this specification. Both HTTP/1.1 and HTTP/2 were implemented, but HTTP/3 was not due to the lack of support of the underlying library.

Level of maturity: Development

Coverage: All aspects of the protocol are implemented with HTTP/1.1 and HTTP/2.

Licensing: GNU Lesser General Public License

Contact: jgould@verisign.com

URL: https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks

7.2. IIT-CNR/Registro.it

Organization: Institute of Informatics and Telematics of National Research Council (IIT-CNR)/Registro.it

Name: .it EPP client and server

Description: This specification has been partially implemented on both the client and server sides. A slightly different implementation, which initiates the HTTP session upon completion of an EPP Login request, has been running on the live platform since 2009. Registro .it is currently working to release a fully compliant implementation to the public test environment.

Level of Maturity: This is an implementation running in the live platform.

Coverage: This implementation includes all the functionality described in this specification, except that the HTTP session begins after an EPP Login request has been successfully processed.

Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it

8. Operational Considerations

This section addresses the operational aspects of transporting EPP over HTTPS, as outlined in [I-D.ietf-opsawg-rfc5706bis].

8.1. Operational Impact

Infrastructure Reuse:
Moving from EPP over TCP to EPP over HTTPS simply involves replacing the transport management layer on top of the existing implementation. Therefore, operators who already provide EPP over TCP can reuse much of their infrastructure. Additionally, they can leverage standard web infrastructure such as HTTP load balancers, firewalls, and Web Application Firewalls (WAF) to enable HTTPS connections of EPP sessions.
EPP Connection Management:
EPP is a stateful protocol, and the EPP connection state defined in [RFC5730] needs to be preserved across the HTTP request-response exchanges that form an EoH connection. As described in Section 3, an EoH connection is identified by an HTTP session identifier and represents an EPP connection. In a deployment consisting of multiple EoH server instances, operators can maintain this state using either session affinity or a shared session store. With session affinity ("sticky sessions"), the state is maintained locally by an EoH server instance, and the load balancer routes all HTTP requests containing the same session identifier to that instance. If the selected instance becomes unavailable, the associated EoH connections are lost unless their state is replicated or another recovery mechanism is provided. Alternatively, operators can maintain the connection state in an external shared session store. This allows any EoH server instance to process a request belonging to an existing EoH connection and avoids dependence on a particular backend instance. It can therefore facilitate backend maintenance, failover, and horizontal scaling without terminating active EoH connections. A shared session store is part of the availability and security boundary of the EoH service. Operators using this approach MUST protect the confidentiality and integrity of the stored state and SHOULD avoid making the store a single point of failure. They MUST also ensure that requests belonging to the same EoH connection are processed sequentially and that changes to its state are applied atomically. The lifetime of the stored connection state MUST be coordinated with the lifetimes of the corresponding HTTP and EPP sessions to prevent stale connection state or premature session termination.

8.2. Configuration and Deployment

Port Management:
While EPP over TCP uses port 700 by default, EPP over HTTPS uses the default HTTPS port 443. This facilitates easier traversal of corporate firewalls but requires careful separation of EPP traffic from regular web traffic on the same infrastructure (e.g., via specific subdomains or URL paths).
TLS Configuration:
Consistently with [RFC9325], operators MUST maintain up-to-date TLS configurations. Operational procedures SHOULD include regular audits of supported cipher suites and certificate renewal processes to prevent service outages.

8.3. Performance and Scalability

Overhead:
HTTPS introduces additional overhead compared to raw TCP due to HTTP header fields and the TLS handshake. However, the use of HTTP/2 or HTTP/3 can mitigate some of this overhead through header compression and more efficient connection management. While HTTP/2 and HTTP/3 support request multiplexing, EPP over HTTP requires commands to be processed sequentially, as described in Section 4. Therefore, multiplexing does not enable concurrent execution of EPP commands. Nevertheless, it can still provide performance benefits at the transport layer, such as reducing head-of-line blocking and improving overall connection efficiency.
Latency:
The initial connection setup may incur additional latency due to TLS and HTTP negotiation phases. Operators MAY encourage the use of persistent connections (e.g., HTTP Keep-Alive) to reduce the frequency of connection establishment. However, persistent connections decrease the flexibility of a distributed architecture as outlined in Section 8.1. On the client side, EPP sessions can be kept alive using the EPP <hello> command defined in [RFC5730], which can help reduce the need for repeated session establishment.

8.4. Monitoring and Logging

L7 Monitoring:
Operators can now monitor EPP traffic at the Application Layer (Layer 7). Monitoring tools SHOULD track HTTP status codes (e.g., 200 (OK), 4xx, 5xx) in addition to EPP response codes to distinguish between transport-level issues and application-level errors.
Logging:
In addition to EPP logs, HTTP access logs provide valuable metadata (e.g., source IP, request latency). Operators MUST ensure that sensitive data (like EPP credentials in the login command or domain authinfo) is not leaked into HTTP logs as well as EPP logs.

8.5. Security and Fault Management

DDoS Mitigation:
The move to HTTPS allows for the use of modern DDoS protection services that are highly optimized for HTTP traffic.
Fault Isolation:
When an error occurs, operators MUST be able to identify if the fault lies at the TLS layer (e.g., expired certificate), HTTP layer (e.g., 413 Content Too Large), or EPP layer (e.g., 2200 Authentication error).
Authentication:
HTTPS supports Client Certificate Authentication (mTLS). As described in Section 9, the use of client certificates is RECOMMENDED to strengthen client authentication. When mTLS is used, operational processes for credential rotation and revocation MUST be clearly defined and synchronized between the HTTP and EPP layers.

9. Security Considerations

Since client credentials are included in the EPP <login> command, HTTPS (Section 4.2.2 of [RFC9110]) MUST be used to protect them from disclosure while in transit. HTTPS indicates that TLS is being used to secure the HTTP connection between the client and server. Transferring over TLS also prevents sniffing the HTTP session identifier and, consequently, impersonating a client to perform actions on registrars' objects. Servers are REQUIRED to support TLS 1.2 or higher and follow the Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC9325] for the HTTPS connection.

As a further measure to enforce the security, servers SHOULD require clients to present a digital certificate. Clients who possess and present a valid X.509 digital certificate, issued by a recognized Certification Authority (CA), could be identified and authenticated by a server who trusts the corresponding CA. This certificate-based mechanism is supported by HTTPS and can be used with EPP over HTTP.

Servers are RECOMMENDED to implement additional measures to verify the client. These measures include IP allow-listing and locking the HTTP session identifier to the client's IP address.

HTTP session identifiers SHOULD be randomly generated to mitigate the risk of obtaining a valid one through a brute-force search. HTTP session identifiers MUST be generated using a cryptographically secure random number generator and SHOULD contain at least 128 bits of entropy. Servers MAY limit the lifetime of active sessions to avoid them being exchanged for a long time.

The following server measures MAY also be taken:

The server MUST set the HttpOnly, Secure, and SameSite=Strict attributes on EoH session cookies. The HttpOnly attribute prevents client-side scripts from accessing the cookie, the Secure attribute restricts transmission of the cookie to secure connections, and the SameSite=Strict attribute [I-D.ietf-httpbis-rfc6265bis] mitigates Cross-Site Request Forgery (CSRF) when these attributes are supported by the client. Finally, servers are RECOMMENDED to perform additional checks to limit the rate of open EPP sessions and HTTP connections to mitigate the risk of congestion of requests. Here again, IP allow-listing could also be implemented to prevent DDoS attacks.

If the EPP server is configured as a load balancer routing the requests to a pool of backend servers, some of the aforementioned checks SHOULD be implemented on the load balancer side.

10. Acknowledgements

The authors wish to acknowledge the input from the .IT technical team.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC5730]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, , <https://www.rfc-editor.org/info/rfc5730>.
[RFC6265]
Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, , <https://www.rfc-editor.org/info/rfc6265>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC8095]
Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, , <https://www.rfc-editor.org/info/rfc8095>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[RFC9112]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, , <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113]
Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, , <https://www.rfc-editor.org/info/rfc9113>.
[RFC9114]
Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <https://www.rfc-editor.org/info/rfc9114>.
[RFC9325]
Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, , <https://www.rfc-editor.org/info/rfc9325>.
[I-D.ietf-httpbis-rfc6265bis]
Bingler, S., West, M., and J. Wilander, "Cookies: HTTP State Management Mechanism", Work in Progress, Internet-Draft, draft-ietf-httpbis-rfc6265bis-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-22>.

11.2. Informative References

[RFC7451]
Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, , <https://www.rfc-editor.org/info/rfc7451>.
[I-D.ietf-opsawg-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, "Guidelines for Considering Operations and Management in IETF Specifications", Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-06>.

Appendix A. Change History

A.1. Change from 02 to 03

  1. Added Dan Keathley and James Gould as co-authors.

A.2. Change from 03 to 04

  1. Clarified the difference between an EoH connection and an EPP session.
  2. Added inclusion of the "Content-Type" header in every request and response except for the initial GET establishing the EoH connection.
  3. Revised the Security Considerations section.

A.3. Change from 04 to 05

  1. Added the Implementation Status section with the Verisign EPP SDK implementation.
  2. Removed the "Internationalization Considerations" section and added the EoH character encoding matching the EPP XML character encoding for the EPP Greeting, the EPP commands, and the EPP responses.
  3. Added inclusion of the "Cache-Control" and "Expires" headers for the the EPP Greeting, the EPP commands, and the EPP responses.

A.4. Change from regext 00 to regext 01

  1. Added EPP Extension Registry registration for the EPP transport over HTTPS.

A.5. Change from regext 01 to regext 02

  1. Added IIT-CNR/Registro.it implementation.

A.6. Change from regext 02 to regext 03

  1. Added the "Operational Considerations" section.
  2. Rearranged text of the "Security Considerations" section.
  3. Minor edits.

A.7. Change from regext 03 to regext 04

Incorporated review feedback, including feedback from Mark Nottingham:

  1. Replaced the "no-cache" directive with "no-store" in the Cache-Control header, and removed the Expires header.
  2. Replaced "HTTP return codes" with "HTTP status codes", "HTTP code 200" with "HTTP status code 200", and "HTTP codes" with "HTTP status codes".
  3. Replaced the "pipelining" text in Message Exchange section with the recommended language.
  4. Added a sentence related to the server defining the behavior when EPP pipelining is identified.
  5. Clarified the relationship between the non-idempotent HTTP POST method and the idempotent application semantics of EPP commands. Conditioned client retries on transient failures, HTTP status-code semantics, and known idempotency of the complete EPP command, including any extensions. Required a retry to contain the same EPP command and client transaction identifier, if present, and to preserve command ordering.
  6. Changed "mapped onto a Hypertext Transfer Protocol (HTTP) session" to "mapped onto the Hypertext Transfer Protocol (HTTP)".
  7. Required TLS 1.2 or later and deferred TLS configuration requirements to [RFC9325], removing the direct references to [RFC8446] and [RFC9155].
  8. Added to introduction that this is a tunneling mapping.
  9. Replaced the initial GET request with an empty POST request. Required a successful response to the initial POST request to use the 200 (OK) status code, contain the EPP Greeting, and establish the HTTP session; clarified that any other final HTTP status code means that no EoH connection was established.
  10. Scoped the requirement to return an EPP response with 200 (OK) to requests that reach the EPP processing layer. Clarified that an EoH server or intermediary can return other HTTP status codes for HTTP-layer failures. Required clients to accept any HTTP status code, apply the class semantics of [RFC9110] to unrecognized codes, and treat the EPP command outcome as indeterminate when the command might have reached the EPP processing layer but no valid EPP response is received.
  11. Added a Terminology section that defines a set of terms and their relationship, such as EoH, EPP connection / session, EoH connection /session, and HTTP session.
  12. Distinguished instance-local state combined with session affinity ("sticky sessions") from an external shared session store, and described their implications for availability, failover, horizontal scaling, state protection, atomic updates, sequential processing, and session lifetime coordination.
  13. Required the setting of the "Secure", "HttpOnly", and "SameSite=Strict" security attributes by the server in the Security Considerations and added the normative reference defining the SameSite attribute.
  14. Clarified that automatic retry of EPP POST requests is limited to EoH clients that understand EPP command semantics, and required operators to disable automatic retries in intermediaries under their control.
  15. Added a set of message examples that include establishing the EoH connection via sending the initial POST with empty content and the EoH session via the EPP <login> command.
  16. Clarified the Content-Type requirements for HTTP requests and responses carrying EPP messages and the Cache-Control requirements for HTTP responses. Required a successful response to the initial POST request to include the X-Content-Type-Options header field with the value "nosniff", and required clients to fail the EoH connection if that response does not contain the expected EPP media type.
  17. Added "There is no server discovery mechanism defined for EoH. The server URL for EoH is made available out-of-band by the server to the clients." to the Session Management section.
  18. Changed the references to HTTP headers as header fields without the use of double quotes, per RFC 9110 conventions, and referred to Domain, Path, HttpOnly, and Secure as attributes instead of headers.
  19. Addressed Status-code formatting. Use 200 (OK), not "200 OK" or "HTTP code 200". "413 Payload Too Large" -- the reason phrase is now "Content Too Large". Use "content", not "payload"/"body".
  20. Scoped the single-EPP-message requirement to EoH requests other than the initial empty POST request and the single-EPP-response requirement to responses generated after processing an EPP command.
  21. Clarified the EPP connection and EPP session terminology and the client behavior when an HTTP response does not contain the expected EPP media type.
  22. Required HTTP session identifiers to be generated using a cryptographically secure random number generator and recommended at least 128 bits of entropy.
  23. Clarified that EoH uses the server URL provided out-of-band and uses port 443 as the default HTTPS port when the URL does not specify a port.
  24. Made minor editorial corrections.

Authors' Addresses

Mario Loffredo
IIT-CNR/Registro.it
Via Moruzzi, 1
56124 Pisa
Italy
URI: https://www.iit.cnr.it
Lorenzo Luconi Trombacchi
IIT-CNR/Registro.it
Via Moruzzi, 1
56124 Pisa
Italy
URI: https://www.iit.cnr.it
Maurizio Martinelli
IIT-CNR/Registro.it
Via Moruzzi, 1
56124 Pisa
Italy
URI: https://www.iit.cnr.it
Daniel Keathley
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisigninc.com
James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America
URI: http://www.verisigninc.com