idnits 2.17.1 draft-hollenbeck-rfc4934bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4934, but the abstract doesn't seem to directly say this. It does mention RFC4934 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2009) is 5475 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) == Outdated reference: A later version (-02) exists of draft-hollenbeck-rfc4930bis-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.hollenbeck-rfc4930bis' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4934 (Obsoleted by RFC 5734) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: 4934 (if approved) April 23, 2009 5 Intended status: Standards Track 6 Expires: October 25, 2009 8 Extensible Provisioning Protocol (EPP) Transport over TCP 9 draft-hollenbeck-rfc4934bis-01 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 25, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes how an Extensible Provisioning Protocol (EPP) 48 session is mapped onto a single Transmission Control Protocol (TCP) 49 connection. This mapping requires use of the Transport Layer 50 Security (TLS) protocol to protect information exchanged between an 51 EPP client and an EPP server. This document is intended to obsolete 52 RFC 4934. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 58 2. Session Management . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Transport Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. Internationalization Considerations . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. TLS Usage Profile . . . . . . . . . . . . . . . . . . . . . . 8 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Changes from RFC 4934 . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 This document describes how the Extensible Provisioning Protocol 75 (EPP) is mapped onto a single client-server TCP connection. Security 76 services beyond those defined in EPP are provided by the Transport 77 Layer Security (TLS) Protocol [RFC2246]. EPP is described in 78 [I-D.hollenbeck-rfc4930bis]. TCP is described in [RFC0793]. This 79 document is intended to obsolete RFC 4934 [RFC4934]. 81 1.1. Conventions Used in This Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Session Management 89 Mapping EPP session management facilities onto the TCP service is 90 straightforward. An EPP session first requires creation of a TCP 91 connection between two peers, one that initiates the connection 92 request and one that responds to the connection request. The 93 initiating peer is called the "client", and the responding peer is 94 called the "server". An EPP server MUST listen for TCP connection 95 requests on a standard TCP port assigned by IANA. 97 The client MUST issue an active OPEN call, specifying the TCP port 98 number on which the server is listening for EPP connection attempts. 99 The EPP server MUST return an EPP to the client after the 100 TCP session has been established. 102 An EPP session is normally ended by the client issuing an EPP 103 command. A server receiving an EPP command MUST 104 end the EPP session and close the TCP connection with a CLOSE call. 105 A client MAY end an EPP session by issuing a CLOSE call. 107 A server MAY limit the life span of an established TCP connection. 108 EPP sessions that are inactive for more than a server-defined period 109 MAY be ended by a server issuing a CLOSE call. A server MAY also 110 close TCP connections that have been open and active for longer than 111 a server-defined period. 113 3. Message Exchange 115 With the exception of the EPP server greeting, EPP messages are 116 initiated by the EPP client in the form of EPP commands. An EPP 117 server MUST return an EPP response to an EPP command on the same TCP 118 connection that carried the command. If the TCP connection is closed 119 after a server receives and successfully processes a command but 120 before the response can be returned to the client, the server MAY 121 attempt to undo the effects of the command to ensure a consistent 122 state between the client and the server. EPP commands are 123 idempotent, so processing a command more than once produces the same 124 net effect on the repository as successfully processing the command 125 once. 127 An EPP client streams EPP commands to an EPP server on an established 128 TCP connection. A client MUST NOT distribute commands from a single 129 EPP session over multiple TCP connections. A client MAY establish 130 multiple TCP connections to support multiple EPP sessions with each 131 session mapped to a single connection. A server SHOULD limit a 132 client to a maximum number of TCP connections based on server 133 capabilities and operational load. 135 EPP describes client-server interaction as a command-response 136 exchange where the client sends one command to the server and the 137 server returns one response to the client. A client might be able to 138 realize a slight performance gain by pipelining (sending more than 139 one command before a response for the first command is received) 140 commands with TCP transport, but this feature does not change the 141 basic single command, single response operating mode of the core 142 protocol. 144 Each EPP data unit MUST contain a single EPP message. Commands MUST 145 be processed independently and in the same order as sent from the 146 client. 148 A server SHOULD impose a limit on the amount of time required for a 149 client to issue a well-formed EPP command. A server SHOULD end an 150 EPP session and close an open TCP connection if a well-formed command 151 is not received within the time limit. 153 A general state machine for an EPP server is described in Section 2 154 of [I-D.hollenbeck-rfc4930bis]. General client-server message 155 exchange using TCP transport is illustrated in Figure 1. 157 Client Server 158 | | 159 | Connect | 160 | >>------------------------------->> | 161 | | 162 | Send Greeting | 163 | <<-------------------------------<< | 164 | | 165 | Send | 166 | >>------------------------------->> | 167 | | 168 | Send Response | 169 | <<-------------------------------<< | 170 | | 171 | Send Command | 172 | >>------------------------------->> | 173 | | 174 | Send Response | 175 | <<-------------------------------<< | 176 | | 177 | Send Command X | 178 | >>------------------------------->> | 179 | | 180 | Send Command Y | 181 | >>---------------+ | 182 | | | 183 | | | 184 | Send Response X | 185 | <<---------------(---------------<< | 186 | | | 187 | | | 188 | +--------------->> | 189 | | 190 | Send Response Y | 191 | <<-------------------------------<< | 192 | | 193 | Send | 194 | >>------------------------------->> | 195 | | 196 | Send Response & Disconnect | 197 | <<-------------------------------<< | 198 | | 200 Figure 1: TCP Client-Server Message Exchange 202 4. Data Unit Format 204 The EPP data unit contains two fields: a 32-bit header that describes 205 the total length of the data unit, and the EPP XML instance. The 206 length of the EPP XML instance is determined by subtracting four 207 octets from the total length of the data unit. A receiver must 208 successfully read that many octets to retrieve the complete EPP XML 209 instance before processing the EPP message. 211 EPP Data Unit Format (one tick mark represents one bit position): 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Total Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | EPP XML Instance | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Total Length (32 bits): The total length of the EPP data unit 222 measured in octets in network (big endian) byte order. The octets 223 contained in this field MUST be included in the total length 224 calculation. 226 EPP XML Instance (variable length): The EPP XML instance carried in 227 the data unit. 229 5. Transport Considerations 231 Section 2.1 of the EPP core protocol specification 232 [I-D.hollenbeck-rfc4930bis] describes considerations to be addressed 233 by protocol transport mappings. This mapping addresses each of the 234 considerations using a combination of features described in this 235 document and features provided by TCP as follows: 237 - TCP includes features to provide reliability, flow control, 238 ordered delivery, and congestion control. Section 1.5 of RFC 793 239 [RFC0793] describes these features in detail; congestion control 240 principles are described further in RFC 2581 [RFC2581] and RFC 241 2914 [RFC2914]. TCP is a connection-oriented protocol, and 242 Section 2 of this mapping describes how EPP sessions are mapped to 243 TCP connections. 245 - Sections 2 and 3 of this mapping describe how the stateful nature 246 of EPP is preserved through managed sessions and controlled 247 message exchanges. 249 - Section 3 of this mapping notes that command pipelining is 250 possible with TCP, though batch-oriented processing (combining 251 multiple EPP commands in a single data unit) is not permitted. 253 - Section 4 of this mapping describes features to frame data units 254 by explicitly specifying the number of octets used to represent a 255 data unit. 257 6. Internationalization Considerations 259 This mapping does not introduce or present any internationalization 260 or localization issues. 262 7. IANA Considerations 264 System port number 700 has been assigned by the IANA for mapping EPP 265 onto TCP. 267 User port number 3121 (which was used for development and test 268 purposes) has been reclaimed by the IANA. 270 8. Security Considerations 272 EPP as-is provides only simple client authentication services using 273 identifiers and plain text passwords. A passive attack is sufficient 274 to recover client identifiers and passwords, allowing trivial command 275 forgery. Protection against most other common attacks MUST be 276 provided by other layered protocols. 278 When layered over TCP, the Transport Layer Security (TLS) Protocol 279 version 1.0 [RFC2246] or its successors (such as TLS 1.2 [RFC5246]), 280 using the latest version supported by both parties, MUST be used to 281 provide integrity, confidentiality, and mutual strong client-server 282 authentication. Implementations of TLS often contain a weak 283 cryptographic mode that SHOULD NOT be used to protect EPP. Clients 284 and servers desiring high security SHOULD instead use TLS with 285 cryptographic algorithms that are less susceptible to compromise. 287 Authentication using the TLS Handshake Protocol confirms the identity 288 of the client and server machines. EPP uses an additional client 289 identifier and password to identify and authenticate the client's 290 user identity to the server, supplementing the machine authentication 291 provided by TLS. The identity described in the client certificate 292 and the identity described in the EPP client identifier can differ, 293 as a server can assign multiple user identities for use from any 294 particular client machine. Acceptable certificate identities MUST be 295 negotiated between client operators and server operators using an 296 out-of-band mechanism. Presented certificate identities MUST match 297 negotiated identities before EPP service is granted. 299 There is a risk of login credential compromise if a client does not 300 properly identify a server before attempting to establish an EPP 301 session. Before sending login credentials to the server, a client 302 needs to confirm that the server certificate received in the TLS 303 handshake is an expected certificate for the server. A client also 304 needs to confirm that the greeting received from the server contains 305 expected identification information. After establishing a TLS 306 session and receiving an EPP greeting on a protected TCP connection, 307 clients MUST compare the certificate subject and/or subjectAltName to 308 expected server identification information and abort processing if a 309 mismatch is detected. If certificate validation is successful, the 310 client then needs to ensure that the information contained in the 311 received certificate and greeting is consistent and appropriate. As 312 described above, both checks typically require an out-of-band 313 exchange of information between client and server to identify 314 expected values before in-band connections are attempted. 316 EPP TCP servers are vulnerable to common TCP denial-of-service 317 attacks including TCP SYN flooding. Servers SHOULD take steps to 318 minimize the impact of a denial-of-service attack using combinations 319 of easily implemented solutions, such as deployment of firewall 320 technology and border router filters to restrict inbound server 321 access to known, trusted clients. 323 9. TLS Usage Profile 325 The client should initiate a connection to the server and then send 326 the TLS Client Hello to begin the TLS handshake. When the TLS 327 handshake has finished the client can then send the first EPP 328 message. 330 TLS implementations are REQUIRED to support the mandatory cipher 331 suite specified in the implemented version: 333 o TLS 1.0 [RFC2246]: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 334 o TLS 1.1 [RFC4346]: TLS_RSA_WITH_3DES_EDE_CBC_SHA 335 o TLS 1.2 [RFC5246]: TLS_RSA_WITH_AES_128_CBC_SHA 337 This document is assumed to apply to future versions of TLS, in which 338 case the mandatory cipher suite for the implemented version MUST be 339 supported. 341 Mutual client and server authentication using the TLS Handshake 342 Protocol is REQUIRED. Signatures on the complete certification path 343 for both client machine and server machine MUST be validated as part 344 of the TLS handshake. Information included in the client and server 345 certificates, such as validity periods and machine names, MUST also 346 be validated. A complete description of the issues associated with 347 certification path validation can be found in RFC 5280 [RFC5280]. 348 EPP service MUST NOT be granted until successful completion of a TLS 349 handshake and certificate validation, ensuring that both the client 350 machine and the server machine have been authenticated and 351 cryptographic protections are in place. 353 If the client has external information as to the expected identity of 354 the server, the server name check MAY be omitted. For instance, a 355 client may be connecting to a machine whose address and server name 356 are dynamic but the client knows the certificate that the server will 357 present. In such cases, it is important to narrow the scope of 358 acceptable certificates as much as possible in order to prevent man- 359 in-the-middle attacks. In special cases, it might be appropriate for 360 the client to simply ignore the server's identity, but it needs to be 361 understood that this leaves the connection open to active attack. 363 During the TLS negotiation, the EPP client MUST check its 364 understanding of the server server name/IP address against the 365 server's identity as presented in the server Certificate message in 366 order to prevent man-in-the-middle attacks. In this section, the 367 client's understanding of the server's identity is called the 368 "reference identity". Checking is performed according to the 369 following rules in the specified order: 371 o If the reference identity is a server name: 373 * If a subjectAltName extension of the dNSName [CCITT.X509.1988] 374 type is present in the server's certificate, then it SHOULD be 375 used as the source of the server's identity. Matching is 376 performed as described in Section 7.2 of [RFC5280], with the 377 exception that wildcard matching (see below) is allowed for 378 dNSName type. If the certificate contains multiple names 379 (e.g., more than one dNSName field), then a match with any one 380 of the fields is considered acceptable. 381 * The '*' (ASCII 42) wildcard character is allowed in 382 subjectAltName values of type dNSName, and then only as the 383 left-most (least significant) DNS label in that value. This 384 wildcard matches any left-most DNS label in the server name. 385 That is, the subject *.example.com matches the server names 386 a.example.com and b.example.com, but does not match example.com 387 or a.b.example.com. 388 * The server's identity MAY also be verified by comparing the 389 reference identity to the Common Name (CN) [RFC4519] value in 390 the leaf Relative Distinguished Name (RDN) of the subjectName 391 field of the server's certificate. This comparison is 392 performed using the rules for comparison of DNS names in bullet 393 1 above (including wildcard matching). Although the use of the 394 Common Name value is existing practice, it is deprecated, and 395 Certification Authorities are encouraged to provide 396 subjectAltName values instead. Note that the TLS 397 implementation may represent DNs in certificates according to 398 X.500 or other conventions. For example, some X.500 399 implementations order the RDNs in a DN using a left-to-right 400 (most significant to least significant) convention instead of 401 LDAP's right-to-left convention. 403 o If the reference identity is an IP address: 405 * The iPAddress subjectAltName SHOULD be used by the client for 406 comparison. In such case the reference identity MUST be 407 converted to the "network byte order" octet string 408 representation. For IP Version 4 (as specified in RFC 791 409 [RFC0791]) the octet string will contain exactly four octets. 410 For IP Version 6 (as specified in RFC 2460 [RFC2460]) the octet 411 string will contain exactly sixteen octets. This octet string 412 is then compared against subjectAltName values of type 413 iPAddress. A match occurs if the reference identity octet 414 string and value octet strings are identical. 416 If the server identity check fails, user-oriented clients SHOULD 417 either notify the user (clients MAY give the user the opportunity to 418 continue with the EPP session in this case) or close the transport 419 connection and indicate that the server's identity is suspect. 420 Automated clients SHOULD return or log an error indicating that the 421 server's identity is suspect and/or SHOULD close the transport 422 connection. Automated clients MAY provide a configuration setting 423 that disables this check, but MUST provide a setting which enables 424 it. 426 All EPP messages MUST be sent as TLS "application data". It is 427 possible that multiple EPP messages be contained in one TLS record, 428 or that an EPP message be transferred in multiple TLS records. 430 When no data is received from a connection for a long time (where the 431 application decides what "long" means), a server MAY close the 432 connection. The server MUST attempt to initiate an exchange of 433 close_notify alerts with the client before closing the connection. 434 Servers that are unprepared to receive any more data MAY close the 435 connection after sending the close_notify alert, thus generating an 436 incomplete close on the client side. 438 10. Acknowledgements 440 This document was originally written as an individual submission 441 Internet-Draft. The PROVREG working group later adopted it as a 442 working group document and provided many invaluable comments and 443 suggested improvements. The author wishes to acknowledge the efforts 444 of WG chairs Edward Lewis and Jaap Akkerhuis for their process and 445 editorial contributions. 447 Specific suggestions that have been incorporated into this document 448 were provided by Chris Bason, Randy Bush, Patrik Faltstrom, Ned 449 Freed, James Gould, Dan Manley, and John Immordino. 451 Much of the text in the TLS Usage Profile section was cloned from the 452 current "TLS Transport Mapping for Syslog" Internet-Draft document. 454 11. References 456 11.1. Normative References 458 [CCITT.X509.1988] International International Telephone 459 and Telegraph Consultative Committee, 460 "Information Technology - Open Systems 461 Interconnection - The Directory: 462 Authentication Framework", 463 CCITT Recommendation X.509, 464 November 1988. 466 [I-D.hollenbeck-rfc4930bis] Hollenbeck, S., "Extensible Provisioning 467 Protocol (EPP)", 468 draft-hollenbeck-rfc4930bis-00 (work in 469 progress), April 2009. 471 [RFC0791] Postel, J., "Internet Protocol", STD 5, 472 RFC 791, September 1981. 474 [RFC0793] Postel, J., "Transmission Control 475 Protocol", STD 7, RFC 793, 476 September 1981. 478 [RFC2119] Bradner, S., "Key words for use in RFCs 479 to Indicate Requirement Levels", BCP 14, 480 RFC 2119, March 1997. 482 [RFC2246] Dierks, T. and C. Allen, "The TLS 483 Protocol Version 1.0", RFC 2246, 484 January 1999. 486 [RFC2460] Deering, S. and R. Hinden, "Internet 487 Protocol, Version 6 (IPv6) 488 Specification", RFC 2460, December 1998. 490 [RFC4519] Sciberras, A., "Lightweight Directory 491 Access Protocol (LDAP): Schema for User 492 Applications", RFC 4519, June 2006. 494 11.2. Informative References 496 [RFC2581] Allman, M., Paxson, V., and W. Stevens, 497 "TCP Congestion Control", RFC 2581, 498 April 1999. 500 [RFC2914] Floyd, S., "Congestion Control 501 Principles", BCP 41, RFC 2914, 502 September 2000. 504 [RFC4346] Dierks, T. and E. Rescorla, "The 505 Transport Layer Security (TLS) Protocol 506 Version 1.1", RFC 4346, April 2006. 508 [RFC4934] Hollenbeck, S., "Extensible Provisioning 509 Protocol (EPP) Transport Over TCP", 510 RFC 4934, May 2007. 512 [RFC5246] Dierks, T. and E. Rescorla, "The 513 Transport Layer Security (TLS) Protocol 514 Version 1.2", RFC 5246, August 2008. 516 [RFC5280] Cooper, D., Santesson, S., Farrell, S., 517 Boeyen, S., Housley, R., and W. Polk, 518 "Internet X.509 Public Key 519 Infrastructure Certificate and 520 Certificate Revocation List (CRL) 521 Profile", RFC 5280, May 2008. 523 Appendix A. Changes from RFC 4934 525 1. Changed "This document obsoletes RFC 3734" to "This document is 526 intended to obsolete RFC 4934". 527 2. Replaced references to RFC 3280 with references to 5280. 528 3. Replaced references to RFC 3734 with references to 4934. 529 4. Updated references to RFC 4346 and TLS 1.1 with references to 530 5246 and TLS 1.2. 531 5. Replaced references to RFC 4930 with references to 4930bis. 533 6. Added clarifying TLS Usage Profile section and included 534 references. 535 7. Move the paragraph that begins with "Mutual client and server 536 authentication" from the Security Considerations section to the 537 TLS Usage Profile section. 538 8. Added "TLS Transport Mapping for Syslog" acknowledgement. 540 Author's Address 542 Scott Hollenbeck 543 VeriSign, Inc. 544 21345 Ridgetop Circle 545 Dulles, VA 20166-6503 546 US 548 EMail: shollenbeck@verisign.com