idnits 2.17.1 draft-ietf-provreg-epp-tcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'EPP' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 January 29, 2003 Expires: July 29, 2003 6 Extensible Provisioning Protocol Transport Over TCP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes how an Extensible Provisioning Protocol (EPP) 32 session is mapped onto a single Transmission Control Protocol (TCP) 33 connection. This mapping requires use of the Transport Layer Security 34 (TLS) protocol to protect information exchanged between an EPP client 35 and an EPP server. 37 Conventions Used In This Document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 Table of Contents 45 1. Introduction ................................................. 3 46 2. Session Management ........................................... 4 47 3. Message Exchange ............................................. 5 48 4. Data Unit Format ............................................. 7 49 5. Transport Considerations ..................................... 8 50 6. Internationalization Considerations .......................... 9 51 7. IANA Considerations .......................................... 9 52 8. Security Considerations ...................................... 10 53 9. Acknowledgements ............................................. 11 54 10. References .................................................. 11 55 11. Author's Address ............................................ 11 56 A. Revisions From Previous Version .............................. 12 57 B. Full Copyright Statement ..................................... 13 59 1. Introduction 61 This document describes how the Extensible Provisioning Protocol (EPP) 62 is mapped onto a single client-server TCP connection. Security 63 services beyond those defined in EPP are provided by the Transport 64 Layer Security (TLS) Protocol [RFC2246]. EPP is described in [EPP]. 65 TCP is described in [RFC793]. 67 2. Session Management 69 Mapping EPP session management facilities onto the TCP service is 70 straight forward. An EPP session first requires creation of a TCP 71 connection between two peers, one that initiates the connection 72 request and one that responds to the connection request. The 73 initiating peer is called the "client", and the responding peer is 74 called the "server". An EPP server MUST listen for TCP connection 75 requests on a standard TCP port assigned by IANA. 77 The client MUST issue an active OPEN call, specifying the TCP port 78 number on which the server is listening for EPP connection attempts. 79 The server MUST respond with a passive OPEN call, which the client 80 MUST acknowledge to establish the connection. The EPP server MUST 81 return an EPP to the client after the TCP session has been 82 established. 84 An EPP session is normally ended by the client issuing an EPP 85 command. A server receiving an EPP command MUST end the EPP 86 session and close the TCP connection through an active CLOSE call. 87 The client MUST respond with a passive CLOSE call. 89 A client MAY end an EPP session by issuing an active CLOSE call. A 90 server SHOULD respond with a passive CLOSE call. 92 A server MAY limit the life span of an established TCP connection. 93 EPP sessions that are inactive for more than a server-defined period 94 MAY be ended by a server issuing an active CLOSE call. A server MAY 95 also close TCP connections that have been open and active for longer 96 than a server-defined period. 98 Peers SHOULD respond to an active CLOSE call with a passive CLOSE 99 call. The closing peer MAY issue an ABORT call if the responding peer 100 does not respond to the active CLOSE call. 102 3. Message Exchange 104 With the exception of the EPP server greeting, EPP messages are 105 initiated by the EPP client in the form of EPP commands. An EPP 106 server MUST return an EPP response to an EPP command on the same TCP 107 connection that carried the command. If the TCP connection is closed 108 after a server receives and successfully processes a command but 109 before the response can be returned to the client, the server MAY 110 attempt to undo the effects of the command to ensure a consistent 111 state between the client and the server. EPP commands are idempotent, 112 so processing a command more than once produces the same net effect on 113 the repository as successfully processing the command once. 115 An EPP client streams EPP commands to an EPP server on an established 116 TCP connection. A client MAY but SHOULD NOT establish multiple TCP 117 connections to create multiple command exchange channels. A server 118 SHOULD limit a client to a maximum number of TCP connections based on 119 server capabilities and operational load. 121 EPP describes client-server interaction as a command-response exchange 122 where the client sends one command to the server and the server 123 returns one response to the client. A client might be able to realize 124 a slight performance gain by pipelining (sending more than one command 125 before a response for the first command is received) commands with TCP 126 transport, but this feature does not change the basic single command, 127 single response operating mode of the core protocol. The amount of 128 data that can be outstanding is limited to the current TCP window 129 size. 131 Each EPP data unit MUST contain a single EPP message. Commands MUST 132 be processed independently and in the same order as sent from the 133 client. 135 A server SHOULD impose a limit on the amount of time required for a 136 client to issue a well-formed EPP command. A server SHOULD end an EPP 137 session and close an open TCP connection if a well-formed command is 138 not received within the time limit. 140 A general state machine for an EPP server is described in section 2 of 141 [EPP]. General client-server message exchange using TCP transport is 142 illustrated in Figure 1. 144 Client Server 145 | | 146 | Connect | 147 | >>------------------------------->> | 148 | | 149 | Send Greeting | 150 | <<-------------------------------<< | 151 | | 152 | Send | 153 | >>------------------------------->> | 154 | | 155 | Send Response | 156 | <<-------------------------------<< | 157 | | 158 | Send Command | 159 | >>------------------------------->> | 160 | | 161 | Send Response | 162 | <<-------------------------------<< | 163 | | 164 | Send Command X | 165 | >>------------------------------->> | 166 | | 167 | Send Command Y | 168 | >>---------------+ | 169 | | | 170 | | | 171 | Send Response X | 172 | <<---------------(---------------<< | 173 | | | 174 | | | 175 | +--------------->> | 176 | | 177 | Send Response Y | 178 | <<-------------------------------<< | 179 | | 180 | Send | 181 | >>------------------------------->> | 182 | | 183 | Send Response & Disconnect | 184 | <<-------------------------------<< | 185 | | 187 Figure 1: TCP Client-Server Message Exchange 189 4. Data Unit Format 191 The data field of the TCP header MUST contain an EPP data unit. The 192 EPP data unit contains two fields: a 32-bit header that describes the 193 total length of the data unit, and the EPP XML instance. 195 EPP Data Unit Format (one tick mark represents one bit position): 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Total Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | EPP XML Instance | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Total Length (32 bits): The total length of the EPP data unit measured 206 in octets in network (big endian) byte order. The octets contained in 207 this field MUST be included in the total length calculation. 209 EPP XML Instance (variable length): The EPP XML instance carried in 210 the data unit. 212 5. Transport Considerations 214 Section 2.1 of the EPP core protocol specification [EPP] describes 215 considerations to be addressed by protocol transport mappings. This 216 mapping addresses each of the considerations using a combination of 217 features described in this document and features provided by TCP as 218 follows: 220 - TCP includes features to provide reliability, flow control, ordered 221 delivery, and congestion control. Section 1.5 of RFC 793 [RFC793] 222 describes these features in detail; congestion control principles are 223 described further in RFC 2581 [RFC2581] and RFC 2914 [RFC2914]. TCP 224 is a connection-oriented protocol, and Section 2 of this mapping 225 describes how EPP sessions are mapped to TCP connections. 227 - Sections 2 and 3 of this mapping describe how the stateful nature of 228 EPP is preserved through managed sessions and controlled message 229 exchanges. 231 - Section 3 of this mapping notes that command pipelining is possible 232 with TCP, though batch-oriented processing (combining multiple EPP 233 commands in a single data unit) is not permitted. 235 - Section 4 of this mapping describes features to frame data units by 236 explicitly specifying the number of octets used to represent a data 237 unit. 239 6. Internationalization Considerations 241 This mapping does not introduce or present any internationalization or 242 localization issues. 244 7. IANA Considerations 246 Mapping EPP onto TCP requires a TCP port assignment from IANA for 247 public operation. TCP port 3121 (a port number in the user port 248 range) has been assigned by IANA for development and test purposes. A 249 system port will need to be assigned, and this user port assignment 250 will need to be reclaimed, if this document advances to RFC status. 252 System Port number XXX - TBA by IANA. 254 8. Security Considerations 256 EPP as-is provides only simple client authentication services using 257 identifiers and plain text passwords. A passive attack is sufficient 258 to recover client identifiers and passwords, allowing trivial command 259 forgery. Protection against most other common attacks MUST be 260 provided by other layered protocols. 262 EPP provides protection against replay attacks through command 263 idempotency. A replayed or repeated command will not change the state 264 of any object in any way, though denial of service through consumption 265 of connection resources is a possibility. 267 When layered over TCP, the Transport Layer Security (TLS) Protocol 268 described in [RFC2246] MUST be used to prevent eavesdropping, 269 tampering, and command forgery attacks. Implementations of TLS often 270 contain a US-exportable cryptographic mode that SHOULD NOT be used to 271 protect EPP. Clients and servers desiring high security SHOULD 272 instead use TLS with cryptographic algorithms that are less 273 susceptible to compromise. 275 Mutual client and server authentication using the TLS Handshake 276 Protocol is REQUIRED. Signatures on the complete certificate chain 277 for both client machine and server machine MUST be validated as part 278 of the TLS handshake. Information included in the client and server 279 certificates, such as validity periods and machine names, MUST also be 280 validated. EPP service MUST NOT be granted until successful 281 completion of a TLS handshake and certificate validation, ensuring 282 that both the client machine and the server machine have been 283 authenticated and cryptographic protections are in place. 285 Authentication using the TLS Handshake Protocol confirms the identity 286 of the client and server machines. EPP uses an additional client 287 identifier and password to identify and authenticate the client's user 288 identity to the server, supplementing the machine authentication 289 provided by TLS. The identity described in the client certificate and 290 the identity described in the EPP client identifier can differ, as a 291 server can assign multiple user identities for use from any particular 292 client machine. 294 EPP TCP servers are vulnerable to common TCP denial of service attacks 295 including TCP SYN flooding. Servers SHOULD take steps to minimize the 296 impact of a denial of service attack using combinations of easily 297 implemented solutions, such as deployment of firewall technology and 298 border router filters to restrict inbound server access to known, 299 trusted clients. 301 9. Acknowledgements 303 This document was originally written as an individual submission 304 Internet-Draft. The provreg working group later adopted it as a 305 working group document and provided many invaluable comments and 306 suggested improvements. The author wishes to acknowledge the efforts 307 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 308 editorial contributions. 310 Specific suggestions that have been incorporated into this document 311 were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned Freed, 312 James Gould, Dan Manley, and John Immordino. 314 10. References 316 Normative References: 318 [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 319 progress. 321 [RFC793] J. Postel: "Transmission Control Protocol", STD 7, RFC 793, 322 September 1981. 324 [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC2246] T. Dierks and C. Allen: "The TLS Protocol Version 1.0", RFC 328 2246, January 1999. 330 [RFC2581] M. Allman et al.: "TCP Congestion Control", RFC 2581, April 331 1999. 333 [RFC2914] S. Floyd: "Congestion Control Principles", BCP 41, RFC 2914, 334 September 2000. 336 Informative References: 338 None 340 11. Author's Address 342 Scott Hollenbeck 343 VeriSign Global Registry Services 344 21345 Ridgetop Circle 345 Dulles, VA 20166-6503 346 USA 347 shollenbeck@verisign.com 349 A. Revisions From Previous Version 351 (Note to RFC editor: please remove this section completely before 352 publication as an RFC.) 354 -05 to -06 (IESG review): 356 Removed "This document is being discussed" paragraph from section 1. 358 Modified MAY/SHOULD text in section 3, paragraph 2. 360 More text in section 8 to describe the relationship between TLS 361 authentication and EPP ID/password authentication. 363 Added references to RFCs 2581 and 2914. 365 B. Full Copyright Statement 367 Copyright (C) The Internet Society 2002. All Rights Reserved. 369 This document and translations of it may be copied and furnished to 370 others, and derivative works that comment on or otherwise explain it 371 or assist in its implementation may be prepared, copied, published and 372 distributed, in whole or in part, without restriction of any kind, 373 provided that the above copyright notice and this paragraph are 374 included on all such copies and derivative works. However, this 375 document itself may not be modified in any way, such as by removing 376 the copyright notice or references to the Internet Society or other 377 Internet organizations, except as needed for the purpose of developing 378 Internet standards in which case the procedures for copyrights defined 379 in the Internet Standards process must be followed, or as required to 380 translate it into languages other than English. 382 The limited permissions granted above are perpetual and will not be 383 revoked by the Internet Society or its successors or assigns. 385 This document and the information contained herein is provided on an 386 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 387 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 388 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 389 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 390 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 392 Acknowledgement 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.