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

Versions: 00 01 02 03 04 05 06 07 RFC 3983

Network Working Group                                          A. Newton
Internet-Draft                                            VeriSign, Inc.
Expires: August 15, 2004                                         M. Sanz
                                                                DENIC eG
                                                       February 15, 2004


   IRIS - Using the Internet Registry Information Service (IRIS) over
             the Blocks Extensible Exchange Protocol (BEEP)
                     draft-ietf-crisp-iris-beep-05

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on August 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document specifies how to use the Blocks Extensible Exchange
   Protocol (BEEP) as the application transport substrate for the
   Internet Registry Information Service (IRIS).









Newton & Sanz           Expires August 15, 2004                 [Page 1]

Internet-Draft                 iris-beep                   February 2004


Table of Contents

   1.  Introduction and Motivations . . . . . . . . . . . . . . . . .  3
   2.  Document Terminology . . . . . . . . . . . . . . . . . . . . .  4
   3.  BEEP Profile Identification  . . . . . . . . . . . . . . . . .  5
   4.  IRIS Message Packages  . . . . . . . . . . . . . . . . . . . .  6
   5.  IRIS Message Patterns  . . . . . . . . . . . . . . . . . . . .  7
   5.1 Registry Dependent Patterns  . . . . . . . . . . . . . . . . .  7
   5.2 Default Pattern  . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Server Authentication Methods  . . . . . . . . . . . . . . . .  8
   6.1 Registry Dependent Methods . . . . . . . . . . . . . . . . . .  8
   6.2 Default Authentication Method  . . . . . . . . . . . . . . . .  8
   7.  IRIS Transport Mapping Definitions . . . . . . . . . . . . . .  9
   7.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.2 Application Protocol Label . . . . . . . . . . . . . . . . . .  9
   7.3 Allowable Character Sets . . . . . . . . . . . . . . . . . . .  9
   7.4 BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Registrations  . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.1 BEEP Profile Registration  . . . . . . . . . . . . . . . . . . 10
   8.2 URI Scheme Registration  . . . . . . . . . . . . . . . . . . . 10
   8.3 Well-known TCP Port Registration . . . . . . . . . . . . . . . 11
   8.4 NAPSTR Registration  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Registry Definition Checklist  . . . . . . . . . . . . . . . . 12
   10. Internationalization Considerations  . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
       Normative References . . . . . . . . . . . . . . . . . . . . . 16
       Informative References . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18





















Newton & Sanz           Expires August 15, 2004                 [Page 2]

Internet-Draft                 iris-beep                   February 2004


1. Introduction and Motivations

   The proposal in this document describes the IRIS [6] application
   transport binding using BEEP [2].  Requirements for IRIS and the
   specification in this document are outlined in CRISP [18].

   The choice of BEEP as the transport substrate is primarily driven by
   the need to re-use an existing, well-understood protocol with all the
   necessary features to support the requirements.  This gives
   implementers a wealth of toolkits and debugging gear for use in
   constructing both servers and clients and allows operators to apply
   existing experience in issues of deployment.  It is also felt that
   the construction of a simple application transport for the specific
   purpose of IRIS would yield a similar, though likely smaller and
   probably less complete, standard after taking into consideration such
   matters as framing, authentication, etc.

   Precedents for using other transport mechanisms in layered
   applications do not seem to fit with the design goals of IRIS.  HTTP
   [14] offers many features employed for use by similar applications.
   However, it is not the intention of IRIS to be put to such uses as
   by-passing fire-walls, co-mingling URI schemes, or any other such
   methods which might lead to confusion between IRIS and traditional
   World Wide Web applications.  Beyond adhering to the guidelines
   spelled out in RFC3205 [15], the use of HTTP also offers many other
   challenges that quickly erode its appeal.  For example, the
   appropriate use of TLS [4] with HTTP is defined by RFC2817 [13], but
   the common use as described in RFC2818 [17] is usually the only
   method in most implementations.

   Finally, the straight use of TCP such as that specified by EPP-TCP
   [16] does not offer the client negotiation characteristics needed by
   a referral application where a single client, in the act of
   processing a query, may traverse multiple servers operating with
   different parameters.
















