From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4934.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc4934.txt (limited to 'doc/rfc/rfc4934.txt') diff --git a/doc/rfc/rfc4934.txt b/doc/rfc/rfc4934.txt new file mode 100644 index 0000000..90effec --- /dev/null +++ b/doc/rfc/rfc4934.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group S. Hollenbeck +Request for Comments: 4934 VeriSign, Inc. +Obsoletes: 3734 May 2007 +Category: Standards Track + + + Extensible Provisioning Protocol (EPP) Transport over TCP + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Conventions Used in This Document . . . . . . . . . . . . . 2 + 2. Session Management . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Transport Considerations . . . . . . . . . . . . . . . . . . . 5 + 6. Internationalization Considerations . . . . . . . . . . . . . . 6 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 + Appendix A. Changes from RFC 3734 . . . . . . . . . . . . . . . . 9 + + + + + + + +Hollenbeck Standards Track [Page 1] + +RFC 4934 EPP TCP Transport May 2007 + + +1. Introduction + + This document describes how the Extensible Provisioning Protocol + (EPP) is mapped onto a single client-server TCP connection. Security + services beyond those defined in EPP are provided by the Transport + Layer Security (TLS) Protocol [RFC2246]. EPP is described in + [RFC4930]. TCP is described in [RFC0793]. This document obsoletes + RFC 3734 [RFC3734]. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Session Management + + Mapping EPP session management facilities onto the TCP service is + straightforward. An EPP session first requires creation of a TCP + 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 MUST listen for TCP connection + requests on a standard TCP port assigned by IANA. + + The client MUST issue an active OPEN call, specifying the TCP port + number on which the server is listening for EPP connection attempts. + The EPP server MUST return an EPP to the client after the + TCP session has been established. + + An EPP session is normally ended by the client issuing an EPP + command. A server receiving an EPP command MUST + end the EPP session and close the TCP connection with a CLOSE call. + A client MAY end an EPP session by issuing a CLOSE call. + + A server MAY limit the life span of an established TCP connection. + EPP sessions that are inactive for more than a server-defined period + MAY be ended by a server issuing a CLOSE call. A server MAY also + close TCP connections that have been open and active for longer than + a server-defined period. + +3. Message Exchange + + With the exception of the EPP server greeting, EPP messages are + initiated by the EPP client in the form of EPP commands. An EPP + server MUST return an EPP response to an EPP command on the same TCP + connection that carried the command. If the TCP connection is closed + after a server receives and successfully processes a command but + + + +Hollenbeck Standards Track [Page 2] + +RFC 4934 EPP TCP Transport May 2007 + + + before the response can be returned to the client, the server MAY + attempt to undo the effects of the command to ensure a consistent + state between the client and the server. EPP commands are + idempotent, so processing a command more than once produces the same + net effect on the repository as successfully processing the command + once. + + An EPP client streams EPP commands to an EPP server on an established + TCP connection. 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 EPP sessions with each + session mapped to a single connection. A server SHOULD limit a + client to a maximum number of TCP connections based on server + capabilities and operational load. + + 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. A client might be able to + realize a slight performance gain by pipelining (sending more than + one command before a response for the first command is received) + commands with TCP transport, but this feature does not change the + basic single command, single response operating mode of the core + protocol. + + 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. + + 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 and close an open TCP connection if a well-formed command + is not received within the time limit. + + A general state machine for an EPP server is described in Section 2 + of [RFC4930]. General client-server message exchange using TCP + transport is illustrated in Figure 1. + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 3] + +RFC 4934 EPP TCP Transport May 2007 + + + Client Server + | | + | Connect | + | >>------------------------------->> | + | | + | Send Greeting | + | <<-------------------------------<< | + | | + | Send | + | >>------------------------------->> | + | | + | Send Response | + | <<-------------------------------<< | + | | + | Send Command | + | >>------------------------------->> | + | | + | Send Response | + | <<-------------------------------<< | + | | + | Send Command X | + | >>------------------------------->> | + | | + | Send Command Y | + | >>---------------+ | + | | | + | | | + | Send Response X | + | <<---------------(---------------<< | + | | | + | | | + | +--------------->> | + | | + | Send Response Y | + | <<-------------------------------<< | + | | + | Send | + | >>------------------------------->> | + | | + | Send Response & Disconnect | + | <<-------------------------------<< | + | | + + Figure 1: TCP Client-Server Message Exchange + + + + + + + +Hollenbeck Standards Track [Page 4] + +RFC 4934 EPP TCP Transport May 2007 + + +4. Data Unit Format + + The EPP data unit contains two fields: a 32-bit header that describes + the total length of the data unit, and the EPP XML instance. The + length of the EPP XML instance is determined by subtracting four + octets from the total length of the data unit. A receiver must + successfully read that many octets to retrieve the complete EPP XML + instance before processing the EPP message. + + EPP Data Unit Format (one tick mark represents one bit position): + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | EPP XML Instance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Total Length (32 bits): The total length of the EPP data unit + measured in octets in network (big endian) byte order. The octets + contained in this field MUST be included in the total length + calculation. + + EPP XML Instance (variable length): The EPP XML instance carried in + the data unit. + +5. Transport Considerations + + Section 2.1 of the EPP core protocol specification [RFC4930] + describes considerations to be addressed by protocol transport + mappings. This mapping addresses each of the considerations using a + combination of features described in this document and features + provided by TCP as follows: + + - TCP includes features to provide reliability, flow control, + ordered delivery, and congestion control. Section 1.5 of RFC 793 + [RFC0793] describes these features in detail; congestion control + principles are described further in RFC 2581 [RFC2581] and RFC + 2914 [RFC2914]. TCP is a connection-oriented protocol, and + Section 2 of this mapping describes how EPP sessions are mapped to + TCP connections. + + - Sections 2 and 3 of this mapping describe how the stateful nature + of EPP is preserved through managed sessions and controlled + message exchanges. + + + + + +Hollenbeck Standards Track [Page 5] + +RFC 4934 EPP TCP Transport May 2007 + + + - Section 3 of this mapping notes that command pipelining is + possible with TCP, though batch-oriented processing (combining + multiple EPP commands in a single data unit) is not permitted. + + - Section 4 of this mapping describes features to frame data units + by explicitly specifying the number of octets used to represent a + data unit. + +6. Internationalization Considerations + + This mapping does not introduce or present any internationalization + or localization issues. + +7. IANA Considerations + + System port number 700 has been assigned by the IANA for mapping EPP + onto TCP. + + User port number 3121 (which was used for development and test + purposes) has been reclaimed by the IANA. + +8. Security Considerations + + EPP as-is provides only simple client authentication services using + identifiers and plain text passwords. A passive attack is sufficient + to recover client identifiers and passwords, allowing trivial command + forgery. Protection against most other common attacks MUST be + provided by other layered protocols. + + When layered over TCP, the Transport Layer Security (TLS) Protocol + version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), + using the latest version supported by both parties, MUST be used to + provide integrity, confidentiality, and mutual strong client-server + authentication. 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 that are 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 machine and server machine MUST be validated as part + of the TLS handshake. Information included in the client and server + certificates, such as validity periods and machine names, MUST also + be validated. A complete description of the issues associated with + certification path validation can be found in RFC 3280 [RFC3280]. + EPP service MUST NOT be granted until successful completion of a TLS + + + + + +Hollenbeck Standards Track [Page 6] + +RFC 4934 EPP TCP Transport May 2007 + + + handshake and certificate validation, ensuring that both the client + machine and the server machine have been authenticated and + cryptographic protections are in place. + + Authentication using the TLS Handshake Protocol confirms the identity + of the client and server machines. EPP uses an additional client + identifier and password to identify and authenticate the client's + user identity to the server, supplementing the machine authentication + provided by TLS. The identity described in the client certificate + and the identity described in the EPP client identifier can differ, + as a server can assign multiple user identities for use from any + particular client machine. Acceptable certificate identities MUST be + negotiated between client operators and server operators using an + out-of-band mechanism. Presented certificate identities MUST match + negotiated identities before EPP service is granted. + + There is a risk of login credential compromise if a client does not + properly identify a server before attempting to establish an EPP + session. Before sending login credentials to the server, a client + needs to confirm that the server certificate received in the TLS + handshake is an expected certificate for the server. A client also + needs to confirm that the greeting received from the server contains + expected identification information. 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. If certificate validation is successful, the + client then needs to ensure that the information contained in the + received certificate and greeting is consistent and appropriate. As + described above, both checks typically require an out-of-band + exchange of information between client and server to identify + expected values before in-band connections are attempted. + + EPP TCP servers are vulnerable to common TCP denial-of-service + attacks including TCP SYN flooding. Servers SHOULD take steps to + minimize the impact of a denial-of-service attack using combinations + of easily implemented solutions, such as deployment of firewall + technology and border router filters to restrict inbound server + access to known, trusted clients. + +9. Acknowledgements + + This document was originally written as an individual submission + Internet-Draft. The PROVREG working group later adopted it as a + working group document and provided many invaluable comments and + suggested improvements. The author wishes to acknowledge the efforts + of WG chairs Edward Lewis and Jaap Akkerhuis for their process and + editorial contributions. + + + +Hollenbeck Standards Track [Page 7] + +RFC 4934 EPP TCP Transport May 2007 + + + Specific suggestions that have been incorporated into this document + were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned + Freed, James Gould, Dan Manley, and John Immordino. + +10. References + +10.1. Normative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + RFC 4930, May 2007. + +10.2. Informative References + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, + RFC 2914, September 2000. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Transport Over TCP", RFC 3734, March 2004. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 8] + +RFC 4934 EPP TCP Transport May 2007 + + +Appendix A. Changes from RFC 3734 + + 1. Minor reformatting as a result of converting I-D source format + from nroff to XML. + + 2. Updated Security Considerations to include strong authentication + among the list of needed security services. Removed paragraph + describing replay attacks because it's not specific to TCP. New + text has been added to RFC 4930 to describe this issue. + + 3. Modified description of TCP operation as a result of IESG + evaluation. + + 4. Moved RFCs 2581 and 2914 from the normative reference section to + the informative reference section. + + 5. Added informative references to RFCs 3280 and 4346 and + descriptive text for each as a result of IESG evaluation. + + 6. Revised security considerations as a result of IESG evaluation. + + 7. Updated EPP references. + +Author's Address + + Scott Hollenbeck + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + US + + EMail: shollenbeck@verisign.com + + + + + + + + + + + + + + + + + + + +Hollenbeck Standards Track [Page 9] + +RFC 4934 EPP TCP Transport May 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Hollenbeck Standards Track [Page 10] + -- cgit v1.2.3