Internet Engineering Task Force Eric Brunner-Williams Internet-Draft wampumpeag Ayesha Damaraju Ning Zhang NeuStar November, 2001 Expires April 2002 Extensible Provisioning Protocol Transport Over BEEP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo documents how an EPP (Extensible Provisioning Protocol) session is mapped onto a single BEEP (Blocks Extensible Exchange Protocol) session. 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]. Brunner, et al Expires April 2002 [Page 1] Internet-Draft EPP BEEP Transport November 2001 Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 1 Abstract ....................................................... 1 Table of Contents .............................................. 2 1. Introduction ................................................ 2 2. Session Mangement ........................................... 2 2.1 Session Layer Interface ................................. 3 2.1.1 Protocol Identification and Naming Conventions ..... 3 2.1.2 Connection Establishment ........................... 4 2.1.3 Authentication & Confidentiality ................... 4 2.1.4 EPP Session Initialization ......................... 5 2.1.5 Authorization ...................................... 5 2.1.6 Data Exchange (use of XML and MIME) ................ 6 2.1.7 Session Termination ................................ 7 3. Internationalization Considerations ......................... 8 4. IANA Considerations ......................................... 8 5. Security Considerations ..................................... 8 5.1 Session Layer ........................................... 8 5.2 Authentication .......................................... 8 References ..................................................... 8 Editors' Addresses ............................................. 9 Full Copyright Statement ....................................... 10 Acknowledgement ................................................ 10 1. Introduction [EPP] (Extensible Provisioning Protocol) defines generic object management operations and an extensible framework that maps protocol operations to objects stored in a shared central repository. This memo documents how a EPP session is mapped onto a single [BEEP] session. [RFC3081] documents how a BEEP session is mapped onto a single TCP [RFC793] connection. Refer to Section 2.5 of [BEEP] for an explanation of the mapping requirements. This memo is being discussed on the "ietf-provreg" mailing list. To join the list, send a message to with the words "subscribe ietf-provreg" in the body of the message. There is a web site for the list archives at http://www.cafax.se/ietf-provreg. 2. Session Management Although BEEP is peer-to-peer, it is convenient to label each peer in the context of the role it is performing at a given time: Brunner, et al Expires April 2002 [Page 2] Internet-Draft EPP BEEP Transport November 2001 When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, which establishes a connection to the listener, is acting in the initiating role. In the examples which follow, these are referred to as "L:" and "I:", respectively. A BEEP peer starting an exchange is termed the client; similarly, the other BEEP peer is termed the server. In the examples which follow, these are referred to as "C:" and "S:", respectively. Typically, a BEEP peer acting in the server role is also acting in a listening role. However, because BEEP is peer-to-peer in nature, no such requirement exists. Mapping EPP session management facilities onto BEEP services is straight forward. A BEEP session is established when a TCP connection is established between two BEEP peers: the BEEP peer that issues a passive TCP OPEN call is termed the listener (server); and, the BEEP peer that issues an active TCP OPEN call is termed the initiator (client). A EPP session is established when a BEEP channel is established. The EPP greeting message will be sent on the BEEP channel when the BEEP channel is established. An EPP session is nominally ended by the client issuing an EPP command which terminates the respective BEEP channel. A server receiving an EPP command MUST end the EPP session and release the BEEP channel. 2.1 Session Layer Interface EPP (version 1.0) is specified as a BEEP service and identified by a profile as a URI prefix: http://www.neulevel.com/profiles/EPP/1.0 /* XXX */ Note: The final designation of the protocol identification will determine the actual profile URI prefix. 2.1.1 Protocol Identification and Naming Conventions Each and every message exchanged over a BEEP channel must be enclosed in protocol identifier tag which is "epp". The protocol identifier consists of attribute "version" which identifies the version of EPP Brunner, et al Expires April 2002 [Page 3] Internet-Draft EPP BEEP Transport November 2001 to be used for data exchange between the client and server. See [EPP] for the details. 2.1.2 Connection Establishment A BEEP connection MUST be established prior establishing an EPP session. The SRV algorithm [RFC2782] is used to determine the TCP/IP addressing information assigned to the peers; i.e.: * Service: "epp" * Protocol: "tcp" On successful establishment of a BEEP connection, the greeting returned by the server must include an EPP profile, and optionally TLS and/or SASL profile(s). Example: Identification of EPP profile after BEEP session establishment S: S: S: RPY 0 0 . 0 252 S: Content-Type: application/beep+xml S: S: S: /* XXX */ S: S: S: S: END C: RPY 0 0 . 0 51 C: Content-Type: application/beep+xml C: C: C: END 2.1.3 Authentication & Confidentiality Authentication is a matter of provisioning for each BEEP peer. Peer authentication/User authentication is performed using one of the BEEP security and authentication service profiles, such as SASL, after a successful negotiation during greeting exchange. Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BEEP session; further no additional attempts at authentication are allowed. Confidentiality is a matter of provisioning for each BEEP peer and is Brunner, et al Expires April 2002 [Page 4] Internet-Draft EPP BEEP Transport November 2001 achieved by transport layer security, such as TLS. Typically, any data considered sensitive by an originating peer would have its content encrypted for the intended recipient peer, rather than relying on hop-by-hop encryption. Similarly, an originating peer will sign the content if end-to-end authentication is desired. 2.1.4 EPP Session Initialization When a client wants to create an EPP session, a BEEP channel needs to be created and initialized with an EPP profile. A BEEP channel is created when a BEEP start element is sent on channel 0, which is is created on BEEP connection establishment. An optional parameter corresponding to the EPP authorization sent by the client is carried within a "CDATA" element during channel creation. During the channel creation, a BEEP/EPP peer must send the EPP profile to the remote EPP peer, for example: C: MSG 0 1 . 51 204 C: Content-Type: application/beep+xml C: C: C: /* XXX */ C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 252 98 S: Content-Type: application/beep+xml S: S: /* XXX */ S: END On successful establishment of an EPP session, the server returns an optional EPP message, which identifies EPP objects and object services. 2.1.5 Authorization During channel creation, the EPP "profile" element in the BEEP "start" element may contain optional parameters, such as "userid" and "password" elements that could be used for second-level authentication, encoded and encapsulated in the "CDATA" element. Note that by the encapsulated operation failure, the channel creation will not be performed and the respective error code is returned. For example: Brunner, et al Expires April 2002 [Page 5] Internet-Draft EPP BEEP Transport November 2001 C: MSG 0 1 . 51 204 C: Content-Type: application/beep+xml C: C: C: /* XXX */ C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 252 86 S: Content-Type: application/beep+xml S: S: /* XXX */ S: authorization failed S: S: END In this case, a positive reply is sent (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed. Otherwise, the server signifies success. For example: C: MSG 0 1 . 51 204 C: Content-Type: application/beep+xml C: C: C: /* XXX */ C: ABYTXORERLTABYL]]> C: C: C: END S: S: RPY 0 1 . 252 98 S: Content-Type: application/beep+xml S: S: /* XXX */ S: END EPP session authentication is performed as part of data exchange on the channel using the EPP command. 2.1.6 Data Exchange (use of XML and MIME) The BEEP framework describes how arbitrary MIME content is exchanged as a BEEP payload. For example, to exchange the following message body that conforms the XML [XML] schema [XML SCHEMA] definition of EPP messages: Brunner, et al Expires April 2002 [Page 6] Internet-Draft EPP BEEP Transport November 2001 Command completed successfully ABC-12346 54322-XYZ The corresponding BEEP message encoding will be as follows: S: MSG 1 2 . 255 468 S: Content-Type: application/beep+xml S: S: S: S: S: S: Command completed successfully S: S: S: S: ABC-12346 S: 54322-XYZ S: S: S: S: END Note that additional MIME headers may be included, e.g., message digests. 2.1.7 Session Termination EPP session termination is performed as part of data exchange on the channel with the EPP command, which also terminates the respective BEEP channel. All EPP sessions are terminated by terminating a BEEP session. Brunner, et al Expires April 2002 [Page 7] Internet-Draft EPP BEEP Transport November 2001 3. Internationalization Considerations This memo introduces no international considerations beyond those introduced in [EPP]. 4. IANA Considerations A TCP port will need to be assigned, initially in the user port range for development and test purposes, and reassigned in the system port range, and the user port reclaimed, if this document advances to RFC (standards track) status. The IANA registers "beep" as a GSSAPI [RFC2078] service name, as specified in Section 4.1 of [BEEP]. Additional standards-track BEEP profile(s) for EPP, and standards-track features for the channel management profile for EPP may be registered. 5. Security Considerations EPP layered over BEEP provides transport security, authentication, and access control security mechanisms based on security profiles provided by the session layer. Protection against denial of service attacks is provided by network intrusion detection and load distribution systems. 5.1 Session Layer Each session is protected at the transport layer by the TLS encryption scheme that is based on secure socket layer (SSL) encryption. 5.2 Authentication BEEP uses a variant of the Simple Authentication Security Layer (SASL) mechanism described in [RFC2595] to provide a simple application-layer authentication service. The SASL security mechanism specifies provision of an authorization identifier, authentication identifier, and password as a single string separated by ASCII NUL characters. References [EPP] Hollenbeck, S., "Extensible Provisioning Protocol", Internet- Draft , work in progress. Brunner, et al Expires April 2002 [Page 8] Internet-Draft EPP BEEP Transport November 2001 [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [RFC793] J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying the location of services", RFC 2782, February 2000. [RFC2595] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [XML] Bray, T., et al, "Extensible Markup Language (XML) 1.0 (Second Edition)", 6 October 2000. http://www.w3.org/TR/REC-xml [XML-SCHEMA] XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. April 2000. http://www.w3.org/TR/2000/xmlschema-1/ XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. April 2000. http://www.w3.org/TR/2000/xmlschema-2/ Editors' Addresses Eric Brunner-Williams wampumpeag 1415 Forest Ave., Portland, ME 04103 Email: brunner@nic-naa.net Ayesha Damaraju NeuStar, Inc. 1120 Vermont Ave, N.W. Suite 400 Washington, DC 20005 Phone: +1 202 533 2600 Email: ayesha.damaraju@neustar.com Ning Zhang Brunner, et al Expires April 2002 [Page 9] Internet-Draft EPP BEEP Transport November 2001 NeuStar, Inc. 1120 Vermont Ave, N.W. Suite 400 Washington, DC 20005 Phone: +1 202 533 2600 Email: ning.zhang@neustar.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. This revision benefited from substantial contributions from Scott Hollenbeck. Brunner, et al Expires April 2002 [Page 10]