RFC 4992

XML Pipelining with Chunks for the Internet Registry Information Service

📅 published August 2007, from ietf

RFC 4992 🎀 XML Pipelining with Chunks for the Internet Registry Information Service

Okay bestie, let's do the vibe check first 💅 This is RFC 4992, XML Pipelining with Chunks for the Internet Registry Information Service. It was written by A. Newton at VeriSign, Inc. and published in August 2007. It's a Standards Track doc, so it's a real Internet protocol spec and not just a suggestion 👑 It updates RFC 3981 and its header doesn't list anything it obsoletes 🦋 It's from the Network Working Group, too, so it's very official and very serious 🧚

Status of This Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 💖 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The IETF Trust (2007).

Abstract 🦋

This doc describes a simple TCP transfer protocol for the Internet Registry Information Service (IRIS). Data moves between clients and servers in chunks so that pipelining can happen ✨

Table of Contents 📖

   1. Introduction ....................................................3
   2. Document Terminology ............................................3
   3. Request Block (RQB) .............................................4
   4. Response Blocks .................................................4
      4.1. Response Block (RSB) .......................................5
      4.2. Connection Response Block (CRB) ............................5
   5. Block Header ....................................................6
   6. Chunks ..........................................................7
      6.1. No Data Types ..............................................9
      6.2. Version Information Types ..................................9
      6.3. Size Information Types .....................................9
      6.4. Other Information Types ...................................10
      6.5. SASL Types ................................................11
      6.6. Authentication Success Information Types ..................12
      6.7. Authentication Failure Information Types ..................12
      6.8. Application Data Types ....................................12
   7. Idle Sessions ..................................................13
   8. Closing Sessions Due to an Error ...............................13
   9. Use over TLS ...................................................13
   10. Update to RFC 3981 ............................................13
   11. IRIS Transport Mapping Definitions ............................14
      11.1. URI Scheme ...............................................14
      11.2. Application Protocol Label ...............................14
   12. Internationalization Considerations ...........................14
   13. IANA Considerations ...........................................14
      13.1. XPC URI Scheme Registration ..............................14
      13.2. XPCS URI Scheme Registration .............................15
      13.3. S-NAPTR XPC Registration .................................15
      13.4. S-NAPTR XPCS Registration ................................15
      13.5. Well-Known TCP Port Registration for XPC .................16
      13.6. Well-Known TCP Port Registration for XPCS ................16
   14. Security Considerations .......................................17
      14.1. Security Mechanisms ......................................17
      14.2. SASL Compliance ..........................................18
   15. References ....................................................19
      15.1. Normative References .....................................19
      15.2. Informative References ...................................19
   Appendix A. Examples ..............................................20
   Appendix B. Contributors ..........................................28

1. Introduction ✨

IRIS can use S-NAPTR [5] to define multiple application transports (or transfer protocols) for different kinds of registry services. The server operator gets to decide which ones 💅 The TCP transfer protocol in this document is completely modular, so any registry type can use it 🫶

This transfer protocol defines simple framing for sending XML in chunks. That way, XML fragments can be acted upon (or pipelined) before the whole XML instance has arrived 🔥 This doc calls it XML pipelining with chunks (XPC), and when it's used with IRIS, it's called IRIS-XPC 🌈

XPC is for simple request and response interactions between clients and servers. Clients send a series of requests to a server in data blocks. The server answers each data block individually with a matching data block, all over the same connection 🦋 Request and response data blocks are sent with the TCP SEND function and received with the TCP RECEIVE function 💜

The lifecycle of an XPC session has these phases:

  1. A client establishes a TCP connection with a server.
  2. The server sends a connection response block (CRB).
  3. The client sends a request block (RQB). In this request, the client can set a "keep open" flag asking the server to keep the XPC session open after responding to this request 🌸
  4. The server responds with a response block (RSB). In this response, the server can tell the client whether or not the XPC session will be closed ✨
  5. If the XPC session is not going to be terminated, the lifecycle repeats from step 3.
  6. The TCP connection is closed.

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 RFC 2119 [8]. These are the official requirement words, so they're not just vibes 🔥

Octet fields with numeric values follow the conventions in RFC 1166 [12]. The leftmost bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted, the most significant octet is transmitted first 🧚 Bits that signify flags in an octet are numbered using the same RFC 1166 [12] conventions: bit 0 is the most significant bit and bit 7 is the least significant bit 💖 When a diagram describes a group of octets, transmission starts from the left 🍓

3. Request Block (RQB) 🎀

The request block (RQB) looks like this:

         +--------+-----------+-----------+-------------+
   field | header | authority | authority | chunks 1..n |
         |        |  length   |           |             |
         +--------+-----------+-----------+-------------+
   octets    1         1         0..255      variable

                               Request Block

Here's what each field means:

  • header - as described in Section 5.
  • authority length - the length of the authority field in this request block.
  • authority - a string of octets describing the authority this request is to be executed against. See [1] for the definition and description of an authority. The number of octets in this string MUST be no more and no less than the number specified by the authority length. Not one more, not one less, periodt 💅
  • chunks 1..n - the request data broken into chunks (Section 6).

