Extensible Provisioning Protocol (EPP) Transport Over TCP
obsoleted by
- rfc-4934 — Extensible Provisioning Protocol (EPP) Transport Over TCP
Extracted elements (23)
If the TCP connection is closed after a server successfully processes a command but before the response is returned, the server MAY attempt to undo the effects of the command; EPP commands are idempotent, so processing a command more than once produces the same net effect.
TLS authentication confirms the identity of client and server machines, while EPP uses an additional client identifier and password to authenticate the user identity; this two-layer approach allows a server to assign multiple user identities for use from any particular client machine.
This transport mapping relies on TCP features (reliability, flow control, ordered delivery, congestion control per RFC 793, RFC 2581, RFC 2914) to satisfy the EPP core protocol transport requirements defined in Section 2.1 of RFC 3730.
A client MAY but SHOULD NOT establish multiple TCP connections to create multiple command exchange channels; a server SHOULD limit a client to a maximum number of TCP connections.
A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection through an active CLOSE call; the client MUST respond with a passive CLOSE call.
A server SHOULD impose a limit on the amount of time required 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 the time limit.
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.
Implementations of TLS often contain a US-exportable cryptographic mode that SHOULD NOT be used to protect EPP; clients and servers desiring high security SHOULD use TLS with cryptographic algorithms less susceptible to compromise.
Information included in the client and server certificates, such as validity periods and machine names, MUST be validated as part of the TLS handshake.
Mutual client and server authentication using the TLS Handshake Protocol is REQUIRED; signatures on the complete certificate chain for both client and server MUST be validated, and EPP service MUST NOT be granted until successful completion of a TLS handshake and certificate validation.
The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
The octets contained in the Total Length field MUST be included in the total length calculation of the EPP data unit.
When layered over TCP, the Transport Layer Security (TLS) Protocol described in RFC 2246 MUST be used to prevent eavesdropping, tampering, and command forgery attacks.
An EPP session over TCP begins with the client issuing an active OPEN, the server responding with a passive OPEN, the client acknowledging to establish the connection, and the server immediately returning an EPP <greeting>.
Command pipelining is possible with TCP transport — a client may send more than one command before receiving a response for the first — but batch-oriented processing (combining multiple EPP commands in a single data unit) is not permitted.
System port number 700 has been assigned by IANA for mapping EPP onto TCP. User port number 3121 (previously used for development and testing) has been reclaimed by IANA.
EPP provides only simple client authentication with identifiers and plain text passwords; a passive attack is sufficient to recover credentials, so TLS MUST be used to protect all EPP sessions over TCP and mutual TLS certificate authentication is required.
EPP provides protection against replay attacks through command idempotency — a replayed command will not change the state of any object — though denial of service through consumption of connection resources remains a possibility.
EPP TCP servers are vulnerable to TCP SYN flooding and other common TCP denial of service attacks; servers SHOULD deploy firewall technology and border router filters to restrict inbound access to known, trusted clients.
EPP session lifecycle states over TCP: (1) TCP connection established; (2) server sends <greeting>; (3) client sends <login>, server responds; (4) command/response exchange; (5) client sends <logout> or issues active CLOSE to terminate session and TCP connection.
The EPP data unit consists of a 32-bit Total Length field (network byte order, inclusive of the length field itself) followed by a variable-length EPP XML Instance field.