Newton & Sanz           Expires August 15, 2004                 [Page 3]

Internet-Draft                 iris-beep                   February 2004


2. Document Terminology

   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 [5].














































Newton & Sanz           Expires August 15, 2004                 [Page 4]

Internet-Draft                 iris-beep                   February 2004


3. BEEP Profile Identification

   The BEEP profile identifier for IRIS is a URI composed of the IRIS
   schema URN, followed by a slash, followed by an IRIS registry type
   (which is a URN).

   In the use of this profile identifier, the IRIS schema MUST be
   abbreviated according to the rules of IRIS.  This is possible because
   the IRIS schema URN is compliant with XML_URN [19].

   The registry type URN MUST be abbreviated according to the rules of
   IRIS (see [6]).  This is possible because the registry type URN is
   compliant with XML_URN [19].

   The following is an example of an IRIS profile identifier for BEEP.
   It identifies the version of IRIS to match that specified by
   "urn:iana:params:xml:ns:iris1" with a registry type URN of
   "urn:iana:params:xml:ns:dreg1".


     http://iana.org/beep/transient/crisp/iris1/dreg1

   The full ABNF [8] with certain values included from IRIS [6] follows.

     profile            = profile-uri "/" iris-urn "/" registry-urn
     profile-uri        = "http://iana.org/beep/transient/crisp/"
     iris-urn           = // as specified by IRIS
     registry-urn       = // as specified by IRIS

   This URI is used in the "profile" element in BEEP during channel
   creation.  According to the rules of BEEP, multiple "profile"
   elements may be offered thus allowing for a negotiation of the
   version of IRIS to be used for every registry type being served.

   Once this profile is accepted and the channel is created, the state
   of the channel is considered ready to exchange IRIS messages.















Newton & Sanz           Expires August 15, 2004                 [Page 5]

Internet-Draft                 iris-beep                   February 2004


4. IRIS Message Packages

   The BEEP profile for IRIS transmits XML [1] containing the requests
   and responses for IRIS registries.  These XML instances MUST be
   encoded as Unicode [9] using the media-type of "application/xml"
   according to RFC3023 [11].

   XML processors are obliged to recognize both UTF-8 and UTF-16 [9]
   encodings.  XML provides for mechanisms to identify and use other
   character encodings by means of the "encoding" attribute in the
   declaration.  Absence of this attribute or a byte order mark (BOM)
   means a default of UTF-8 encoding.  Thus, for compatibility reasons,
   and per RFC 2277 [12], use of UTF-8 is RECOMMENDED with this
   transport mapping.  UTF-16 is OPTIONAL.  Other encodings MUST NOT be
   used.

   A registry type MAY define other message packages that are not IRIS
   XML instances (e.g.  binary images referenced by an IRIS response).

































Newton & Sanz           Expires August 15, 2004                 [Page 6]

Internet-Draft                 iris-beep                   February 2004


5. IRIS Message Patterns

5.1 Registry Dependent Patterns

   Because each registry type is defined by a separate BEEP profile (see
   [6]), each registry type MAY define a different message pattern.
   These patterns MUST be within the allowable scope of BEEP [2].  If a
   registry type does not explicitly define a message pattern, the
   default pattern is used (see Section 5.2).

   However, each registry type MUST be capable of supporting the default
   pattern (Section 5.2) for use with the <lookupEntity> query in IRIS.

5.2 Default Pattern

   The default BEEP profile for IRIS only has a one-to-one request/
   response message pattern.  This exchange involves sending an IRIS XML
   instance, which results in a response of an IRIS XML instance.

   The request is sent by the client using an "MSG" message containing a
   valid IRIS XML instance.  The server responds with an "RPY" message
   containing a valid IRIS XML instance.  The "ERR" message is used for
   sending fault codes.  The list of allowable fault codes is listed in
   BEEP [2].



























Newton & Sanz           Expires August 15, 2004                 [Page 7]

Internet-Draft                 iris-beep                   February 2004


6. Server Authentication Methods