4. Response Blocks 🌈

There are two types of blocks a server uses to respond to a client. The first is the response block (RSB), defined in Section 4.1, which the server uses to respond to request blocks (RQBs). The second is a specialized version called the connection response block (CRB), defined in Section 4.2. A server sends a CRB to a client when a connection is established, to start protocol negotiation 🦋 Conceptually, a CRB is a type of RQB. They share the same format, but a CRB can only convey specific information, and it's only sent at the very beginning of the session lifecycle 🧚

4.1. Response Block (RSB) 🌸

The response block (RSB) looks like this:

         +--------+-------------+
   field | header | chunks 1..n |
         |        |             |
         +--------+-------------+
   octets    1       variable

                              Response Block

Here's what each field means:

  • header - as described in Section 5.
  • chunks 1..n - the response data broken into chunks (Section 6).

Servers SHOULD NOT send an RSB to a client until they have received the entire RQB. Servers that do start sending an RSB before the whole RQB has arrived need to keep in mind that clients won't be expected to start processing the RSB until they've fully sent the RQB, and that the RSB may fill up the client's TCP buffers 😭

4.2. Connection Response Block (CRB) 💜

A connection response block (CRB) is a response block that a server sends to a client when the client starts a session. It has the same format as a response block (RSB) (Section 4.1). The only difference is that it's constrained in one of two ways:

  1. It contains only one chunk (see Section 6), and that chunk holds version information (see Section 6.2). The keep-open (KO) flag in the block header (see Section 5) has a value of 1, which means the connection is not closing. Servers MUST use this type of CRB to indicate service availability 🫶
  2. It contains only one chunk (see Section 6), and that chunk holds a system error (see 'system-error' under Section 6.4). The keep-open (KO) flag in the block header (see Section 5) has a value of 0, which means the server will close the connection immediately after sending the CRB. Servers MUST use this type of CRB when they can accept connections but cannot process requests 💀

5. Block Header ✨

okay so every data block starts with a one-octet header, bestie 🎀 It's called the block header, and it has the same format for request AND response blocks, even tho some of the bits only mean something in one type 💅 The bits follow the RFC 1166 [12] convention, where bit 0 is the most significant bit and bit 7 is the least significant bit. Here's the breakdown 🦋

  • bits 0 and 1 - version (V field) - If 0 (both bits are zero), the protocol is the version defined in this document. Otherwise, the rest of the bits in the header and the block may be interpreted as another version 🌈 If a server gets a request for a version it doesn't support, it SHOULD follow the behavior described in Section 8. no cap, that's the move 💜
  • bit 2 - keep open (KO flag) - This one is about whether the connection stays open 🫶 It's used to request that a connection stay open (by a client) and to show that a connection will stay open (by a server), and what it means depends on the type of block.
    • In a request block (RQB): a value of 1 means the client is asking the server not to close the TCP session, and a value of 0 means the client expects their server to close the TCP session right after sending the matching response 🍓
    • In a response block (RSB) or a connection response block (CRB): a value of 1 means the server expects the client to keep the TCP session open so the server can receive another request, and a value of 0 means the server expects the client to close the TCP session right after this block 😭
  • bits 3, 4, 5, 6, and 7 - reserved - These MUST be 0. If a server receives a request where any of these bits is set to 1 and the server doesn't understand what the value is for, the server SHOULD follow the behavior described in Section 8. the way the reserved bits are literally the spec's dustbin 🙈
       +---------+-----------+----------+
field  | Version | Keep Open | reserved |
       |   (V)   |   (KO)    |          |
       +---------+-----------+----------+
bits   |  0 and 1|     2     | 3 - 7    |

                    Block Header

6. Chunks 🧚

okay this section is about how the request and response XML gets cut up into bite-sized pieces 🍰 Request and response blocks MUST always have a minimum of 1 chunk, and each chunk has a one-octet descriptor. The first bit of that descriptor tells you if the chunk is the last one in the block 🔥

The chunk descriptor bits are also ordered by the RFC 1166 [12] convention, where bit 0 is the most significant bit and bit 7 is the least significant bit. Here's what each one means 💖

  • bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk in the block 👑
  • bit 1 - data complete (DC flag) - If 1, the data in this chunk is the end of the data for that chunk type. If this bit is never set to 1 in any chunk descriptor for chunks of the same type in a block, clients and servers MUST NOT assume the data will continue in another block. If the block switches from one chunk type to another without signaling that the data is complete, clients and servers MUST assume that the remaining data will not be sent in a remaining chunk. this one is giving "don't assume, just check" energy 🙅‍♀️
  • bits 2, 3, and 4 - reserved - These MUST be 0. 🌸
  • bits 5, 6, and 7 - chunk type (CT field) - This decides what kind of data is in the chunk. Here are the binary values for each chunk type 🦋
    • 000 - no data or 'nd' type (see Section 6.1)
    • 001 - version information or 'vi' type (see Section 6.2)
    • 010 - size information or 'si' type (see Section 6.3)
    • 011 - other information or 'oi' type (see Section 6.4)
    • 100 - SASL (Simple Authentication and Security Layer) data or 'sd' type (see Section 6.5)
    • 101 - authentication success information or 'as' type (see Section 6.6)
    • 110 - authentication failure information or 'af' type (see Section 6.7)
    • 111 - application data or 'ad' type (see Section 6.8)
       +------------+---------------+----------+------------+
