Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (23)
BEEP was chosen as the transport substrate for IRIS because it is an existing, well-understood protocol with the necessary features (framing, authentication) that gives implementers toolkits and operational experience. HTTP was rejected to avoid confusion with WWW applications and because proper TLS use is inconsistently implemented; raw TCP was rejected because it lacks the client negotiation needed for referral traversal across multiple servers.
Each registry type is defined by a separate BEEP profile, so each MAY define its own message pattern; however, all must remain within the allowable scope of BEEP (RFC 3080) and must also support the default one-to-one pattern for <lookupEntity> queries.
The registry type SHOULD define a server authentication method because server authentication via TLS depends on the authority component of the URI; without an explicit definition, the basic server authentication method of Section 6.2 applies by default.
A server MUST honor queries for all advertised registry types on any channel opened with an IRIS profile URI.
During TLS negotiation the server's certificate MUST be an X.509 certificate and MUST contain the authority name in either the subjectDN or the subjectAltName extension of type dNSName.
Each registry type MUST be capable of supporting the default one-to-one request/response message pattern for use with the <lookupEntity> query in IRIS, even if it also defines registry-specific patterns.
IRIS XML instances transmitted over BEEP MUST be encoded as Unicode using the media-type 'application/xml' per RFC 3023. UTF-8 is RECOMMENDED; UTF-16 is OPTIONAL; other encodings MUST NOT be used.
Registry-dependent message patterns MUST be within the allowable scope of BEEP. If a registry type does not explicitly define a pattern, the default pattern defined in Section 5.2 is used.
Specifications of registry types MUST explicitly define: a message pattern (or declare use of the default) and a server authentication method (or declare use of the basic method or no authentication).
The IRIS-over-BEEP mapping MUST use TCP as specified by RFC 3081 (mapping BEEP core onto TCP).
The IRIS schema in the BEEP profile identifier MUST be abbreviated according to the rules of IRIS, and the registry type URN MUST also be abbreviated according to IRIS rules.
The server certificate MUST be cryptographically verified according to TLS procedures. The client then checks for a case-insensitive subject match: first dNSName in subjectAltName, then dc-component subjectDN, then cn-component subjectDN (wildcard '*' MAY be used as the leftmost label in cn).
The URI scheme name specific to BEEP over IRIS MUST be 'iris.beep', and the application protocol label MUST also be 'iris.beep'.
Under the basic server authentication method, the client MUST present the name of the authority to the server using the BEEP serverName mechanism at session instantiation (e.g., serverName="com" for authority 'com').
The BEEP profile identifier for IRIS is a URI composed of the IRIS schema URN followed by a slash and the IRIS registry type URN, with both URNs abbreviated per IRIS rules. The profile-uri prefix is 'http://iana.org/beep/', yielding identifiers such as 'http://iana.org/beep/iris1/dreg1'.
The default BEEP message pattern for IRIS is a one-to-one request/response exchange: the client sends an IRIS XML instance in a BEEP 'MSG' message, the server responds with an IRIS XML instance in an 'RPY' message, and faults are conveyed in 'ERR' messages.
This document registers a well-known TCP port for 'IRIS over BEEP' (short name: iris.beep) with IANA, covering message formats defined in Sections 3, 4, and 5.
This document registers the BEEP profile 'http://iana.org/beep/iris1' with the IANA BEEP profile registry. The profile uses IRIS XML instances as message syntax for one-to-one request/response exchanges.
This document registers the 'iris.beep' URI scheme, intended to identify IRIS entities made available using the BEEP profile for IRIS.
This document registers the S-NAPTR application protocol label 'iris.beep' with IANA, intended to identify an IRIS server using BEEP.
Anonymous client access SHOULD be considered either by using no authentication tuning profile or by using the SASL ANONYMOUS profile (http://iana.org/beep/SASL/ANONYMOUS).
Because IRIS contains a referral mechanism that may traverse multiple servers, clients SHOULD NOT use the SASL/PLAIN tuning profile to avoid handing user credentials to untrusted servers. Per SASL/PLAIN rules, clients MUST NOT use SASL/PLAIN without first encrypting the TCP session (e.g., via TLS).
Clients SHOULD be prepared to support a specific set of BEEP tuning profiles for authentication and encryption, including SASL/DIGEST-MD5, SASL/OTP, and TLS with 3DES or AES-128/256 cipher suites, optionally with client-side certificates for mutual authentication.