6.1 Registry Dependent Methods

   When using the TLS [4] tuning profile in BEEP, it is possible to
   verify the authenticity of the server.  However, a convention is
   needed to conduct this authentication.  This convention dictates the
   name of the authority used by a client to ask for authentication
   credentials so that the server knows which set of credentials to pass
   back.  Because this is dependent on the authority component of the
   URI, each registry type SHOULD define a server authentication method.

   If a registry type does not explicitly define a server authentication
   method, the default method is used (see Section 6.2).

6.2 Default Authentication Method

   The default server authentication method is as follows:

   1.  When connecting to a server, the client MUST present the name of
       the authority to the server using the BEEP [2] serverName
       mechanism.  For instance, if the URI "iris:com/dreg/domain/
       example.com" is being resolved, the client would use the
       serverName="com" attribute during the BEEP session instantiation.

   2.  During TLS negotiation, the server presents to the client a
       certificate for the authority given in serverName.  This
       certificate MUST be an X509 [10] certificate.  This certificate
       MUST contain the authority in either the subjectDN or the
       subjectAltName extension of type dNSName.

   3.  The certificate MUST cryptographically verify according to the
       procedures of TLS.

   4.  The client then checks the content of the subjectDN or dNSName.
       Matching for both the types is case insensitive.  A wildcard
       character ('*') MAY be used as the left-most component of the
       name.  If more than one dNSName is present, a match on any one is
       acceptable.












Newton & Sanz           Expires August 15, 2004                 [Page 8]

Internet-Draft                 iris-beep                   February 2004


7. IRIS Transport Mapping Definitions

   This section lists the definitions required by IRIS [6] for transport
   mappings.

7.1 URI Scheme

   The URI scheme name specific to BEEP over IRIS MUST be "iris.beep".

7.2 Application Protocol Label

   The application protocol label MUST be "iris.beep".

7.3 Allowable Character Sets

   See Section 4 and Section 10.

7.4 BEEP Mapping

   The mapping of IRIS in this document is specific to RFC 3080 [2].
   This mapping MUST use TCP as specified by RFC 3081 [3].






























Newton & Sanz           Expires August 15, 2004                 [Page 9]

Internet-Draft                 iris-beep                   February 2004


8. Registrations

8.1 BEEP Profile Registration

   Profile Identification: http://iana.org/beep/transient/crisp/iris/0.2

   Messages exchanged during Channel Creation: none

   Messages starting one-to-one exchanges: IRIS XML instance

   Messages in positive replies: IRIS XML instance

   Messages in negative replies: none

   Messages in one-to-many exchanges: none

   Message Syntax: IRIS XML instances as defined by IRIS [6].

   Message Semantics: request/response exchanges as defined by IRIS [6].

   Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
   <sanz@denic.de>

8.2 URI Scheme Registration

   URL scheme name: iris.beep

   URL scheme syntax: defined in Section 7.1 and [6].

   Character encoding considerations: as defined in RFC2396 [7].

   Intended usage: identifies an IRIS entity made available using the
   BEEP profile for IRIS

   Applications using this scheme: defined in IRIS [6].

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: BEEP [2] and IRIS [6].

   Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
   <sanz@denic.de>

   Author/Change controller: the IESG





Newton & Sanz           Expires August 15, 2004                [Page 10]

Internet-Draft                 iris-beep                   February 2004


8.3 Well-known TCP Port Registration

   Protocol Number: TCP

   Message Formats, Types, Opcodes, and Sequences: defined in Section 3,
   Section 4, and Section 5.

   Functions: defined in IRIS [6].

   Use of Broadcast/Multicast: none

   Proposed Name: IRIS over BEEP

   Short name: iris.beep

   Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
   <sanz@denic.de>

8.4 NAPSTR Registration

   Application Protocol Label: iris.beep

   Intended usage: identifies an IRIS server using BEEP

   Interoperability considerations: n/a

   Security Considerations: defined in Section 12.

   Relevant Publications: BEEP [2] and IRIS [6].

   Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
   <sanz@denic.de>

   Author/Change controller: the IESG

















Newton & Sanz           Expires August 15, 2004                [Page 11]