field  | Last Chunk | Data Complete | reserved | Chunk Type |
       |    (LC)    |     (DC)      |          |    (CT)    |
       +------------+---------------+----------+------------+
bits   |     0      |       1       |  2 - 4   |   5 - 7    |

                    Chunk Descriptor

A block MAY have multiple types of chunks, but all chunks of the same type MUST be contiguous in a block and MUST be ordered in the block in the order their data is supposed to be interpreted. Contiguous chunks must be ordered by type within a block like this 🌈

  1. authentication-related chunks - either SASL data chunks (type 100), authentication success information chunks (type 101), or authentication failure information chunks (type 110), but not more than one type. While setting up security mechanisms with these chunks, clients MUST NOT send subsequent requests until they've received either an authentication success or failure chunk. 🔐
  2. data chunks - either no data chunks (type 000) or application data chunks (type 111), but not both. 💅
  3. information chunks - either version information (type 001) or other information (type 011), but not both. ✨

A block MUST have at least one type of the above chunks. ⭐

The format for a chunk is as follows 🍓

       +-----------+------------+--------+
field  | chunk     | chunk data | chunk  |
       | descriptor| length     | data   |
       +-----------+------------+--------+
octets |     1     |     2      |variable|

                    chunk

Here's what those fields mean:

  • chunk descriptor - as described above.
  • chunk data length - the length of the data of the chunk.
  • chunk data - the data of the chunk.

6.1. No Data Types 🫧

Servers and clients MUST ignore data in chunk types labeled no data. There's no requirement for these chunks to be zero length, so don't freak out if they aren't 🙈 A client MAY send "no data" to a server, and the server MUST respond with either a chunk of the same type or other information (Section 6.4). the server always has to reply, periodt 💜

6.2. Version Information Types 🎀

Chunks of this type contain XML that conforms to the schema specified in [9], and they MUST have the <versions> element as the root element. 💖

In the context of IRIS-XPC, the protocol identifiers for these elements are as follows:

  • <transferProtocol> - the value "iris.xpc1" to indicate the protocol specified in this document.
  • <application> - the XML namespace identifier for IRIS [1].
  • <dataModel> - the XML namespace identifier for IRIS registries.

In the context of IRIS-XPC, the authentication mechanism identifiers are the SASL mechanism names found in the IANA SASL mechanism registry defined by RFC 4422 [10]. 🦋

This document defines no extension identifiers. nothing new to see here, bestie 🌸

Clients MAY send a block with this type of chunk to a server. These chunks SHOULD be zero length, and servers MUST ignore any data in them. When a server receives a chunk of this type, it MUST respond with a chunk of this type. This back-and-forth lets a client ask a server what version information it has 🧚✨

The octet sizes for the 'requestSizeOctets' and 'responseSizeOctets' attributes of the <tranferProtocol> element are defined in Section 6.3. (yes the spelling says tranfer, that's how the spec wrote it, so we're keeping it exactly 🙈)

6.3. Size Information Types 📏

Chunks of this type contain XML that conforms to the schema specified in RFC 4991 [9], and they MUST have the <size> element as the root element. 🍰

Octet counts provided by this information are defined as the sum of the count of all chunk data of a particular chunk type. For instance, if an XML instance is broken up into chunks of 20, 30, and 40 octets, the octet count would be 90 (20 + 30 + 40). math bestie 🧮💅

Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received. don't be sending size chunks, that's not your job 💀

6.4. Other Information Types 🌈

Chunks of this type contain XML that conforms to the schema specified in RFC 4991 [9], and they MUST have the <other> element as the root element. 💜

The values for the 'type' attribute of <other> are as follows:

  • 'block-error' - indicates there was an error decoding a block. Servers SHOULD send a block error in the following cases:
    1. When a request block is received containing a chunk of this type.
    2. When a request block is received containing authentication success (see Section 6.6) or authentication failure (see Section 6.7) information.
    3. When a request block is received containing size information (see Section 6.3).
    4. When reserved bits in the request block are 1.
    5. When a block has not been received in its entirety and the TCP session has been idle for a specific period of time (i.e., a data block has been received but no terminating chunk for the data block has been received). Two minutes is RECOMMENDED for this timeout value. Note, there is a difference between an idle condition due to the incomplete reception of a data block and an idle condition between request/response transactions associated with keeping the session open. For the latter, see Section 7. two different kinds of "idle" and they are NOT the same thing, so read carefully 👀
  • 'data-error' - indicates there was an error parsing data in chunks containing application or SASL data (e.g., XML is not valid in application data). 🙃
  • 'system-error' - indicates that the receiver cannot process the request due to a condition not related to this protocol. Servers SHOULD send a system-error when they are capable of responding to requests but not capable of processing requests. 🔥
  • 'authority-error' - indicates that the intended authority specified in the corresponding request is not served by the receiver. Servers SHOULD send an authority error when they receive a request directed to an authority other than those they serve. not the right address, bestie 🦋
  • 'idle-timeout' - indicates that an XPC session has been idle for too long. Usage of this value is defined in Section 7. Note, there is a difference between an idle condition due to the incomplete reception of a data block and an idle condition between request/response transactions associated with keeping the session open. For the former, see 'block-error' above. ⏳

