Extensible Provisioning Protocol (EPP) Transport over TCP
obsoletes
- rfc-4934 — Extensible Provisioning Protocol (EPP) Transport Over TCP
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
also
- std-69
Extracted elements (27)
Command pipelining (sending multiple commands before receiving a response to the first) is possible with TCP transport and may yield slight performance gains, but EPP prohibits batch processing (multiple commands in a single data unit) and the core protocol remains single-command/single-response.
The wildcard character '*' (ASCII 42) is permitted in subjectAltName values of type dNSName only as the left-most DNS label, matching any single left-most label (e.g., *.example.com matches a.example.com but not a.b.example.com or example.com).
Use of the Common Name (CN) field in the leaf RDN for server identity verification is existing practice but deprecated; Certification Authorities are encouraged to provide subjectAltName values instead.
A client MUST NOT distribute commands from a single EPP session over multiple TCP connections. A client MAY establish multiple TCP connections to support multiple independent EPP sessions.
A server receiving an EPP <logout> command MUST end the EPP session and close the TCP connection with a CLOSE call.
Acceptable certificate identities MUST be negotiated between client and server operators using an out-of-band mechanism. Presented certificate identities MUST match negotiated identities before EPP service is granted.
After establishing a TLS session and receiving an EPP greeting on a protected TCP connection, clients MUST compare the certificate subject and/or subjectAltName to expected server identification information and abort processing if a mismatch is detected.
All EPP messages MUST be sent as TLS 'application data'. It is possible that multiple EPP messages are in one TLS record or that a single EPP message spans multiple TLS records.
An EPP server MUST listen for TCP connection requests on the 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.
Automated clients SHOULD return or log an error and SHOULD close the transport connection if the server identity check fails. They MAY provide a configuration setting to disable this check but MUST provide a setting to enable it.
During TLS negotiation, the EPP client MUST check its reference identity (server name or IP address) against the server's identity in the Certificate message to prevent man-in-the-middle attacks.
During TLS negotiation, the EPP server MUST verify that the client certificate matches the reference identity previously negotiated out of band, matching the entire subject name or subjectAltName per RFC 5280.
Each EPP data unit MUST contain a single EPP message. 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 the client machine and server machine have been authenticated and cryptographic protections are in place.
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, and certificate validity periods and machine names MUST also be validated.
The EPP server MUST return an EPP <greeting> to the client after the TCP session has been established.
The octets in the 32-bit Total Length field MUST be included in the total length calculation, meaning the minimum valid value is 4.
TLS implementations are REQUIRED to support the mandatory cipher suite for the implemented version: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (TLS 1.0), TLS_RSA_WITH_3DES_EDE_CBC_SHA (TLS 1.1), or TLS_RSA_WITH_AES_128_CBC_SHA (TLS 1.2).
When closing a connection, the server MUST attempt to initiate an exchange of close_notify alerts with the client before closing. Servers unprepared to receive more data MAY close after sending close_notify, producing an incomplete close on the client side.
When layered over TCP, TLS version 1.0 or its successors MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication.
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 as-is provides only simple client authentication using identifiers and plain text passwords; a passive attack is sufficient to recover credentials and forge commands. TLS MUST be used to provide integrity, confidentiality, and mutual authentication.
EPP TCP servers are vulnerable to TCP denial-of-service attacks including 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 identify the server before establishing an EPP session. Clients must verify the server TLS certificate and the received <greeting> contents match expected values before sending credentials.
An EPP session over TCP follows the sequence: TCP OPEN → TLS handshake → server sends <greeting> → client sends <login> and receives response → command/response exchanges → client sends <logout> → server closes TCP connection. A server MAY terminate idle or long-running sessions.
The EPP data unit has two fields: a 32-bit Total Length (network 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 4 octets.