idnits 2.17.1 draft-hollenbeck-epp-rfc3734bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 429. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 453. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (January 9, 2007) is 6309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3734 (Obsoleted by RFC 4934) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Obsoletes: 3734 (if approved) January 9, 2007 5 Intended status: Standards Track 6 Expires: July 13, 2007 8 Extensible Provisioning Protocol (EPP) Transport Over TCP 9 draft-hollenbeck-epp-rfc3734bis-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 13, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how an Extensible Provisioning Protocol (EPP) 43 session is mapped onto a single Transmission Control Protocol (TCP) 44 connection. This mapping requires use of the Transport Layer 45 Security (TLS) protocol to protect information exchanged between an 46 EPP client and an EPP server. This document obsoletes RFC 3734 if 47 approved. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Conventions Used In This Document . . . . . . . . . . . . 3 53 2. Session Management . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Transport Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. Internationalization Considerations . . . . . . . . . . . . . 7 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 64 Appendix A. Changes from RFC 3734 . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 Intellectual Property and Copyright Statements . . . . . . . . . . 11 68 1. Introduction 70 This document describes how the Extensible Provisioning Protocol 71 (EPP) is mapped onto a single client-server TCP connection. Security 72 services beyond those defined in EPP are provided by the Transport 73 Layer Security (TLS) Protocol [RFC2246]. EPP is described in 74 [I-D.hollenbeck-epp-rfc3730bis]. TCP is described in [RFC0793]. 75 This document obsoletes RFC 3734 [RFC3734] if approved. 77 1.1. Conventions Used In This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Session Management 85 Mapping EPP session management facilities onto the TCP service is 86 straight forward. An EPP session first requires creation of a TCP 87 connection between two peers, one that initiates the connection 88 request and one that responds to the connection request. The 89 initiating peer is called the "client", and the responding peer is 90 called the "server". An EPP server MUST listen for TCP connection 91 requests on a standard TCP port assigned by IANA. 93 The client MUST issue an active OPEN call, specifying the TCP port 94 number on which the server is listening for EPP connection attempts. 95 The EPP server MUST return an EPP to the client after the 96 TCP session has been established. 98 An EPP session is normally ended by the client issuing an EPP 99 command. A server receiving an EPP command MUST 100 end the EPP session and close the TCP connection with a CLOSE call. 101 A client MAY end an EPP session by issuing a CLOSE call. 103 A server MAY limit the life span of an established TCP connection. 104 EPP sessions that are inactive for more than a server-defined period 105 MAY be ended by a server issuing a CLOSE call. A server MAY also 106 close TCP connections that have been open and active for longer than 107 a server-defined period. 109 3. Message Exchange 111 With the exception of the EPP server greeting, EPP messages are 112 initiated by the EPP client in the form of EPP commands. An EPP 113 server MUST return an EPP response to an EPP command on the same TCP 114 connection that carried the command. If the TCP connection is closed 115 after a server receives and successfully processes a command but 116 before the response can be returned to the client, the server MAY 117 attempt to undo the effects of the command to ensure a consistent 118 state between the client and the server. EPP commands are 119 idempotent, so processing a command more than once produces the same 120 net effect on the repository as successfully processing the command 121 once. 123 An EPP client streams EPP commands to an EPP server on an established 124 TCP connection. A client MUST NOT distribute commands from a single 125 EPP session over multiple TCP connections. A client MAY establish 126 multiple TCP connections to support multiple EPP sessions with each 127 session mapped to a single connection. A server SHOULD limit a 128 client to a maximum number of TCP connections based on server 129 capabilities and operational load. 131 EPP describes client-server interaction as a command-response 132 exchange where the client sends one command to the server and the 133 server returns one response to the client. A client might be able to 134 realize a slight performance gain by pipelining (sending more than 135 one command before a response for the first command is received) 136 commands with TCP transport, but this feature does not change the 137 basic single command, single response operating mode of the core 138 protocol. 140 Each EPP data unit MUST contain a single EPP message. Commands MUST 141 be processed independently and in the same order as sent from the 142 client. 144 A server SHOULD impose a limit on the amount of time required for a 145 client to issue a well-formed EPP command. A server SHOULD end an 146 EPP session and close an open TCP connection if a well-formed command 147 is not received within the time limit. 149 A general state machine for an EPP server is described in section 2 150 of [I-D.hollenbeck-epp-rfc3730bis]. General client-server message 151 exchange using TCP transport is illustrated in Figure 1. 153 Client Server 154 | | 155 | Connect | 156 | >>------------------------------->> | 157 | | 158 | Send Greeting | 159 | <<-------------------------------<< | 160 | | 161 | Send | 162 | >>------------------------------->> | 163 | | 164 | Send Response | 165 | <<-------------------------------<< | 166 | | 167 | Send Command | 168 | >>------------------------------->> | 169 | | 170 | Send Response | 171 | <<-------------------------------<< | 172 | | 173 | Send Command X | 174 | >>------------------------------->> | 175 | | 176 | Send Command Y | 177 | >>---------------+ | 178 | | | 179 | | | 180 | Send Response X | 181 | <<---------------(---------------<< | 182 | | | 183 | | | 184 | +--------------->> | 185 | | 186 | Send Response Y | 187 | <<-------------------------------<< | 188 | | 189 | Send | 190 | >>------------------------------->> | 191 | | 192 | Send Response & Disconnect | 193 | <<-------------------------------<< | 194 | | 196 Figure 1: TCP Client-Server Message Exchange 198 4. Data Unit Format 200 The data field of the TCP header MUST contain an EPP data unit. The 201 EPP data unit contains two fields: a 32-bit header that describes the 202 total length of the data unit, and the EPP XML instance. The length 203 of the EPP XML instance is determined by subtracting four octets from 204 the total length of the data unit. A receiver must successfully read 205 that many octets to retrieve the complete EPP XML instance before 206 processing the EPP message. 208 EPP Data Unit Format (one tick mark represents one bit position): 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Total Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | EPP XML Instance | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Total Length (32 bits): The total length of the EPP data unit 219 measured in octets in network (big endian) byte order. The octets 220 contained in this field MUST be included in the total length 221 calculation. 223 EPP XML Instance (variable length): The EPP XML instance carried in 224 the data unit. 226 5. Transport Considerations 228 Section 2.1 of the EPP core protocol specification 229 [I-D.hollenbeck-epp-rfc3730bis] describes considerations to be 230 addressed by protocol transport mappings. This mapping addresses 231 each of the considerations using a combination of features described 232 in this document and features provided by TCP as follows: 234 - TCP includes features to provide reliability, flow control, 235 ordered delivery, and congestion control. Section 1.5 of RFC 793 236 [RFC0793] describes these features in detail; congestion control 237 principles are described further in RFC 2581 [RFC2581] and RFC 238 2914 [RFC2914]. TCP is a connection-oriented protocol, and 239 Section 2 of this mapping describes how EPP sessions are mapped to 240 TCP connections. 242 - Sections 2 and 3 of this mapping describe how the stateful nature 243 of EPP is preserved through managed sessions and controlled 244 message exchanges. 246 - Section 3 of this mapping notes that command pipelining is 247 possible with TCP, though batch-oriented processing (combining 248 multiple EPP commands in a single data unit) is not permitted. 250 - Section 4 of this mapping describes features to frame data units 251 by explicitly specifying the number of octets used to represent a 252 data unit. 254 6. Internationalization Considerations 256 This mapping does not introduce or present any internationalization 257 or localization issues. 259 7. IANA Considerations 261 System port number 700 has been assigned by the IANA for mapping EPP 262 onto TCP. 264 User port number 3121 (which was used for development and test 265 purposes) has been reclaimed by the IANA. 267 8. Security Considerations 269 EPP as-is provides only simple client authentication services using 270 identifiers and plain text passwords. A passive attack is sufficient 271 to recover client identifiers and passwords, allowing trivial command 272 forgery. Protection against most other common attacks MUST be 273 provided by other layered protocols. 275 When layered over TCP, the Transport Layer Security (TLS) Protocol 276 version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), 277 using the latest version supported by both parties, MUST be used to 278 provide integrity, confidentiality, and mutual strong client-server 279 authentication. Implementations of TLS often contain a weak 280 cryptographic mode that SHOULD NOT be used to protect EPP. Clients 281 and servers desiring high security SHOULD instead use TLS with 282 cryptographic algorithms that are less susceptible to compromise. 284 Mutual client and server authentication using the TLS Handshake 285 Protocol is REQUIRED. Signatures on the complete certification path 286 for both client machine and server machine MUST be validated as part 287 of the TLS handshake. Information included in the client and server 288 certificates, such as validity periods and machine names, MUST also 289 be validated. A complete description of the issues associated with 290 certification path validation can be found in RFC 3280 [RFC3280]. 291 EPP service MUST NOT be granted until successful completion of a TLS 292 handshake and certificate validation, ensuring that both the client 293 machine and the server machine have been authenticated and 294 cryptographic protections are in place. 296 Authentication using the TLS Handshake Protocol confirms the identity 297 of the client and server machines. EPP uses an additional client 298 identifier and password to identify and authenticate the client's 299 user identity to the server, supplementing the machine authentication 300 provided by TLS. The identity described in the client certificate 301 and the identity described in the EPP client identifier can differ, 302 as a server can assign multiple user identities for use from any 303 particular client machine. Acceptable certificate identities MUST be 304 negotiated between client operators and server operators using an 305 out-of-band mechanism. Presented certificate identities MUST match 306 negotiated identities before EPP service is granted. 308 There is a risk of login credential compromise if a client does not 309 properly identify a server before attempting to establish an EPP 310 session. Before sending login credentials to the server, a client 311 needs to confirm that the server certificate received in the TLS 312 handshake is an expected certificate for the server. A client also 313 needs to confirm that the greeting received from the server contains 314 expected identification information. After establishing a TLS 315 session and receiving an EPP greeting on a protected TCP connection, 316 clients MUST compare the certificate subject and/or subjectAltName to 317 expected server identification information and abort processing if a 318 mismatch is detected. If certificate validation is successful, the 319 client then needs to ensure that the information contained in the 320 received certificate and greeting is consistent and appropriate. As 321 described above, both checks typically require an out-of-band 322 exchange of information between client and server to identify 323 expected values before in-band connections are attempted. 325 EPP TCP servers are vulnerable to common TCP denial of service 326 attacks including TCP SYN flooding. Servers SHOULD take steps to 327 minimize the impact of a denial of service attack using combinations 328 of easily implemented solutions, such as deployment of firewall 329 technology and border router filters to restrict inbound server 330 access to known, trusted clients. 332 9. Acknowledgements 334 This document was originally written as an individual submission 335 Internet-Draft. The provreg working group later adopted it as a 336 working group document and provided many invaluable comments and 337 suggested improvements. The author wishes to acknowledge the efforts 338 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 339 editorial contributions. 341 Specific suggestions that have been incorporated into this document 342 were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned 343 Freed, James Gould, Dan Manley, and John Immordino. 345 10. References 347 10.1. Normative References 349 [I-D.hollenbeck-epp-rfc3730bis] 350 Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 351 draft-hollenbeck-epp-rfc3730bis-04 (work in progress), 352 November 2006. 354 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 355 RFC 793, September 1981. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 361 RFC 2246, January 1999. 363 10.2. Informative References 365 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 366 Control", RFC 2581, April 1999. 368 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 369 RFC 2914, September 2000. 371 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 372 X.509 Public Key Infrastructure Certificate and 373 Certificate Revocation List (CRL) Profile", RFC 3280, 374 April 2002. 376 [RFC3734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 377 Transport Over TCP", RFC 3734, March 2004. 379 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 380 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 382 Appendix A. Changes from RFC 3734 384 1. Minor reformatting as a result of converting I-D source format 385 from nroff to XML. 387 2. Updated Security Considerations to include strong authentication 388 among the list of needed security services. Removed paragraph 389 describing replay attacks because it's not specific to TCP. New 390 text has been added to 3730bis to describe this issue. 392 3. Modified description of TCP operation as a result of IESG 393 evaluation. 395 4. Moved RFCs 2581 and 2914 from the normative reference section to 396 the informative reference section. 398 5. Added informational references to RFCs 3280 and 4346 and 399 descriptive text for each as a result of IESG evaluation. 401 6. Revised security considerations as a result of IESG evaluation. 403 7. Updated EPP references. 405 Author's Address 407 Scott Hollenbeck 408 VeriSign, Inc. 409 21345 Ridgetop Circle 410 Dulles, VA 20166-6503 411 US 413 Email: shollenbeck@verisign.com 415 Full Copyright Statement 417 Copyright (C) The IETF Trust (2007). 419 This document is subject to the rights, licenses and restrictions 420 contained in BCP 78, and except as set forth therein, the authors 421 retain all their rights. 423 This document and the information contained herein are provided on an 424 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 425 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 426 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 427 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 428 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 429 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 431 Intellectual Property 433 The IETF takes no position regarding the validity or scope of any 434 Intellectual Property Rights or other rights that might be claimed to 435 pertain to the implementation or use of the technology described in 436 this document or the extent to which any license under such rights 437 might or might not be available; nor does it represent that it has 438 made any independent effort to identify any such rights. Information 439 on the procedures with respect to rights in RFC documents can be 440 found in BCP 78 and BCP 79. 442 Copies of IPR disclosures made to the IETF Secretariat and any 443 assurances of licenses to be made available, or the result of an 444 attempt made to obtain a general license or permission for the use of 445 such proprietary rights by implementers or users of this 446 specification can be obtained from the IETF on-line IPR repository at 447 http://www.ietf.org/ipr. 449 The IETF invites any interested party to bring to its attention any 450 copyrights, patents or patent applications, or other proprietary 451 rights that may cover technology that may be required to implement 452 this standard. Please address the information to the IETF at 453 ietf-ipr@ietf.org. 455 Acknowledgment 457 Funding for the RFC Editor function is provided by the IETF 458 Administrative Support Activity (IASA).