Clients MUST NOT send chunks of this type, and servers MAY close down a session using the procedure in Section 8 if a chunk of this type is received. ✨

6.5. SASL Types 💖

okay so SASL chunks are how clients and servers swap SASL data back and forth 🔐 literally the whole point of this type 💅

the format for this chunk's data looks like this:

         +-----------+-----------+-----------+-----------+
   field | mechanism | mechanism | mechanism | mechanism |
         |   name    |   name    |   data    |   data    |
         |  length   |           |  length   |           |
         +-----------+-----------+-----------+-----------+
   octets     1        variable       2        variable

                            SASL Authentication

so here's what each field means 🧚

  • mechanism name length: the length of the SASL mechanism name.
  • mechanism name: the name of the SASL mechanism as registered in the IANA SASL mechanism registry defined by [10].
  • mechanism data length: the length of the SASL data.
  • mechanism data: the data used for SASL.

these fields MUST NOT span multiple chunks 🚫 so bestie, it should be noted that SASL data length going over the length of the chunk minus the length of SASL profile name minus one is an error. not a vibe.

depending on which SASL mechanism you're using, SASL data goes from clients to servers and from servers to clients, and it might take multiple request/response transactions to finish 🔄 but once the SASL exchange is complete and a server can tell what the authentication status is, the server MUST send either authentication success information (see Section 6.6) or authentication failure information (see Section 6.7). no skipping that step 🙅‍♀️

when a SASL mechanism supports it, the mechanism data length may be set to a decimal value of 65,535 to mean an absent initial response ✨ and a value of 0 means an empty initial response. so many options, I'm obsessed 😭

6.6. Authentication Success Information Types 🎉

chunks of this type contain XML that follows the schema in RFC 4991 [9] and they MUST have the <authenticationSuccess> element as the root element 👑

this type only goes from a server to a client 🫶 if a client sends it to a server, that results in a block error (see 'block-error' in Section 6.4). the way this chunk gets used is defined in Section 6.5. a server MAY close down a session because it received this type of chunk, using the procedure in Section 8 💀

SASL mechanisms can use the <data> child element to pass back arbitrary binary data as base 64 binary 🍓 if that element is missing, there's no data, but if it's there with no content, that means an empty data set. the difference is everything 🙈

6.7. Authentication Failure Information Types ❌

chunks of this type contain XML that follows the schema in RFC 4991 [9] and they MUST have the <authenticationFailure> element as the root element 😔

same energy as 6.6: this type only goes from a server to a client. if a client sends it to a server, that's a block error (see 'block-error' in Section 6.4). the usage is defined in Section 6.5, and a server MAY close down a session because of reception of this type of chunk, using the procedure in Section 8 🥀

6.8. Application Data Types 🌸

these chunks carry application data 📦 for IRIS, that means IRIS [1] XML instances. simple and cute 🎀

7. Idle Sessions 😴

if a server needs to close a connection because it's idle, it SHOULD do the following:

  1. Send an unsolicited response block containing an idle timeout error (see 'idle-timeout' in Section 6.4) with the keep-open (KO) flag in the block header (Section 5) set to a value of 0.
  2. Close the TCP connection.

8. Closing Sessions Due to an Error 🚨

if a server is closing a session because of an error, it SHOULD do the following:

  1. Send a response block containing either a block-error or data-error (see Section 6.4) or version information (see Section 6.2) with the keep-open (KO) flag in the block header (Section 5) set to a value of 0.
  2. Close the TCP connection.

9. Use over TLS 🔒

XPC may be tunneled over TLS [4] by setting up a TLS session right after a TCP session opens and before any blocks get sent. this kind of session is called XPCS ✨

when you're using TLS, a convention has to be established so a client can check that a server is legit 🕵️‍♀️ XPCS uses the same convention described by IRIS-BEEP [2], so you don't have to learn a new one.

TLS gives you authentication and confidentiality, which is giving security queen energy 👑

implementers should note that XPC and XPCS have separate URI scheme names and S-NAPTR application protocol labels, but both are identified with the same <transferProtocol> value in version information chunks (see Section 6.2). same value, different vibes, so don't mix them up 🧚

10. Update to RFC 3981 📝

Section 6.2 of RFC 3981 [1] (IRIS-CORE) says IRIS-BEEP [2] is the default transport for IRIS. this document revises RFC 3981 and specifies IRIS-XPC as the default transport for IRIS instead 🦋 the TCP well-known port registration is specified in Section 13.5.

11. IRIS Transport Mapping Definitions 🗺️

this section lists the definitions IRIS [1] needs for transport mappings.

11.1. URI Scheme

