Internet Engineering Task Force Eric Brunner-Williams
Internet-Draft Editor
May, 2002 Expires December 2002
Extensible Provisioning Protocol Transport Over BEEP
<draft-ietf-provreg-epp-beep-02.txt>
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/<path>" 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 <majordomo@cafax.se> 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
<logout> 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: <wait for incoming connection>
L: <open connection>
L: RPY 0 0 . 0 252
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri="http://invalid.tld/beep/epp" />
L: <profile uri="http://xml.resource.org/profiles/TLS" />
L: <profile uri="http://xml.resource.org/profiles/sasl/OTP" />
L: </greeting>
L: END
I: RPY 0 0 . 0 51
I: Content-Type: application/beep+xml
I:
I: <greeting/>
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 <login> element, and a server may send
an optional <greeting> 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: <start number="1">
I: <profile uri="http://www.invalid.tld/beep/epp">
I: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
I: </profile>
I: </start>
I: END
L:
L: RPY 0 1 . 252 98
L: Content-Type: application/beep+xml
L:
L: <profile uri="http://www.invalid.tld/beep/epp" />
L: END
On successful establishment of an EPP session, the server returns an
optional EPP <greeting> 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: <start number="1">
I: <profile uri="http://www.invalid.tld/beep/epp">
I: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
I: </profile>
I: </start>
I: END
L:
L: RPY 0 1 . 252 86
L: Content-Type: application/beep+xml
L:
L: <profile uri="http://www.invalid.tld/beep/epp">
L: <error code='551'>authorization failed</error>
L: </profile>
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: <start number="1">
I: <profile uri="http://www.invalid.tld/beep/epp">
I: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
I: </profile>
I: </start>
I: END
L:
L: RPY 0 1 . 252 98
L: Content-Type: application/beep+xml
L:
L: <profile uri="http://www.invalid.tld/beep/epp" />
L: END
EPP session authentication is performed as part of data exchange on
the channel using the EPP <login> 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 <epp version="1.0"> and ended with the EPP tag </epp>.
For example, to exchange the following message body that conforms the
XML [7] Schema [8],[9] definition of EPP messages:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:iana:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<unspec/>
<trID>
<clTRID>ABC-12346</clTRID>
<svTRID>54322-XYZ</svTRID>
</trID>
</response>
</epp>
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: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
L: <epp xmlns="urn:iana:xml:ns:epp-1.0"
L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
L: xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
L: <response>
L: <result code="1000">
L: <msg>Command completed successfully</msg>
L: </result>
L: <unspec/>
L: <trID>
L: <clTRID>ABC-12346</clTRID>
L: <svTRID>54322-XYZ</svTRID>
L: </trID>
L: </response>
L: </epp>
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 <logout> 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 <draft-ietf-provreg-epp-NN.txt>, 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,
<http://www.w3.org/TR/xmlschema-1/>.
[9] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
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 <brunner@nic-naa.net>
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 <brunner@nic-naa.net>
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]
