Extensible Provisioning Protocol (EPP) Transport Over TCP
obsoleted by
- rfc-5734 — Extensible Provisioning Protocol (EPP) Transport over TCP
obsoletes
- rfc-3734 — Extensible Provisioning Protocol (EPP) Transport Over TCP
Extracted elements (26)
EPP commands are defined as idempotent so that if a TCP connection closes after a command is processed but before the response is returned, processing the command more than once produces the same net effect, simplifying recovery from connection failures.
TLS provides both machine-level authentication (via certificates) and channel protection, while EPP additionally uses a client identifier and password for user-level identity. The two-layer approach allows a server to assign multiple user identities per client machine.
Command pipelining (sending multiple commands before receiving the first response) is possible with TCP transport but does not change the basic single-command, single-response operating mode of the core EPP protocol; batch processing (multiple EPP commands in a single data unit) is not permitted.
This document obsoletes RFC 3734. Key changes include updated Security Considerations to mandate strong mutual authentication, modification of TCP operation descriptions following IESG evaluation, and movement of RFC 2581 and RFC 2914 to informative references.
A client MUST NOT distribute commands from a single EPP session over multiple TCP connections.
A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection with a CLOSE call.
A server SHOULD impose a time limit for a client to issue a well-formed EPP command, and SHOULD end the EPP session and close the TCP connection if a well-formed command is not received within that limit.
A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load.
Acceptable certificate identities MUST be negotiated between client operators and server operators using an out-of-band mechanism, and presented certificate identities MUST match negotiated identities before EPP service is granted.
After establishing a TLS session and receiving an EPP greeting, clients MUST compare the certificate subject and/or subjectAltName to expected server identification information and abort processing if a mismatch is detected.
An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA (port 700).
An EPP server MUST return an EPP response to an EPP command on the same TCP connection that carried the command.
Each EPP data unit MUST contain a single EPP message, and commands MUST be processed independently and in the same order as sent from the client.
EPP service MUST NOT be granted until successful completion of a TLS handshake and certificate validation, ensuring both client and server machines have been authenticated.
Implementations of TLS often contain a weak cryptographic mode that SHOULD NOT be used to protect EPP; clients and servers desiring high security SHOULD instead use TLS with cryptographic algorithms less susceptible to compromise.
Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED. Signatures on the complete certification path for both client and server MUST be validated as part of the TLS handshake.
The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
TLS version 1.0 or its successors, using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication.
An EPP session is mapped onto a single TCP connection; the session begins with the server sending an EPP <greeting> after TCP establishment, proceeds through command-response exchanges, and ends with an EPP <logout> command or a TCP CLOSE.
The Total Length field in the EPP data unit is a 32-bit value in network byte order that includes the 4 octets of the header itself. A receiver must read Total Length minus four octets to retrieve the complete EPP XML instance.
IANA has assigned system port number 700 for mapping EPP onto TCP. User port number 3121 (previously used for development and test purposes) has been reclaimed by IANA.
EPP provides only simple client authentication via identifiers and plain text passwords; a passive attack is sufficient to recover credentials. Protection against most common attacks MUST be provided by TLS, which is mandatory for all EPP-over-TCP deployments.
EPP TCP servers are vulnerable to common TCP denial-of-service attacks including TCP SYN flooding. Servers SHOULD deploy firewall technology and border router filters to restrict inbound access to known, trusted clients.
There is a risk of login credential compromise if a client does not properly verify the server's certificate before establishing an EPP session. Clients must check both the TLS certificate identity and the EPP greeting for consistency with expected server identification before sending credentials.
The EPP TCP session state machine follows: TCP CONNECT → server sends <greeting> → client sends <login> → server sends response → command/response exchanges → client sends <logout> or CLOSE → server sends response and disconnects. The general EPP server state machine is defined in RFC 4930 Section 2.
The EPP data unit contains a 32-bit Total Length field (network/big-endian byte order, inclusive of the 4-octet header itself) followed by a variable-length EPP XML Instance. The XML instance length equals Total Length minus four octets.