Internet-Draft                 iris-beep                   February 2004


9. Registry Definition Checklist

   Specifications of registry types MUST include the following explicit
   definitions:

   o  message pattern - A definition of the message pattern for use with
      BEEP or a declaration to use the default message pattern in
      Section 5.2.

   o  server authentication method - A definition of the method to use
      for server authentication with TLS or a declaration to use the
      default server authentication method in Section 6.2 or a
      declaration to use no server authentication at all.






































Newton & Sanz           Expires August 15, 2004                [Page 12]

Internet-Draft                 iris-beep                   February 2004


10. Internationalization Considerations

   See Section 4.
















































Newton & Sanz           Expires August 15, 2004                [Page 13]

Internet-Draft                 iris-beep                   February 2004


11. IANA Considerations

   Registrations with the IANA are described in Section 8.
















































Newton & Sanz           Expires August 15, 2004                [Page 14]

Internet-Draft                 iris-beep                   February 2004


12. Security Considerations

   Implementers should be fully aware of the security considerations
   given by IRIS [6], BEEP [2], and TLS [4].  With respect to server
   authentication with the use of TLS, see .

   Clients SHOULD be prepared to use the following BEEP tuning profiles:

   o  http://iana.org/beep/SASL/DIGEST-MD5 - for user authentication
      without the need of session encryption.

   o  http://iana.org/beep/SASL/OTP - for user authentication without
      the need of session encryption.

   o  http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
      cipher - for encryption.

   o  http://iana.org/beep/TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
      cipher with client-side certificates - for encryption and user
      authentication.

   Anonymous client access SHOULD be considered in one of two methods:

   1.  When no authentication tuning profile has been used.

   2.  Using the SASL anonymous profile: http://iana.org/beep/SASL/
       ANONYMOUS

   IRIS contains a referral mechanism as a standard course of operation.
   However, care should be taken that user authentication mechanisms do
   not hand user credentials to untrusted servers.  Therefore, clients
   SHOULD NOT use the http://iana.org/beep/SASL/PLAIN tuning profile.



















Newton & Sanz           Expires August 15, 2004                [Page 15]

Internet-Draft                 iris-beep                   February 2004


Normative References

   [1]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/
         REC-xml-19980210>.

   [2]   Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.

   [3]   Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
         2001.

   [4]   Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
         1999.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCP 14, March 1997.

   [6]   Newton, A. and M. Sanz, "Internet Registry Information
         Service", draft-ietf-crisp-iris-core-05 (work in progress),
         January 2004.

   [7]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [8]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [9]   The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
         0-201-61633-5, 2000, <The Unicode Standard, Version 3>.

   [10]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [11]  Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

   [12]  Alvestrand, H., "IETF Policy on Character Sets and Languages",
         BCP 18, RFC 2277, January 1998.









Newton & Sanz           Expires August 15, 2004                [Page 16]

Internet-Draft                 iris-beep                   February 2004


Informative References

   [13]  Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
         RFC 2817, May 2000.

   [14]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [15]  Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC
         3205, February 2002.

   [16]  Hollenbeck, S., "EPP TCP Transport", Internet Draft,
         draft-ietf-provreg-epp-tcp-06, January 2002.

   [17]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [18]  Newton, A., "Cross Registry Internet Service Protocol (CRISP)
         Requirements", RFC 3707, February 2004.

   [19]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
         February 2004.


Authors' Addresses

   Andrew L. Newton
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   USA

   Phone: +1 703 948 3382
   EMail: anewton@verisignlabs.com; andy@hxr.us
   URI:   http://www.verisignlabs.com/


   Marcos Sanz
   DENIC eG
   Wiesenhuettenplatz 26
   D-60329 Frankfurt
   Germany

   EMail: sanz@denic.de
   URI:   http://www.denic.de/






Newton & Sanz           Expires August 15, 2004                [Page 17]

Internet-Draft                 iris-beep                   February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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 assignees.

   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



Newton & Sanz           Expires August 15, 2004                [Page 18]

Internet-Draft                 iris-beep                   February 2004


   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.











































Newton & Sanz           Expires August 15, 2004                [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/