[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/