Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: May 5, 2003 November 04, 2002
Using the Internet Registry Information Service (IRIS) over the
Blocks Extensible Exchange Protocol (BEEP)
draft-ietf-crisp-iris-beep-01
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 May 5, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). 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) as described draft-ietf-
crisp-iris-core-00.txt.
Newton Expires May 5, 2003 [Page 1]
Internet-Draft iris-beep November 2002
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. URI Definition . . . . . . . . . . . . . . . . . . . . . . . . 8
7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Registry Dependent Resolution . . . . . . . . . . . . . . . . 9
7.2 Default Resolution . . . . . . . . . . . . . . . . . . . . . . 9
8. Server Authentication Methods . . . . . . . . . . . . . . . . 11
8.1 Registry Dependent Methods . . . . . . . . . . . . . . . . . . 11
8.2 Default Authentication Method . . . . . . . . . . . . . . . . 11
9. Registrations . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 BEEP Profile Registration . . . . . . . . . . . . . . . . . . 12
9.2 URI Scheme Registration . . . . . . . . . . . . . . . . . . . 12
9.3 Well-known TCP Port Registration . . . . . . . . . . . . . . . 12
10. Registry Definition Checklist . . . . . . . . . . . . . . . . 14
11. Internationalization Considerations . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
Newton Expires May 5, 2003 [Page 2]
Internet-Draft iris-beep November 2002
1. Introduction and Motivations
The proposal in this document describes the IRIS [8] application
transport binding using BEEP [2]. Requirements for IRIS and the
specification in this document are outlined in CRISP [14].
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
[5] 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 Webb applications. Beyond adhering to the guidelines
spelled out in RFC3205 [6], 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 [3], but
the common use as described in RFC2818 [10] is usually the only
method in most implementations.
Finally, the straight use of TCP such as that specified by EPP-TCP
[9] 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 Expires May 5, 2003 [Page 3]
Internet-Draft iris-beep November 2002
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 [7].
Newton Expires May 5, 2003 [Page 4]
Internet-Draft iris-beep November 2002
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 id
(which is a URN). Since the IRIS schema URN is compliant with
XML_URN, it may be abbreviated according to the rules of IRIS. To
simplify matters, it MUST be abbreviated in the use of this profile
identifier. The registry ID maybe abbreviated according to the rules
of IRIS if it qualifies for abbreviation under the rules of IRIS.
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 ID for the registry
type identified by "urn:iana:params:xml:ns:dreg1".
http://iana.org/beep/transient/crisp/iris1/dreg1
The full ABNF [12] with certain values included from IRIS [8]
follows.
profile = profile-uri "/" iris-urn "/" registry-id
profile-uri = "http://iana.org/beep/transient/crisp/"
iris-urn = // as specified by IRIS
registry-id = // 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 Expires May 5, 2003 [Page 5]
Internet-Draft iris-beep November 2002
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 UTF-8 [13] using the media-type of "application/xml"
according to RFC3023 [18]. A registry type MAY define other message
packages that are not IRIS XML instances (e.g. binary images
referenced by an IRIS response).
Newton Expires May 5, 2003 [Page 6]
Internet-Draft iris-beep November 2002
5. IRIS Message Patterns
5.1 Registry Dependent Patterns
Because each registry type is defined by a separate BEEP profile,
each registry type MAY define a separate 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
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 Expires May 5, 2003 [Page 7]
Internet-Draft iris-beep November 2002
6. URI Definition
An IRIS URI [11] has the following general syntax.
iris://<authority>/<registry-id>/<entity-class>/<entity-name>
The full ABNF [12] with certain values included from RFC2396 [11]
follows.
iris-uri = "iris://" authority "/" registry-id [ "/"
entity-class "/" entity-name ]
authority = // as specified by RFC2396
registry-id = // as specified by IRIS
entity-class = *(unreserved | escaped)
entity-name = *(unreserved | escaped)
reserved = // as specified by RFC2396
escaped = "%" hex hex
hex = "0" | "1" | "2" | "3" | "4" | "5" |
"6" | "7" | "8" | "9" | "A" | "B" |
"C" | "D" | "E" | "F" | "a" | "b" |
"c" | "d" | "e" | "f"
An IRIS URI MUST NOT be a relative URI. In addition, valid URI's
with this scheme MUST always contain a registry ID (namespace
identifier), an entity class, and an entity name. In addition, the
entity class and entity name MUST be of the UTF-8 [13] character set
encoded with "application/x-www-form-urlencoded" as specified by
URL_ENC [15].
When the entity-class and entity-name components are not specified,
the defaults "service-definition" and "id" MUST be implied. For
example, "iris://com/dreg" is to be interpreted "iris://com/dreg/
service-definition/id".
Definitions of registry types SHOULD attempt to make the names of
entity classes transcribable. Despite the fact that URI's are not
friendly to all humans, they care should be taken in their definition
to make them readable and transcribable. One aspect of this is the
use of dashes to separate meaningful words over the use of other
styles such as camel back notation (e.g. "service-definition"
instead of "serviceDefinition").
Newton Expires May 5, 2003 [Page 8]
Internet-Draft iris-beep November 2002
7. URI Resolution
7.1 Registry Dependent Resolution
The IRIS URI resolution process is dependent on the registry type
used in the URI itself and keyed off of the registry ID that appears
in it. In other words, the way in which the authority component of
the URI is processed is dependent on the registry ID.
If a registry type does not explicitly define an IRIS URI resolution
process, the default URI resolution process is used (see Section 7.2.
In all cases, the authority component of the URI MUST be compliant
with RFC2396 [11].
7.2 Default Resolution
In the default resolution process, the authority component of an IRIS
URI may only contain a domain name, a domain name accompanied by a
port number, or an IP address accompanied by a port number. The
authority component of the scheme indicates the server or set of
servers authoritatively responsible for a domain according to SRV
[19] records in DNS if a domain is specified or indicates the
specific server to be queried if an IP address is specified.
The rules for resolution are:
o If the authority component is a domain name accompanied by a port
number as specified by RFC2396, the domain name is converted to an
IP address via an A record to the DNS.
o If the authority component is a domain name by itself, the SRV
algorithm is used with a service parameter of "iris" and a
protocol parameter of "tcp" to determine the IP/TCP addressing
information. If no appropriate SRV RRs are found (e.g., for
"_iris._tcp.example.com"), then the DNS is queried for the A RRs
corresponding to the domain name and the port number used is the
well-known port assigned by the IANA for IRIS using BEEP.
o If the authority component is an IP address, then the DNS is not
queried, and the IP address is used directly. If the port number
is present, it is used directly; otherwise, the port number used
is the well-known port assigned by the IANA for IRIS over BEEP.
The use of an IPv6 address in the authority component MUST conform to
RFC2732 [17].
Here are some examples of IRIS URI's and their meaning in the default
resolution process:
Newton Expires May 5, 2003 [Page 9]
Internet-Draft iris-beep November 2002
o iris://example.com/dreg/domain/example.com
* Asks a server authoritative for "example.com" about
"example.com".
o iris://com/dreg/domain/example.com
* Asks a server authoritative for "com" about "example.com".
o iris://10.0.1.1:44/dreg/domain/example.com
* Asks the server at IP address 10.0.1.1 on port 44 about the
domain "example.com".
Newton Expires May 5, 2003 [Page 10]
Internet-Draft iris-beep November 2002
8. Server Authentication Methods
8.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 server knows which set of credentials to pass
back. Because this is dependent on the authority component of the
URI, each registry type must define a server authentication method.
If a registry type does not explicitly define a server authentication
method, the default method is used (see Section 8.2.
8.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 [16] certificate and contain a
subjectAltName extension of the type dNSName.
3. The certificate MUST cryptographically verify according to the
procedures of TLS.
4. The client then checks the content of the dNSName. It must
exactly match the authority given the server using serverName.
Newton Expires May 5, 2003 [Page 11]
Internet-Draft iris-beep November 2002
9. Registrations
9.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 [8].
Message Semantics: request/response exchanges as defined by IRIS [8].
Contact Information: Andrew Newton <anewton@ecotroph.net>
9.2 URI Scheme Registration
URL scheme name: iris
URL scheme syntax: defined in Section 6.
Character encoding considerations: as defined in RFC2396 [11].
Intended usage: identifies an IRIS entity made available using the
BEEP profile for IRIS
Applications using this scheme: defined in IRIS [8].
Interoperability considerations: n/a
Security Considerations: defined in Section 13.
Relevant Publications: BEEP [2] and IRIS [8].
Contact Information: Andrew Newton <anewton@ecotroph.net>
Author/Change controller: the IESG
9.3 Well-known TCP Port Registration
Protocol Number: TCP
Newton Expires May 5, 2003 [Page 12]
Internet-Draft iris-beep November 2002
Message Formats, Types, Opcodes, and Sequences: defined in Section 3,
Section 4, and Section 5.
Functions: defined in IRIS [8].
Use of Broadcast/Multicast: none
Proposed Name: IRIS over BEEP
Short name: iris
Contact Information: Andrew Newton <anewton@ecotroph.net>
Newton Expires May 5, 2003 [Page 13]
Internet-Draft iris-beep November 2002
10. 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 authority resolution scheme - A definition of the process of
resolving the authority or a declaration to use the default
authority resolution scheme in Section 7.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 8.2.
Newton Expires May 5, 2003 [Page 14]
Internet-Draft iris-beep November 2002
11. Internationalization Considerations
URI's are not considered to be internationalized. The topic of
internationalized URI's is beyond the scope of this document and is
not specific to the IRIS URI scheme defined here. It is an issue to
be addressed by a larger scope.
The entity class and entity name components of an IRIS URI is
specified using UTF-8. This has been done for interoperability
purposes.
Newton Expires May 5, 2003 [Page 15]
Internet-Draft iris-beep November 2002
12. IANA Considerations
The IANA will need to be asked to register the IRIS URI scheme. The
IANA will need to assign a standard port number to IRIS over BEEP.
Newton Expires May 5, 2003 [Page 16]
Internet-Draft iris-beep November 2002
13. Security Considerations
Implementers should be fully aware of the security considerations
given by IRIS [8], 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://iaan.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.
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 Expires May 5, 2003 [Page 17]
Internet-Draft iris-beep November 2002
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] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC 2817, May 2000.
[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] 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.
[6] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC
3205, February 2002.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[8] Newton, A., "Internet Registry Information Service", draft-
ietf-crisp-iris-core-01 (work in progress), November 2002.
[9] Hollenbeck, S., "EPP TCP Transport", Internet Draft, a work in-
progress., January 2002.
[10] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[11] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[12] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[13] The Unicode Consortium, "The Unicode Standard, Version 2.0",
ISBN 0-201-48345-9 ISBN 0-201-48345-9, January 1988, <The
Unicode Standard, Version 2.0>.
[14] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", draft-ietf-crisp-requirements-02 (work in
progress), October 2002.
Newton Expires May 5, 2003 [Page 18]
Internet-Draft iris-beep November 2002
[15] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
[16] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[17] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[18] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[19] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
Author's Address
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@ecotroph.net
URI: http://www.verisignlabs.com/
Newton Expires May 5, 2003 [Page 19]
Internet-Draft iris-beep November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Newton Expires May 5, 2003 [Page 20]