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
<draft-ietf-provreg-epp-beep-01.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 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 <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:
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
<logout> command which terminates the respective BEEP channel. A
server receiving an EPP <logout> 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: <wait for incoming connection>
S: <open connection>
S: RPY 0 0 . 0 252
S: Content-Type: application/beep+xml
S:
S: <greeting>
S: <profile uri="http://www.neulevel.com/profiles/EPP/1.0" /> /* XXX */
S: <profile uri="http://xml.resource.org/profiles/TLS" />
S: <profile uri="http://xml.resource.org/profiles/sasl/OTP" />
S: </greeting>
S: END
C: RPY 0 0 . 0 51
C: Content-Type: application/beep+xml
C:
C: <greeting/>
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: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/EPP/1.0"> /* XXX */
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 252 98
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://www.neulevel.com/profiles/EPP/1.0" /> /* XXX */
S: 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. 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: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/EPP/1.0"> /* XXX */
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 252 86
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://www.neulevel.com/profiles/EPP/1.0"> /* XXX */
S: <error code='551'>authorization failed</error>
S: </profile>
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: <start number="1">
C: <profile uri="http://www.neulevel.com/profiles/EPP/1.0"> /* XXX */
C: <![CDATA[<blob>ABYTXORERLTABYL</blob>]]>
C: </profile>
C: </start>
C: END
S:
S: RPY 0 1 . 252 98
S: Content-Type: application/beep+xml
S:
S: <profile uri="http://www.neulevel.com/profiles/EPP/1.0" /> /* XXX */
S: 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. 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
<?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:
S: MSG 1 2 . 255 468
S: Content-Type: application/beep+xml
S:
S: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
S: <epp xmlns="urn:iana:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <unspec/>
S: <trID>
S: <clTRID>ABC-12346</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S: </epp>
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 <logout> 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 <draft-ietf-provreg-epp-05.txt>, 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]