see Section 13.1 and Section 13.2.

11.2. Application Protocol Label

see Section 13.3 and Section 13.4.

12. Internationalization Considerations 🌍

XML processors are obliged to recognize both UTF-8 and UTF-16 [3] encodings. use of the XML defined by [9] MUST NOT use any character encodings other than UTF-8 or UTF-16 💅

13. IANA Considerations 📋

13.1. XPC URI Scheme Registration

URL scheme name: iris.xpc

Status: permanent

URL scheme syntax: defined in [1].

Character encoding considerations: as defined in RFC 3986 [6].

Intended usage: identifies IRIS XML using chunks over TCP

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

Interoperability considerations: n/a

Security Considerations: defined in Section 14.

Relevant Publications: IRIS [1].

Contact Information: Andrew Newton <andy@hxr.us>

Author/Change controller: the IESG

13.2. XPCS URI Scheme Registration

URL scheme name: iris.xpcs

Status: permanent

URL scheme syntax: defined in [1].

Character encoding considerations: as defined in RFC 3986 [6].

Intended usage: identifies IRIS XML using chunks over TLS

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

Interoperability considerations: n/a

Security Considerations: defined in Section 14.

Relevant Publications: IRIS [1].

Contact Information: Andrew Newton <andy@hxr.us>

Author/Change controller: the IESG

13.3. S-NAPTR XPC Registration

Application Protocol Label (see [5]): iris.xpc

Intended usage: identifies an IRIS server using XPC

Interoperability considerations: n/a

Security Considerations: defined in Section 14.

Relevant Publications: IRIS [1].

Contact Information: Andrew Newton <andy@hxr.us>

Author/Change controller: the IESG

13.4. S-NAPTR XPCS Registration

Application Protocol Label (see [5]): iris.xpcs

Intended usage: identifies an IRIS server using secure XPCS

Interoperability considerations: n/a
Security Considerations: defined in Section 14.

Relevant Publications: IRIS [1].

Contact Information: Andrew Newton <andy@hxr.us>

Author/Change controller: the IESG

13.5. Well-Known TCP Port Registration for XPC

Protocol Number: TCP

TCP Port Number: 713

Message Formats, Types, Opcodes, and Sequences: defined in Section
4.2, Section 3, and Section 4.1.

Functions: defined in IRIS [1].

Use of Broadcast/Multicast: none

Proposed Name: IRIS over XPC

Short name: iris.xpc

Contact Information: Andrew Newton <andy@hxr.us>

13.6. Well-Known TCP Port Registration for XPCS

Protocol Number: TCP

TCP Port Number: 714

Message Formats, Types, Opcodes, and Sequences: defined in Sections
9, 4.2, 3, and 4.1.

Functions: defined in IRIS [1].

Use of Broadcast/Multicast: none

Proposed Name: IRIS over XPCS

Short name: iris.xpcs

Contact Information: Andrew Newton <andy@hxr.us>

14. Security Considerations 🛡️

implementers should be fully aware of the security considerations given by IRIS [1] and TLS [4]. this is NOT optional bestie 😭 with respect to server authentication when using TLS, see Section 6 of IRIS-BEEP [2].

14.1. Security Mechanisms 🔐

clients SHOULD be prepared to use the following security mechanisms, in the following manner:

  • SASL/DIGEST-MD5 - for user authentication without the need of session encryption.
  • SASL/OTP - for user authentication without the need of session encryption.
  • TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for encryption.
  • TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates - for encryption and user authentication.
  • TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for encryption. See [7].
  • TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [7].
  • TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for encryption. See [7].
  • TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [7].

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

  1. When no authentication has been used.
  2. Using the SASL anonymous profile: SASL/ANONYMOUS

as specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN mechanism without first encrypting the TCP session (e.g., such as with TLS). 🙅‍♀️ clients MUST also implement SASL/PLAIN and TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher. no excuses 💖

14.2. SASL Compliance ✅

the following list details how IRIS-XPC complies with SASL, as specified by RFC 4422 [10], Section 4 📜

  1. The SASL service name used by IRIS-XPC is "iris-xpc".
  2. Section 6.2 describes the negotiation facility used to determine the available security mechanisms. this facility may be used both before SASL exchanges start and after security mechanisms are installed.
  3. Here's how the parts of SASL are covered:
    • a) Section 6.5 describes the mechanism to initiate authentication exchanges.
    • b) Section 6.5 describes the mechanism to transfer server challenges and client responses.
    • c) Section 6.6 and Section 6.7 describe the mechanisms to indicate the outcome of an authentication exchange. Section 6.6 describes how additional data may be carried with this message.
  4. Non-empty authorization identity strings used within IRIS-XPC MUST be normalized according to RFC 4013 [11]. the semantics of non-empty authorization identity strings are server dependent, and clients MUST use the values for these strings as given by configuration or the user 🧐
  5. Clients or servers wishing to abort an ongoing authentication exchange MUST close the connection 🔌
  6. After new security layers are negotiated, they take effect on the first octet following the authentication success (as) (Section 6.6) chunk sent by the server, and on the first octet sent after receipt of the authentication success (as) chunk sent by the client. timing is everything ⏰
  7. IRIS-XPC can be used with both TLS and SASL. when they're used together, TLS MUST always be applied before any SASL mechanism 🥇
  8. IRIS-XPC does not support multiple SASL authentications. however, if TLS is being used in combination with SASL, TLS authentication MUST occur before any SASL authentication 💜

