3983
PROPOSED STANDARD
Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
Authors: A. Newton, M. Sanz
Date: January 2005
Area: app
Working Group: crisp
Stream: IETF
Updated by:
RFC 8996
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). [STANDARDS-TRACK]
RFC 3983
PROPOSED STANDARD
Updated by: 8996
Network Working Group A. Newton
Request for Comments: 3983 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
<span class="h1">Using the Internet Registry Information Service (IRIS) over</span>
<span class="h1">the Blocks Extensible Exchange Protocol (BEEP)</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
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).
Table of Contents
<a href="#section-1">1</a>. Introduction and Motivations . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Document Terminology . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. BEEP Profile Identification . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. IRIS Message Packages . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. IRIS Message Patterns . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.1">5.1</a>. Registry Dependent Patterns. . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5.2">5.2</a>. Default Pattern. . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Server Authentication Methods . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-6.1">6.1</a>. Registry Dependent Methods. . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-6.2">6.2</a>. Basic Server Authentication Method. . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-7">7</a>. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.1">7.1</a>. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.2">7.2</a>. Application Protocol Label . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.3">7.3</a>. Allowable Character Sets . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7.4">7.4</a>. BEEP Mapping . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8">8</a>. Registrations . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.1">8.1</a>. BEEP Profile Registration. . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.2">8.2</a>. URI Scheme Registration. . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="grey">Newton & Sanz Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<a href="#section-8.3">8.3</a>. Well-Known TCP Port Registration . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.4">8.4</a>. S-NAPTR Registration . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-9">9</a>. Registry Definition Checklist . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-10">10</a>. Internationalization Considerations . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-11">11</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-12">12</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-13">13</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-13.1">13.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-13.2">13.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction and Motivations</span>
The proposal in this document describes the IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>] application
transport binding that uses BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>]. Requirements for IRIS and the
specification in this document are outlined in CRISP [<a href="#ref-19" title=""Cross Registry Internet Service Protocol (CRISP) Requirements"">19</a>].
The choice of BEEP as the transport substrate is primarily driven by
the need to reuse an existing, well-understood protocol with all the
necessary features to support the requirements. This would give
implementers a wealth of toolkits and debugging gear for use in
constructing both servers and clients and allow operators to apply
existing experience in issues of deployment. The construction of a
simple application transport for the specific purpose of IRIS would
yield a similar standard, though likely smaller and less complete,
after taking into consideration matters such as framing and
authentication.
Precedents for using other transport mechanisms in layered
applications do not seem to fit with the design goals of IRIS. HTTP
[<a href="#ref-15" title=""Hypertext Transfer Protocol -- HTTP/1.1"">15</a>] offers many features employed for use by similar applications.
However, IRIS is not intended to be put to uses such as bypassing
firewalls, commingling URI schemes, or any other methods that might
lead to confusion between IRIS and traditional World Wide Web
applications. Beyond adhering to the guidelines spelled out in <a href="./rfc3205">RFC</a>
<a href="./rfc3205">3205</a> [<a href="#ref-16" title=""On the use of HTTP as a Substrate"">16</a>], the use of HTTP also offers many other challenges that
quickly erode its appeal. For example, the appropriate use of TLS
[<a href="#ref-4" title=""The TLS Protocol Version 1.0"">4</a>] with HTTP is defined by <a href="./rfc2817">RFC 2817</a> [<a href="#ref-14" title=""Upgrading to TLS Within HTTP/1.1"">14</a>], but the common use, as
described in <a href="./rfc2818">RFC 2818</a> [<a href="#ref-18" title=""HTTP Over TLS"">18</a>], is usually the only method in most
implementations.
Finally, the use of IRIS directly over TCP, such as that specified by
EPP-TCP [<a href="#ref-17" title=""EPP TCP Transport"">17</a>], does not offer the client negotiation characteristics
needed by a referral application in which a single client, in
processing a query, may traverse multiple servers operating with
different parameters.
<span class="grey">Newton & Sanz Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Document Terminology</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-5" title=""Key words for use in RFCs to Indicate Requirement Levels"">5</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. BEEP Profile Identification</span>
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 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 [<a href="#ref-20" title=""The IETF XML Registry"">20</a>].
The registry type URN MUST be abbreviated according to the rules of
IRIS (see [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]). This is possible because the registry type URN is
compliant with XML_URN [<a href="#ref-20" title=""The IETF XML Registry"">20</a>].
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":
<a href="http://iana.org/beep/iris1/dreg1">http://iana.org/beep/iris1/dreg1</a>
The full ABNF [<a href="#ref-8" title=""Augmented BNF for Syntax Specifications: ABNF"">8</a>] follows, with certain values included from IRIS
[<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]:
profile = profile-uri "/" iris-urn-abbrev
"/" registry-urn-abbrev
profile-uri = "<a href="http://iana.org/beep/">http://iana.org/beep/</a>"
iris-urn-abbrev = // as specified by IRIS
registry-urn-abbrev = // 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 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 channel
is considered ready to exchange IRIS messages. A server MUST honor
queries for all advertised registry types on any channel opened with
an IRIS profile URI.
<span class="grey">Newton & Sanz Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IRIS Message Packages</span>
The BEEP profile for IRIS transmits XML [<a href="#ref-1" title=""Extensible Markup Language (XML) 1.0"">1</a>] containing the requests
and responses for IRIS registries. These XML instances MUST be
encoded as Unicode [<a href="#ref-9" title=""The Unicode Standard, Version 3"">9</a>] using the media-type of "application/xml"
according to <a href="./rfc3023">RFC 3023</a> [<a href="#ref-11" title=""XML Media Types"">11</a>].
XML processors are obliged to recognize both UTF-8 and UTF-16 [<a href="#ref-9" title=""The Unicode Standard, Version 3"">9</a>]
encodings. XML allows 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) indicates a
default of UTF-8 encoding. Thus, for compatibility reasons, and per
<a href="./rfc2277">RFC 2277</a> [<a href="#ref-12" title=""IETF Policy on Character Sets and Languages"">12</a>], 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).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IRIS Message Patterns</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Registry Dependent Patterns</span>
Because each registry type is defined by a separate BEEP profile (see
[<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]), each registry type MAY define a different message pattern.
These patterns MUST be within the allowable scope of BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>]. If a
registry type does not explicitly define a message pattern, the
default pattern is used (see <a href="#section-5.2">Section 5.2</a>).
However, each registry type MUST be capable of supporting the default
pattern (<a href="#section-5.2">Section 5.2</a>) for use with the <lookupEntity> query in IRIS.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Default Pattern</span>
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 client sends the request by 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 [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>].
<span class="grey">Newton & Sanz Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Server Authentication Methods</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Registry Dependent Methods</span>
When the TLS [<a href="#ref-4" title=""The TLS Protocol Version 1.0"">4</a>] tuning profile in BEEP is used, 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 a client uses 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 basic server authentication method (<a href="#section-6.2">Section 6.2</a>) is used.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Basic Server Authentication Method</span>
The basic server authentication method is as follows:
1. When connecting to a server, the client MUST present the name of
the authority to the server by using the BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>] serverName
mechanism. For instance, if the URI "iris:dreg1//com/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 X.509 certificate [<a href="#ref-10" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">10</a>]. This certificate
MUST contain the authority in either the subjectDN or the
subjectAltName extension of type dNSName.
3. The certificate MUST be cryptographically verified according to
the procedures of TLS.
4. The client then checks the subject of the certificate for a case
insensitive match in the following order:
1. Any of the dNSName types in the subjectAltName.
2. The subjectDN consisting solely of 'dc' components, in which
each 'dc' component represents a label from the authority
name (e.g., example.com is dc=example, dc=com).
3. A subjectDN in which the left-most component is a 'cn'
component containing the name of the authority. A wildcard
character ('*') MAY be used as the left-most label of the
name in the 'cn' component.
<span class="grey">Newton & Sanz Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
If the subject of the certificate does not match any of these
name components, then the certificate is invalid for representing
the authority.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IRIS Transport Mapping Definitions</span>
This section lists the definitions required by IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>] for transport
mappings.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. URI Scheme</span>
The URI scheme name specific to BEEP over IRIS MUST be "iris.beep".
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Application Protocol Label</span>
The application protocol label MUST be "iris.beep".
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Allowable Character Sets</span>
See Sections <a href="#section-4">4</a> and <a href="#section-10">10</a>.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. BEEP Mapping</span>
The mapping of IRIS in this document is specific to <a href="./rfc3080">RFC 3080</a> [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>].
This mapping MUST use TCP as specified by <a href="./rfc3081">RFC 3081</a> [<a href="#ref-3" title=""Mapping the BEEP Core onto TCP"">3</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Registrations</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. BEEP Profile Registration</span>
Profile Identification: <a href="http://iana.org/beep/iris1">http://iana.org/beep/iris1</a>
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 [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Message Semantics: request/response exchanges as defined by IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
<span class="grey">Newton & Sanz Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. URI Scheme Registration</span>
URL scheme name: iris.beep
URL scheme syntax: defined in <a href="#section-7.1">Section 7.1</a> and [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Character encoding considerations: as defined in <a href="./rfc2396">RFC 2396</a> [<a href="#ref-7" title=""Uniform Resource Identifiers (URI): Generic Syntax"">7</a>]
Intended usage: identifies an IRIS entity made available using the
BEEP profile for IRIS
Applications using this scheme: defined in IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Interoperability considerations: n/a
Security Considerations: defined in <a href="#section-12">Section 12</a>.
Relevant Publications: BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>] and IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Author/Change controller: the IESG
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Well-Known TCP Port Registration</span>
Protocol Number: TCP
Message Formats, Types, Opcodes, and Sequences: defined in Sections
3, 4, and 5.
Functions: defined in IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
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>
<span class="grey">Newton & Sanz Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. S-NAPTR Registration</span>
Application Protocol Label: iris.beep
Intended usage: identifies an IRIS server using BEEP
Interoperability considerations: n/a
Security Considerations: defined in <a href="#section-12">Section 12</a>
Relevant Publications: BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>] and IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>]
Contact Information: Andrew Newton <andy@hxr.us> and Marcos Sanz
<sanz@denic.de>
Author/Change controller: the IESG
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Registry Definition Checklist</span>
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
<a href="#section-5.2">Section 5.2</a>.
o server authentication method -- a definition of the method to use
for server authentication with TLS, a declaration to use the basic
server authentication method in <a href="#section-6.2">Section 6.2</a>, or a declaration to
use no server authentication at all.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Internationalization Considerations</span>
See <a href="#section-4">Section 4</a>.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. IANA Considerations</span>
Registrations with the IANA are described in <a href="#section-8">Section 8</a>.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Security Considerations</span>
Implementers should be fully aware of the security considerations
given by IRIS [<a href="#ref-6" title=""IRIS: The Internet Registry Information Service (IRIS) Core Protocol"">6</a>], BEEP [<a href="#ref-2" title=""The Blocks Extensible Exchange Protocol Core"">2</a>], and TLS [<a href="#ref-4" title=""The TLS Protocol Version 1.0"">4</a>]. With respect to server
authentication with the use of TLS, see <a href="#section-6">Section 6</a>.
<span class="grey">Newton & Sanz Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
Clients SHOULD be prepared to use the following BEEP tuning profiles:
o <a href="http://iana.org/beep/SASL/DIGEST-MD5">http://iana.org/beep/SASL/DIGEST-MD5</a> -- for user authentication
without the need of session encryption.
o <a href="http://iana.org/beep/SASL/OTP">http://iana.org/beep/SASL/OTP</a> -- for user authentication without
the need of session encryption.
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher -- for encryption.
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_3DES_EDE_CBC_SHA
cipher with client-side certificates -- for encryption and user
authentication.
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_AES_128_CBC_SHA
cipher -- for encryption. See [<a href="#ref-13" title=""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"">13</a>].
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_AES_128_CBC_SHA
cipher with client-side certificates -- for encryption and user
authentication. See [<a href="#ref-13" title=""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"">13</a>].
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_AES_256_CBC_SHA
cipher -- for encryption. See [<a href="#ref-13" title=""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"">13</a>].
o <a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> using the TLS_RSA_WITH_AES_256_CBC_SHA
cipher with client-side certificates -- for encryption and user
authentication. See [<a href="#ref-13" title=""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"">13</a>].
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:
<a href="http://iana.org/beep/SASL/ANONYMOUS">http://iana.org/beep/SASL/ANONYMOUS</a>
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 <a href="http://iana.org/beep/SASL/PLAIN">http://iana.org/beep/SASL/PLAIN</a> tuning profile.
As specified by SASL/PLAIN, clients MUST NOT use the
<a href="http://iana.org/beep/SASL/PLAIN">http://iana.org/beep/SASL/PLAIN</a> tuning profile without first
encrypting the TCP session (e.g. such as with the
<a href="http://iana.org/beep/TLS">http://iana.org/beep/TLS</a> tuning profile).
<span class="grey">Newton & Sanz Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. References</span>
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. Normative References</span>
[<a id="ref-1">1</a>] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998, <<a href="http://www.w3.org/TR/1998/REC-xml-19980210">http://www.w3.org/TR/1998/REC-</a>
<a href="http://www.w3.org/TR/1998/REC-xml-19980210">xml-19980210</a>>.
[<a id="ref-2">2</a>] Rose, M., "The Blocks Extensible Exchange Protocol Core", <a href="./rfc3080">RFC</a>
<a href="./rfc3080">3080</a>, March 2001.
[<a id="ref-3">3</a>] Rose, M., "Mapping the BEEP Core onto TCP", <a href="./rfc3081">RFC 3081</a>, March
2001.
[<a id="ref-4">4</a>] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", <a href="./rfc2246">RFC</a>
<a href="./rfc2246">2246</a>, January 1999.
[<a id="ref-5">5</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-6">6</a>] Newton, A. and M. Sanz, "IRIS: The Internet Registry
Information Service (IRIS) Core Protocol", <a href="./rfc3981">RFC 3981</a>, January
2005.
[<a id="ref-7">7</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", <a href="./rfc2396">RFC 2396</a>, August
1998.
[<a id="ref-8">8</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", <a href="./rfc2234">RFC 2234</a>, November 1997.
[<a id="ref-9">9</a>] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[<a id="ref-10">10</a>] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", <a href="./rfc3280">RFC 3280</a>, April 2002.
[<a id="ref-11">11</a>] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types",
<a href="./rfc3023">RFC 3023</a>, January 2001.
[<a id="ref-12">12</a>] Alvestrand, H., "IETF Policy on Character Sets and Languages",
<a href="https://www.rfc-editor.org/bcp/bcp18">BCP 18</a>, <a href="./rfc2277">RFC 2277</a>, January 1998.
[<a id="ref-13">13</a>] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", <a href="./rfc3268">RFC 3268</a>, June 2002.
<span class="grey">Newton & Sanz Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>. Informative References</span>
[<a id="ref-14">14</a>] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
<a href="./rfc2817">RFC 2817</a>, May 2000.
[<a id="ref-15">15</a>] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol
-- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.
[<a id="ref-16">16</a>] Moore, K., "On the use of HTTP as a Substrate", <a href="https://www.rfc-editor.org/bcp/bcp56">BCP 56</a>, <a href="./rfc3205">RFC</a>
<a href="./rfc3205">3205</a>, February 2002.
[<a id="ref-17">17</a>] Hollenbeck, S., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22EPP+TCP+Transport%22'>"EPP TCP Transport"</a>, Work in Progress, January
2002.
[<a id="ref-18">18</a>] Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000.
[<a id="ref-19">19</a>] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", <a href="./rfc3707">RFC 3707</a>, February 2004.
[<a id="ref-20">20</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
January 2004.
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Authors' Addresses</span>
Andrew L. Newton
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: [email protected]; [email protected]
URI: <a href="http://www.verisignlabs.com/">http://www.verisignlabs.com/</a>
Marcos Sanz
DENIC eG
Wiesenhuettenplatz 26
D-60329 Frankfurt
Germany
EMail: [email protected]
URI: <a href="http://www.denic.de/">http://www.denic.de/</a>
<span class="grey">Newton & Sanz Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc3983">RFC 3983</a> IRIS-Beep January 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Newton & Sanz Standards Track [Page 12]
Annotations
Select text to annotate