Internet Engineering Task Force Eric Brunner-Williams Internet-Draft Editor May, 2002 Expires December 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 defines a BEEP channel profile for EPP. 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 [1]. The convention "http://invalid.tld/" is used for URIs which are referred to but not yet defined. Brunner-Williams, Ed. Expires December 2002 [Page 1] Internet-Draft EPP BEEP Transport May 2002 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 References ..................................................... 8 Editor's Address ............................................... 8 Appendix ....................................................... 9 Full Copyright Statement ....................................... 9 Acknowledgement ................................................ 10 1. Introduction The Extensible Provisioning Protocol [2] 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 an EPP session is mapped onto a [3] channel. [4] documents how a BEEP session is mapped onto a single TCP [5] connection. 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: When a BEEP session is established, the peer that awaits new connections is acting in the listening role, and the other peer, Brunner-Williams, Ed. Expires December 2002 [Page 2] Internet-Draft EPP BEEP Transport May 2002 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 initiating an exchange is also known as a client. A BEEP peer listening for an initiator is also known as a server. 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. A EPP session is established when a BEEP channel bound to the EPP profile defined in this document is started. An EPP session is normally terminated by the client issuing an EPP command. Once the client sends this command, it may no longer send traffic on the corresponding channel. Similarly, once the server receives and fully processes this command, the EPP session is complete, and the server may no longer send traffic on that channel. 2.1 Session Layer Interface This memo defines a BEEP channel profile for EPP using the URI: http://invalid.tld/beep/epp 2.1.1 Protocol Identification and Naming Conventions Each 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 to be used for data exchange between the client and server. See [2] for the details. 2.1.2 Connection Establishment A BEEP connection MUST be established prior to establishing an EPP session. The SRV algorithm [6] 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). Brunner-Williams, Ed. Expires December 2002 [Page 3] Internet-Draft EPP BEEP Transport May 2002 Example: Identification of EPP profile after BEEP session establishment L: L: L: RPY 0 0 . 0 252 L: Content-Type: application/beep+xml L: L: L: L: L: L: L: END I: RPY 0 0 . 0 51 I: Content-Type: application/beep+xml I: I: I: 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 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 A client may send an optional element, and a server may send an optional element, during the establishment of a EPP session. If these optional elements are sent over the EPP EPP session, then the BEEP channel profile for EPP exchanges them as piggybacked data during BEEP channel creation. For example: I: MSG 0 1 . 51 204 I: Content-Type: application/beep+xml I: Brunner-Williams, Ed. Expires December 2002 [Page 4] Internet-Draft EPP BEEP Transport May 2002 I: I: I: ABYTXORERLTABYL]]> I: I: I: END L: L: RPY 0 1 . 252 98 L: Content-Type: application/beep+xml L: L: L: 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. For example: I: MSG 0 1 . 51 204 I: Content-Type: application/beep+xml I: I: I: I: ABYTXORERLTABYL]]> I: I: I: END L: L: RPY 0 1 . 252 86 L: Content-Type: application/beep+xml L: L: L: authorization failed L: L: 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: Brunner-Williams, Ed. Expires December 2002 [Page 5] Internet-Draft EPP BEEP Transport May 2002 I: MSG 0 1 . 51 204 I: Content-Type: application/beep+xml I: I: I: I: ABYTXORERLTABYL]]> I: I: I: END L: L: RPY 0 1 . 252 98 L: Content-Type: application/beep+xml L: L: L: 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. Each EPP command/response payload is preceded by the EPP tag and ended with the EPP tag . For example, to exchange the following message body that conforms the XML [7] Schema [8],[9] definition of EPP messages: Command completed successfully ABC-12346 54322-XYZ The corresponding BEEP message encoding will be as follows: L: MSG 1 2 . 255 468 L: Content-Type: text/xml L: Brunner-Williams, Ed. Expires December 2002 [Page 6] Internet-Draft EPP BEEP Transport May 2002 L: L: L: L: L: Command completed successfully L: L: L: L: ABC-12346 L: 54322-XYZ L: L: L: L: 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. All EPP sessions are terminated by terminating a BEEP session. 3. Internationalization Considerations This memo introduces no international considerations beyond those introduced in [2]. 4. IANA Considerations If the IESG approves this memo for publication, then the IANA registers the profile specified in the Appendix, The EPP Profile, and selects an IANA-specified URI, e.g., http://iana.org/beep/epp The IANA registers "EPP over BEEP" as a TCP port number, as specified in the Appendix, The System (Well-Known) TCP port number for EPP over BEEP. 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 Brunner-Williams, Ed. Expires December 2002 [Page 7] Internet-Draft EPP BEEP Transport May 2002 attacks is provided by network intrusion detection and load distribution systems. Consult [2] Section 7 for a discussion of EPP-specific security issues. Consult [3] Section 9 for a discussion of BEEP-specific security issues. References [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hollenbeck, S., "Extensible Provisioning Protocol", Internet- Draft , work in progress. [3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [5] J. Postel, "Transmission Control Protocol", STD 7, RFC 793, September 1981. [6] Gulbrandsen, A., Vixie, P., Esibov, L., "A DNS RR for specifying the location of services", RFC 2782, February 2000. [7] Bray, T., et al, "Extensible Markup Language (XML) 1.0 (Second Edition)", 6 October 2000. [8] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . Editor's Address Eric Brunner-Williams 1415 Forest Ave., Portland, ME 04103 brunner@nic-naa.net Brunner-Williams, Ed. Expires December 2002 [Page 8] Internet-Draft EPP BEEP Transport May 2002 Appendix The EPP Profile Profile Identification: http://invalid.tld/beep/epp Messages exchanged during Channel Creation: hello, greeting Messages starting one-to-one exchanges: hello, command Messages in positive replies: greeting, response Messages in negative replies: error Messages in one-to-many exchanges: none Message Syntax: command, response, defined in [2] Message Semantics: c.f., [2] Contact Information: Eric Brunner-Williams The System (Well-Known) TCP port number for EPP over BEEP Protocol Number: TCP Message Formats, type, Opcodes, and Sequences: c.f., Section 2 Functions: c.f., [2] Use of Broadcast/Multicast: none Proposed Name: EPP over BEEP Short name: epp-beep Contact Information: Eric Brunner-Williams 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 Brunner-Williams, Ed. Expires December 2002 [Page 9] Internet-Draft EPP BEEP Transport May 2002 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 Many people have contributed input and commentary to earlier versions of this document, including but not limited to: Ayesha Demaraju (co- author), Ning Zhang (co-author), Marshall Rose (contributor), and Scott Hollenbeck and Rick Wesson, working group members. Funding for the RFC editor function is currently provided by the Internet Society. Brunner-Williams, Ed. Expires December 2002 [Page 10]