15. References 📚

15.1. Normative References

okay so these are the docs IRIS basically can't function without, bestie 📚 ✨

[1] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.

[2] Newton, A. and M. Sanz, "Using the Internet Registry Information Service over the Blocks Extensible Exchange Protocol", RFC 3983, January 2005.

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

[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[5] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.

[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.

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

[9] Newton, A., "A Common Schema for Internet Registry Information Service Transfer Protocols", RFC 4991, August 2007.

[10] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[11] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.

15.2. Informative References

[12] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990.

Appendix A. Examples ✨

This section is full of example IRIS-XPC sessions 🦋 Lines starting with "C:" are what the client sends to the server, and lines starting with "S:" are what the server sends back to the client. After the "C:" or "S:", each line has either octet values in hexadecimal notation with comments, or XML fragments. A line never has both octets-with-comments and XML fragments, and the comments always go in parentheses 🎀

also, flag values of "yes" and "no" are just binary 1 and 0, so don't get confused 🙈

okay so the first example shows an IRIS client sending two requests in one XPC session 💅 In the first request, the client wants status info for "example.com", and that request plus its response each fit in one chunk. In the second request, the client wants status info for "milo.example.com", "felix.example.com", and "hobbes.example.com", and this one (request and response) gets split across three chunks. It's giving organized 😭

S:           (connection response block)
S: 0x20      (block header: V=0,KO=yes)
S:           (chunk 1)
S: 0xC1      (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S:           (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S:   <transferProtocol protocolId="iris.xpc1"
S:     authenticationIds="PLAIN EXTERNAL">
S:     <application protocolId="urn:ietf:params:xml:ns:iris1"
S:       extensionIds="http://example.com/SIMPLEBAG">
S:       <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S:       <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S:     </application>
S:   </transferProtocol>
S: </versions>

C:           (request block)
C: 0x20      (block header: V=0,KO=yes)
C: 0x0B      (authority length=11)
C:           (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C:           (chunk 1)
C: 0xC7      (LC=yes,DC=yes,CT=ad)
C: 0x01 0x53 (chunk length=339)
C:           (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C:   <searchSet>
C:     <lookupEntity
C:       registryType="urn:ietf:params:xml:ns:dchk1"
C:       entityClass="domain-name"
C:       entityName="example.com" />
C:   </searchSet>
C: </request>

S:           (response block)
S: 0x20      (block header: V=0,KO=yes)
S:           (chunk 1)
S: 0xC7      (LC=yes,DC=yes,CT=ad)
S: 0x01 0xE0 (chunk length=480)
S:           (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S:   <iris:resultSet>
S:     <iris:answer>
S:       <domain authority="example.com" registryType="dchk1"
S:         entityClass="domain-name" entityName="example.com-1"
S:         temporaryReference="true"
S:         xmlns="urn:ietf:params:xml:ns:dchk1">
S:         <domainName>example.com</domainName>
S:         <status>
S:           <assignedAndActive/>
S:         </status>
S:       </domain>
S:     </iris:answer>
S:   </iris:resultSet>
S: </iris:response>

C:           (request block)
C: 0x00      (block header: V=0,KO=no)
C: 0x0B      (authority length=11)
C:           (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C:           (chunk 1)
C: 0x07      (LC=no,DC=no,CT=ad)
C: 0x01 0x4E (chunk length=339)
C:           (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C:  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:  xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C:   <searchSet>
C:    <lookupEntity
C:      registryType="urn:ietf:params:xml:ns:dchk1"
C:      entityClass="domain-name"
C:      entityName="milo.example.com" />
C:  </searchSet>
C:           (chunk 2)
C: 0x07      (LC=no,DC=no,CT=ad)
C: 0x00 0xA9 (chunk length=169)
C:           (IRIS XML request)
C:  <searchSet>
C:    <lookupEntity
C:      registryType="urn:ietf:params:xml:ns:dchk1"
C:      entityClass="domain-name"
C:      entityName="felix.example.com" />
C:  </searchSet>
C:           (chunk 3)
C: 0xC7      (LC=yes,DC=yes,CT=ad)
C: 0x00 0xB5 (chunk length=181)
C:           (IRIS XML request)
C:  <searchSet>
C:    <lookupEntity
C:      registryType="urn:ietf:params:xml:ns:dchk1"
C:      entityClass="domain-name"
C:      entityName="hobbes.example.com" />
C:  </searchSet>
C:</request>

S:           (response block)
S: 0x00      (block header: V=0,KO=no)
S:           (chunk 1)
S: 0x07      (LC=no,DC=no,CT=ad)
S: 0x01 0xDA (chunk length=474)
S:           (IRIS XML response)
S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
S:   <iris:resultSet>
S:     <iris:answer>
S:       <domain authority="example.com" registryType="dchk1"
S:         entityClass="domain-name" entityName="milo.example.com-1"
S:         temporaryReference="true"
S:         xmlns="urn:ietf:params:xml:ns:dchk1">
S:         <domainName>milo.example.com</domainName>
S:         <status>
S:           <assignedAndActive/>
S:         </status>
S:       </domain>
S:     </iris:answer>
S:   </iris:resultSet>
S:           (chunk 2)
S: 0x07      (LC=no,DC=no,CT=ad)
S: 0x01 0xA2 (chunk length=418)
S:           (IRIS XML response)
S:  <iris:resultSet>
S:    <iris:answer>
S:      <domain authority="example.com" registryType="dchk1"
S:        entityClass="domain-name" entityName="felix.example.com-1"
S:        temporaryReference="true"
S:        xmlns="urn:ietf:params:xml:ns:dchk1">
S:        <domainName>felix.example.com</domainName>
S:        <status>
S:          <assignedAndActive/>
S:        </status>
S:      </domain>
S:    </iris:answer>
S:  </iris:resultSet>
S:           (chunk 3)
S: 0xC7      (LC=yes,DC=yes,CT=ad)
S: 0x01 0xB5 (chunk length=437)
S:           (IRIS XML response)
S:  <iris:resultSet>
S:     <iris:answer>
S:       <domain authority="example.com" registryType="dchk1"
S:         entityClass="domain-name"
S:  entityName="hobbes.example.com-1"
S:         temporaryReference="true"
S:         xmlns="urn:ietf:params:xml:ns:dchk1">
S:         <domainName>hobbes.example.com</domainName>
S:         <status>
S:           <assignedAndActive/>
S:         </status>
S:       </domain>
S:     </iris:answer>
S:   </iris:resultSet>
S: </iris:response>

Example 1

In this one 🍓 an IRIS client asks for domain status info for "milo.example.com", "felix.example.com", and "hobbes.example.com", all in one single request. The request goes out in one chunk, but the answer comes back split across three chunks.

S:           (connection response block)
S: 0x20      (block header: V=0,KO=yes)
S:           (chunk 1)
S: 0xC1      (LC=yes,DC=yes,CT=vi)
S: 0x01 0xBF (chunk length=447)
S:           (Version Information)
S: <?xml version="1.0"?>
S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
S:   <transferProtocol protocolId="iris.xpc1"
S:     authenticationIds="PLAIN EXTERNAL">
S:     <application protocolId="urn:ietf:params:xml:ns:iris1"
S:       extensionIds="http://example.com/SIMPLEBAG">
S:       <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
S:       <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
S:     </application>
S:   </transferProtocol>
S: </versions>

C:           (request block)
C: 0x00      (block header: V=0,KO=no)
C: 0x0B      (authority length=11)
C:           (authority="example.com")
C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
C:           (chunk 1)
C: 0xC7      (LC=yes,DC=yes,CT=ad)
C: 0x02 0xAB (chunk length=683)
C:           (IRIS XML request)
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
C:    <searchSet>
C:     <lookupEntity
C:       registryType="urn:ietf:params:xml:ns:dchk1"
C:       entityClass="domain-name"
C:       entityName="milo.example.com" />
C:   </searchSet>
C:   <searchSet>
C:     <lookupEntity
C:       registryType="urn:ietf:params:xml:ns:dchk1"
C:       entityClass="domain-name"
C:       entityName="felix.example.com" />
C:   </searchSet>
C:   <searchSet>
C:     <lookupEntity
C:       registryType="urn:ietf:params:xml:ns:dchk1"
C:       entityClass="domain-name"
C:       entityName="hobbes.example.com" />
C:   </searchSet>
C: </request>

ok that's the whole vibe of the examples, bestie 🌈💖

   S:           (response block)
   S: 0x00      (block header: V=0,KO=no)
   S:           (chunk 1)
   S: 0x07      (LC=no,DC=no,CT=ad)
   S: 0x01 0xDA (chunk length=474)
   S:           (IRIS XML response)
   S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
   S:   <iris:resultSet>
   S:     <iris:answer>
   S:       <domain authority="example.com" registryType="dchk1"
   S:         entityClass="domain-name" entityName="milo.example.com-1"
   S:         temporaryReference="true"
   S:         xmlns="urn:ietf:params:xml:ns:dchk1">
   S:         <domainName>milo.example.com</domainName>
   S:         <status>
   S:           <assignedAndActive/>
   S:         </status>
   S:       </domain>
   S:     </iris:answer>
   S:   </iris:resultSet>
   S:           (chunk 2)
   S: 0x07      (LC=no,DC=no,CT=ad)
   S: 0x01 0xA2 (chunk length=418)
   S:           (IRIS XML response)
   S:  <iris:resultSet>
   S:    <iris:answer>
   S:      <domain authority="example.com" registryType="dchk1"
   S:        entityClass="domain-name" entityName="felix.example.com-1"
   S:        temporaryReference="true"
   S:        xmlns="urn:ietf:params:xml:ns:dchk1">
   S:        <domainName>felix.example.com</domainName>
   S:        <status>
   S:          <assignedAndActive/>
   S:        </status>
   S:      </domain>
   S:    </iris:answer>
   S:  </iris:resultSet>
   S:           (chunk 3)
   S: 0xC7      (LC=yes,DC=yes,CT=ad)
   S: 0x01 0xB5 (chunk length=437)
   S:           (IRIS XML response)
   S:  <iris:resultSet>
   S:     <iris:answer>
   S:       <domain authority="example.com" registryType="dchk1"
   S:         entityClass="domain-name"
   S:  entityName="hobbes.example.com-1"
   S:         temporaryReference="true"
   S:         xmlns="urn:ietf:params:xml:ns:dchk1">
   S:         <domainName>hobbes.example.com</domainName>
   S:         <status>
   S:           <assignedAndActive/>
   S:         </status>
   S:       </domain>
   S:     </iris:answer>
   S:   </iris:resultSet>
   S: </iris:response>

Example 2 🌸

In this one, an IRIS client sends a request with SASL/PLAIN authentication data plus a domain status check for "example.com" 💅. The server replies with an authentication success message and the status of "example.com" ✨. Heads up: the client asks for the connection to stay open for more requests, but the server doesn't go along with that 🙈.

   S:           (connection response block)
   S: 0x20      (block header: V=0,KO=yes)
   S:           (chunk 1)
   S: 0xC1      (LC=yes,DC=yes,CT=vi)
   S: 0x01 0xBF (chunk length=447)
   S:           (Version Information)
   S: <?xml version="1.0"?>
   S: <versions xmlns="urn:ietf:params:xml:ns:iris-transport">
   S:   <transferProtocol protocolId="iris.xpc1"
   S:     authenticationIds="PLAIN EXTERNAL">
   S:     <application protocolId="urn:ietf:params:xml:ns:iris1"
   S:       extensionIds="http://example.com/SIMPLEBAG">
   S:       <dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
   S:       <dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
   S:     </application>
   S:   </transferProtocol>
   S: </versions>

   C:           (request block)
   C: 0x00      (block header: V=0,KO=no)
   C: 0x0B      (authority length=11)
   C:           (authority="example.com")
   C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D
   C:           (chunk 1)
   C: 0x44      (LC=no,DC=yes,CT=sd)
   C: 0x00 0x11 (chunk length=11)
   C:           (SASL data)
   C: 0x05      (mechanism length=5)
   C:           (mechanism name="PLAIN")
   C: 0x50 0x4C 0x41 0x49 0x43
   C: 0x00 0x0A (sasl PLAIN data length=10)
   C:           (sasl PLAIN data: authcid="bob")
   C:           (sasl PLAIN data: authzid=NULL)
   C:           (sasl PLAIN data: password="kEw1")
   C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31
   C:           (chunk 2)
   C: 0xC7      (LC=yes,DC=yes,CT=ad)
   C: 0x01 0x53 (chunk length=339)
   C:           (IRIS XML request)
   C: <request xmlns="urn:ietf:params:xml:ns:iris1"
   C:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
   C:   <searchSet>
   C:     <lookupEntity
   C:       registryType="urn:ietf:params:xml:ns:dchk1"
   C:       entityClass="domain-name"
   C:       entityName="example.com" />
   C:   </searchSet>
   C: </request>

   S:           (response block)
   S: 0x00      (block header: V=0,KO=no)
   S:           (chunk 1)
   S: 0x45      (LC=no,DC=yes,CT=as)
   S: 0x00 0xD0 (chunk length=208)
   S:           (authentication success response)
   S: <?xml version="1.0"?>
   S: <authenticationSuccess
   S:   xmlns="urn:ietf:params:xml:ns:iris-transport">
   S:   <description language="en">
   S:     user 'bob' authenticates via password
   S:   </description>
   S: </authenticationSuccess>
   S:           (chunk 2)
   S: 0xC7      (LC=yes,DC=yes,CT=ad)
   S: 0x01 0xE0 (chunk length=480)
   S:           (IRIS XML response)
   S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1">
   S:   <iris:resultSet>
   S:     <iris:answer>
   S:       <domain authority="example.com" registryType="dchk1"
   S:         entityClass="domain-name" entityName="example.com-1"
   S:         temporaryReference="true"
   S:         xmlns="urn:ietf:params:xml:ns:dchk1">
   S:         <domainName>example.com</domainName>
   S:         <status>
   S:           <assignedAndActive/>
   S:         </status>
   S:       </domain>
   S:     </iris:answer>
   S:   </iris:resultSet>
   S: </iris:response>

Example 3 🧚

Appendix B. Contributors 🎀

Big shoutout 🫶 to the folks in the IETF's CRISP Working Group, who made substantive contributions to this document. Special love to Robert Martin-Legene, Milena Caires, and David Blacka 💜.

Author's Address 🦋

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

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

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, 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, THE IETF TRUST 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. It also doesn't claim to have made any independent effort to identify any such rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79 🔥.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr.

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 required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 💖.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society ✨.

📦 where this page comes from