ietf-corpus

rfc-4934

Extensible Provisioning Protocol (EPP) Transport Over TCP

S. Hollenbeck
date2007-05 streamIETF wgnon working group statusDRAFT STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc4934 doi10.17487/RFC4934
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) protocol to protect information exchanged between an EPP client and an EPP server. This document obsoletes RFC 3734. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (26)

design-rationale §3

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.

tcp

design-rationale §8

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.

tls, security

interoperability-note §3

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.

tcp

interoperability-note §A

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.

tcp, security

normative-requirement §3 MUST NOT

A client MUST NOT distribute commands from a single EPP session over multiple TCP connections.

tcp

normative-requirement §2 MUST

A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection with a CLOSE call.

tcp

normative-requirement §3 SHOULD

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.

tcp

normative-requirement §3 SHOULD

A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load.

tcp

normative-requirement §8 MUST

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.

tls, security, pkix

normative-requirement §8 MUST

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.

tls, security, pkix

normative-requirement §2 MUST

An EPP server MUST listen for TCP connection requests on a standard TCP port assigned by IANA (port 700).

tcp, registry

normative-requirement §3 MUST

An EPP server MUST return an EPP response to an EPP command on the same TCP connection that carried the command.

tcp

normative-requirement §3 MUST

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.

tcp

normative-requirement §8 MUST NOT

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.

tls, security

normative-requirement §8 SHOULD NOT

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.

tls, security, crypto

normative-requirement §8 REQUIRED

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.

tls, security, pkix

normative-requirement §2 MUST

The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.

tcp

normative-requirement §8 MUST

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.

tls, security

protocol-element §2

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.

tcp

protocol-element §4

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.

tcp

registry §7

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.

registry, tcp

security-consideration §8

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.

security, tls

security-consideration §8

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.

security, tcp

security-consideration §8

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.

security, tls, pkix

state-machine §3

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.

tcp

wire-format §4

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.

tcp