Network Working Group M.T. Rose Internet-Draft Invisible Worlds, Inc. Expires: September 7, 2000 March 9, 2000 The Blocks eXtensible eXchange Protocol draft-mrose-blocks-protocol-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with 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 September 7, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes the Blocks eXtensible eXchange Protocol (BXXP), a generic application protocol framework for connection-oriented, asynchronous request-response interactions. BXXP permits multiplexing of independent request/response streams over a single transport connection, supporting both textual and binary messages. To subscribe to the Blocks discussion list, send e-mail[13]; there is also a developers' site[14]. Rose Expires September 7, 2000 [Page 1] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Blocks eXtensible eXchange Protocol . . . . . . . . . 5 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 6 2.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 10 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 11 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 11 2.3.1.1 The Start Message . . . . . . . . . . . . . . . . . . . . 11 2.3.1.2 The Greeting Message . . . . . . . . . . . . . . . . . . . 13 2.3.1.3 The Error Message . . . . . . . . . . . . . . . . . . . . 14 2.4 Session Establishment and Release . . . . . . . . . . . . 15 2.5 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . 16 2.5.2 Sending REQ or RSP Messages . . . . . . . . . . . . . . . 17 2.5.3 Receiving REQ or RSP Messages . . . . . . . . . . . . . . 17 2.5.4 Processing SEQ Messages . . . . . . . . . . . . . . . . . 18 2.5.5 Use of Flow Control . . . . . . . . . . . . . . . . . . . 18 2.6 Sequencing and Parallelism . . . . . . . . . . . . . . . . 19 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 20 3. Transport Security . . . . . . . . . . . . . . . . . . . . 21 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 24 3.1.1 Profile Identification and Initialization . . . . . . . . 24 3.1.2 Request and Response Messages . . . . . . . . . . . . . . 25 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 26 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 26 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 26 4. User Authentication . . . . . . . . . . . . . . . . . . . 27 4.1 Profile Identification and Initialization . . . . . . . . 28 4.2 Request and Response Messages . . . . . . . . . . . . . . 30 4.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 31 4.3.1 The Identity Message . . . . . . . . . . . . . . . . . . . 31 4.3.2 The Challenge Message . . . . . . . . . . . . . . . . . . 31 4.3.3 The Response Message . . . . . . . . . . . . . . . . . . . 31 4.3.4 The Complete Message . . . . . . . . . . . . . . . . . . . 31 4.4 The SASL ANONYMOUS Profile . . . . . . . . . . . . . . . . 32 4.4.1 Profile Identification . . . . . . . . . . . . . . . . . . 32 4.4.2 Message Semantics . . . . . . . . . . . . . . . . . . . . 32 4.5 The SASL OTP Profile . . . . . . . . . . . . . . . . . . . 33 4.5.1 Profile Identification . . . . . . . . . . . . . . . . . . 33 4.5.2 Message Semantics . . . . . . . . . . . . . . . . . . . . 33 4.6 The SASL EXTERNAL Profile . . . . . . . . . . . . . . . . 35 4.6.1 Profile Identification . . . . . . . . . . . . . . . . . . 35 4.6.2 Message Semantics . . . . . . . . . . . . . . . . . . . . 35 Rose Expires September 7, 2000 [Page 2] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 5. Profile Registration Template . . . . . . . . . . . . . . 37 6. Initial Profile Registrations . . . . . . . . . . . . . . 38 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 38 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 39 6.3 TLS Transport Security Profile Registration . . . . . . . 41 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 42 6.5 SASL ANONYMOUS User Authentication Profile Registration . 43 6.6 SASL OTP User Authentication Profile Registration . . . . 43 6.7 SASL EXTERNAL User Authentication Profile Registration . . 43 6.8 SASL Family of User Authentication Profiles DTD . . . . . 44 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . 47 References . . . . . . . . . . . . . . . . . . . . . . . . 48 Author's Address . . . . . . . . . . . . . . . . . . . . . 49 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50 B. Changes from draft-mrose-blocks-protocol-00 . . . . . . . 51 Full Copyright Statement . . . . . . . . . . . . . . . . . 52 Rose Expires September 7, 2000 [Page 3] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 1. Introduction BXXP provides a generic application protocol framework for connection-oriented, asynchronous request-response interactions over TCP[1]. Consult [2] for a description of the BXXP's design principles. At the core of BXXP is a framing mechanism that allows for peer-to-peer exchanges of requests and responses. The framing mechanism permits multiplexing multiple, simultaneous, and independent exchanges over a single transport connection with flow control and segmentation. Requests and responses are either textual (structured using XML[3]) or arbitrary (structured using MIME[4]). Frames are exchanged in the context of a "channel". Each channel has an associated "profile" that defines the syntax and semantics of the messages exchanged. Implicit in the operation of BXXP is the notion of channel management. In addition to defining BXXP's channel management profile, this document defines two core profiles: o the TLS[5] transport security profile; and, o the SASL[6] family of user authentication profiles. Other profiles, such as those used for data exchange, are defined by an application protocol designer. A registration template is provided for this purpose. Rose Expires September 7, 2000 [Page 4] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2. The Blocks eXtensible eXchange Protocol BXXP is a stream-oriented protocol. Arbitrary octets are encapsulated within a frame and tagged as either a request or a response. All interactions occur in the context of a channel -- a binding to a well-defined aspect of the application, such as transport security, user authentication, or data exchange. During the creation of a channel, the requestor supplies one or more proposed profiles for that channel. If the responder creates the channel, it selects one of the profiles and returns it in a response; otherwise, it may indicate that none of the profiles are acceptable, and decline creation of the channel. There are no other management capabilities for channels other than creation, as channel usage falls into one of two categories: initial tuning: these are used by profiles that perform initialization once the session is established (e.g., negotiating the use of transport security); although several request-response exchanges may be required to perform the initialization, these channels become inactive early in the session and remain so for the duration. continuous: these are used by profiles that support data exchange; typically, these channels are created after the initial tuning channels have gone quiet. 2.1 Roles Although BXXP is a peer-to-peer protocol, it is convenient to label each peer in the context of the role it is performing at a given time: o When a BXXP session is established, we designate the peer that awaits new connections as acting in the listening role, and the other peer, which establishes a connection to the listener, as acting in the initiating role. In the examples which follow, these are referred to as "I:" and "L:", respectively. o We designate a BXXP peer making a request as a client; similarly, we designate the other BXXP peer as a server. In the examples which follow, these are referred to as "C:" and "S:", respectively. Typically, a BXXP peer acting in the server role is also acting in a listening role. However, because BXXP is peer-to-peer in nature, no such requirement exists. Rose Expires September 7, 2000 [Page 5] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.2 Messages and Frames In BXXP, there are three kinds of messages: requests, responses, and sequence updates. Each request or response conveys data, which is segmented as the payload of one or more frames. Each frame consists of a header, the payload, and a trailer. The header and trailer are each represented using printable ASCII characters and are terminated with a CRLF pair. Between the header and the trailer is the payload, consisting of zero or more octets. For example, here is a request message whose data is contained in a single frame that contains a payload of 81 octets spread over 3 lines (each line of the data is terminated with a CRLF pair): C: REQ . 1 0 94 0 C: C: C: C: C: END Note that the header is two lines long (the second line is blank signifying a lack of explicit MIME typing information). The sequence update message is used to flow control request and response messages, and is represented using printable ASCII characters terminated by a CRLF pair. For example, here is a sequence update message: C: SEQ 1 0 65535 Note that the sequence update message doesn't have a header, payload, or trailer -- it's simply a single line. Rose Expires September 7, 2000 [Page 6] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.2.1 Message Syntax The ABNF for a message is: message = frame / seq frame = header payload trailer header = req / rsp req = "REQ" SP more SP serial SP seqno SP size SP channel CR LF [mime] CR LF rsp = "RSP" SP more SP serial SP seqno SP size SP status [SP diagnostic] CR LF [mime] CR LF more = "." / "*" ; use of 0 for is reserved for the listener's greeting serial = 0..32767 seqno = 0..4294967295 size = 0..2147483647 ; use of 0 for is reserved for BXXP channel management channel = 0..255 ; defaults are: ; ; Content-Type: text/xml ; Content-Transfer-Encoding: 8bit ; mime = status = "+" / "-" diagnostic = *(VCHAR / SP) payload = *OCTET trailer = "END" CR LF seq = "SEQ" SP channel SP ackno SP window CR LF ackno = seqno window = size Rose Expires September 7, 2000 [Page 7] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.2.1.1 Frame Header The frame header consists of a three-character keyword (one of: "REQ" or "RSP"), followed by a continuation indicator, a serial number, a sequence number, a payload size, and one or more parameters. A single space character (decimal code 32, " ") separates each component. The header is terminated with a CRLF pair. The "REQ" keyword indicates that this frame is part of a request message. Following the "REQ" keyword, the continuation indicator, the serial number, the sequence number, and the payload size is the channel number for the request. The "RSP" keyword indicates that this frame is part of a response message. Following the "RSP" keyword, the continuation indicator, the serial number, the sequence number, and the payload size is a status indicator, and, optionally, a textual diagnostic. The continuation indicator (one of: decimal code 42, "*", or decimal code 46, ".") specifies whether this is the final frame of the message: intermediate ("*"): at least one other frame follows for the message; or, complete ("."): this frame completes the data for the message. The serial number must be a non-negative integer (in the range 0..32767) and have a different value than all other outstanding request messages (regardless of channel number). The sequence number must be a non-negative integer (in the range 0..4294967295) and specifies the sequence number of the first octet in the payload, for the associated channel. The payload size must be a non-negative integer (in the range 0..2147483647) and specifies the exact number of octets in the payload. (This does not include the trailer.) The status indicator (one of: decimal code 43, "+", or decimal code 45, "-"), specifies whether the request corresponding to this response was performed: positive ("+"): the request was performed and the response's data contains the corresponding the results; or, negative ("-"): the request could not be performed (either for transient or permanent reasons) and the response's data contains the corresponding error information. Rose Expires September 7, 2000 [Page 8] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 There are several rules for identifying poorly-formed frames: o if the header doesn't start with "REQ" or "RSP"; o if the header starts with "REQ" or "RSP", but any of the continuation indicator, serial number, sequence number, or payload size can not be determined or is invalid; o if the header starts with "REQ", but the channel number can not be determined or is invalid; o if the header starts with "RSP", but the status indicator can not be determined or is invalid; o if the header starts with "RSP", but the serial number does not refer to an outstanding request message; o if the value of the sequence number doesn't correspond to the expected value for the associated channel (c.f., Section 2.5.3); o if the header starts with "REQ" and refers to a message for which at least one other "REQ" frame has been received, and if the continuation indicator of the immediate-previously received frame is intermediate ("*"), and if the channel numbers aren't identical; or, o if the header starts with "RSP" and refers to a message for which at least one other "RSP" frame has been received, and if the status indicator of this frame and the immediate-previously received frame are not identical. If a frame is poorly-formed, then the connection is closed without generating any response. The final frame in a message has a continunation indicator of complete ("."), whilst all earlier frames (if any) have a continuation indicator of intermediate ("*"). Note that any of these frames may have an empty payload, e.g., S: RSP * 1 284 25 + S: S: ... S: ... S: ... S: END S: RSP . 1 309 0 + S: S: END Rose Expires September 7, 2000 [Page 9] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.2.1.2 Frame Payload The data conveyed with a message is structured according to the rules of MIME. Accordingly, the header of the first frame for a message may include "entity-headers" (c.f., MIME[4]'s Section 3). If none, or only some, of the entity-headers are present: o the default "Content-Type" is "text/xml"; and, o the default "Content-Transfer-Encoding" is "8bit". Hence, in the absence of typing information, a message's data is a well-formed XML[3] document. Note that the "entity-headers" (and the empty line that follows) are part of the of the header, not the payload. Thus, they do not contribute to the size of the payload. 2.2.1.3 Frame Trailer The frame trailer consists of "END" followed by a CRLF pair. When receiving a frame, if the characters immediately following the payload don't correspond to a trailer, then the connection is closed without generating a response. 2.2.2 Frame Semantics The semantics of the payload of each frame is channel-specific. Accordingly, the profile associated with a channel must define: o the profile initialization messages, if any, exchanged during channel creation; o the set of request and response messages may be carried in the payload of the channel; and, o the semantics of these messages. A profile registration template (Section 5) is used to organize this information. Rose Expires September 7, 2000 [Page 10] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.3 Channel Management When a BXXP session starts, only channel number 0 is defined, which is used for channel management. Section 6.1 contains the profile registration for BXXP channel management. 2.3.1 Message Semantics 2.3.1.1 The Start Message When a BXXP peer wants to create a channel, it sends a "start" element as data on channel 0, e.g., I: REQ . 1 0 94 0 I: I: I: I: I: END The "start" element contains a "number" attribute, an optional "serverName" attribute, and one or more "profile" elements: o the "number" attribute indicates the channel number (in the range 1..255) used to identify the channel in future frames; o the "serverName" attribute indicates the desired server name for this connection; and, o each "profile" element contained within the "start" element identifies a profile, and, optionally, contains an arbitrary XML element exchanged during channel creation. To avoid conflict in assigning channel numbers when requesting the creation of a channel, BXXP peers acting in the initiating role use only positive integers that are odd-numbered; similarly, BXXP peers acting in the listening role use only positive integers that are even-numbered. The "serverName" attribute is examined only in the first "start" element received by a BXXP peer. (If the attribute isn't present or it's value is empty, then the sending BXXP peer is requesting a configuration-specific default value.) The BXXP peer decides whether to operate as the indicated "server"; if not, an "error" element is returned as data in a negative "RSP" message. When a BXXP peer receives a "start" element as data on channel 0, it examines each of the proposed profiles, and decides whether to use one of them to create the channel. If so, the appropriate "profile" Rose Expires September 7, 2000 [Page 11] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 element is returned as data in a positive "RSP" message; otherwise, an "error" element is returned as data in a negative "RSP" message. When creating the channel, the value of the "serverName" attribute from the first "start" element is consulted to provide configuration information, e.g., the desired server-side certificate when starting the TLS transport security profile (Section 3.1). For example, a successful channel creation might look like this: I: REQ . 1 0 171 0 I: I: I: I: I: I: END L: RSP . 1 284 61 + L: L: L: END Consult Section 4.1 for an example in which a "profile" element contains an optional initialization element. Similarly, an unsuccessful channel creation might look like this: I: REQ . 1 0 94 0 I: I: I: I: I: END L: RSP . 1 284 89 - L: L: number attribute L: in <start> element must be odd-valued L: END Rose Expires September 7, 2000 [Page 12] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.3.1.2 The Greeting Message When a BXXP session is established and the BXXP peer acting in the listening role is available, it returns a "greeting" element as data in a positive "RSP" message, e.g., L: I: L: RSP . 0 0 84 + L: L: L: L: L: END The "greeting" element contains one or more "profile" elements, one for each profile supported by the BXXP peer acting in the listening role: o each "profile" element contained within the "greeting" element identifies a profile, and unlike the "profile" elements that occur within the "start" element, the contents of each "profile" element may not contain an optional initialization element. Rose Expires September 7, 2000 [Page 13] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.3.1.3 The Error Message When a BXXP peer declines the creation of a channel, it returns an "error" element as data in a negative "RSP" message, e.g., I: REQ . 1 0 89 0 I: I: I: I: I: END L: RSP . 1 284 67 - L: L: all requested profiles are L: unsupported L: END The "error" element contains a "code" attribute and an optional textual-diagnostic: o the "code" attribute is a three digit reply code meaningful to programs (Section 7 defines the list of possible values); and, o the textual-diagnostic (which may be multiline) is meaningful to implementers, perhaps operators, and possibly even users. In addition, a BXXP peer returns an "error" element whenever: o it receives a "REQ" message containing an unexpected element; or, o a BXXP session is established, the BXXP peer is acting in the listening role, and that BXXP peer is unavailable. In the latter case, both BXXP peers close the connection. Rose Expires September 7, 2000 [Page 14] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.4 Session Establishment and Release When a BXXP session is established, the BXXP peer acting in the listening role immediately sends a positive "RSP" message with a serial number of zero that contains a "greeting" element, e.g., L: I: L: RSP . 0 0 84 + L: L: L: L: L: END which indicates that the BXXP peer is available. Alternatively, a negative response may also be returned, e.g., L: I: L: RSP . 0 0 22 - system load too high L: L: L: END I: L: L: which indicates that the BXXP peer is unavailable. When a BXXP peer wants to release the session, it sends a "REQ" message on channel 0 with no data. The other BXXP peer may accept the request (by sending a positive "RSP" message), e.g., C: REQ . 1 0 0 0 C: C: END S: RSP . 1 284 0 + S: S: END C: S: L: If the other BXXP peer sends a negative "RSP" message, then the connection should remain open, if possible. Rose Expires September 7, 2000 [Page 15] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.5 Flow Control Although the underlying transport service imposes flow control on a per-connection basis, if multiple channels are simultaneously in use within a connection, BXXP must provide a mechanism to avoid starvation and deadlock. To achieve this, BXXP re-introduces mechanisms used by the TCP: sequence numbers and window-based flow control. Briefly, each channel has a sliding window that indicates the number of payload octets that a peer may transmit before receiving further permission. Every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively. The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. 2.5.1 Channel Creation When a channel is created, the sequence number associated with the first payload octet of the first frame is 0, and the initial window size for that channel is 4096 octets. After channel creation, a BXXP peer may update the window size by sending a "SEQ" message (Section 2.5.4). If a BXXP peer is requested to create a channel and it is unable to allocate at least 4096 octets for that channel, it must decline creation of the channel (Section 2.3.1.3). Similarly, during session establishment, if the BXXP peer acting in the listening role is unable to allocate at least 4096 octets for channel 0, then it must return a negative response (Section 2.4) instead of a greeting. Rose Expires September 7, 2000 [Page 16] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.5.2 Sending REQ or RSP Messages Before a message is sent, the sending BXXP peer must ensure that the size of the payload is within the window advertised by the receiving BXXP peer. If not, it has three choices: o if the window would allow for at least one payload octet to be sent, the BXXP peer may segment the message and start by sending a smaller frame (upto the size of the remaining window); o the BXXP peer may delay sending the message until the window becomes larger; or, o the BXXP peer may signal to its application that it is unable to send the message. The choice is implementation-dependent, although it is recommended that the application using BXXP be given a mechanism for influencing the decision. 2.5.3 Receiving REQ or RSP Messages When a frame is received, the sum of its sequence number and payload size, modulo 4294967296 (2**32), gives the expected sequence number associated with the first payload octet of the next frame received. Accordingly, when receiving a frame if the sequence number isn't the expected value for this channel, then the BXXP peers have lost synchronization, and the connection is closed without generating any response. Rose Expires September 7, 2000 [Page 17] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.5.4 Processing SEQ Messages As an application accepts responsibility for incoming frames, its BXXP peer should send "SEQ" messages to advertise a new window. The "SEQ" message has three parameters: o a channel number; o an acknowledgement number, that indicates the value of the next sequence number that the sender is expecting to receive on this channel; and, o a window size, that indicates the number of payload octets beginning with the one indicated by the acknowledgement number that the sender is expecting to receive on this channel. A single space character (decimal code 32, " ") separates each component. The "SEQ" message is terminated with a CRLF pair. When a "SEQ" message is received, if the channel number, acknowledgement number, or window size can not be determined or is invalid, then the message is poorly-formed, and the connection is closed without generating any response. 2.5.5 Use of Flow Control The key to successful use of flow control within BXXP is to balance performance and fairness: o large messages should be segmented into multiple frames to allow for pipelining within the window; o frames for different channels should be sent in a round-robin fashion to avoid starvation; and, o "SEQ" messages should be sent frequently to avoid deadlock. Rose Expires September 7, 2000 [Page 18] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.6 Sequencing and Parallelism o Within a single channel: A BXXP peer acting in the client role may send multiple "REQ" messages for the same channel without waiting to receive the corresponding "RSP" messages. A BXXP peer acting in the server role must process all "REQ" messages for a given channel in the same order as they were received. As a consequence, that BXXP peer must generate the corresponding "RSP" messages in the same order as the "REQ" messages were received. o Between different channels: A BXXP peer acting in the client role may send multiple "REQ" messages for different channels without waiting to receive the corresponding "RSP" messages. A BXXP peer acting in the server role may process "REQ" messages received for different channels in parallel. As a consequence, although the "RSP" messages for a given channel are generating according to the order in which the corresponding "REQ" messages were received, there is no ordering constraint between "RSP" messages for different channels. o Asynchronous responses: A BXXP peer acting in the server role may send a negative response to a request before it receives the final "REQ" frame of a request. If it does so, that BXXP peer is obliged to ignore any subsequent "REQ" frames for that request, upto and including the final "REQ" frame. If a BXXP peer acting in the client role receives a negative "RSP" frame before it sends the final "REQ" frame for a request, then it is required to send a "REQ" frame with a continuation status of complete (".") and having a zero-length payload. If the processing of a particular frame has sequencing impacts on other frames (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport service. Rose Expires September 7, 2000 [Page 19] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 2.7 Peer-to-Peer Behavior BXXP is a peer-to-peer protocol, as such both peers must be prepared to receive both "REQ" and "RSP" frames. As such, an initiating BXXP peer capable of acting only in the client role must behave gracefully if it receives a "REQ" message. Accordingly, all profiles must provide an appropriate error message for responding to unwanted requests. As a consequence of the peer-to-peer nature of BXXP, serial numbers are unidirectionally-significant. That is, the serial numbers in "REQ" messages sent by a BXXP initiator are unrelated to the serial numbers in "REQ" messages sent by a BXXP listener. For example, these two frames I: REQ . 1 0 94 0 I: I: I: I: I: END L: REQ . 1 284 89 0 L: L: L: L: L: END have no fundamental relationship to each other. Rose Expires September 7, 2000 [Page 20] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 3. Transport Security When a BXXP session starts, plaintext transfer, without privacy, is provided. Accordingly, transport security in BXXP is achieved using an initial tuning profile. This document defines one profile: o the TLS transport security profile, based on TLS version 1[5]. Other profiles may be defined and deployed on a bilateral basis. When a channel associated with transport security begins the underlying negotiation process, all channels (including channel 0), are closed on the BXXP session. Upon completion of the negotiation process, regardless of its outcome, a new BXXP greeting is issued. Rose Expires September 7, 2000 [Page 21] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 A BXXP listener may choose to issue different greetings based on whether privacy is in use, e.g., L: I: L: RSP . 0 0 84 + L: L: L: L: L: END I: REQ . 1 0 120 0 I: I: I: I: I: I: I: END L: RSP . 1 84 83 + L: L: L: L: L: END ... successful transport security negotation ... L: RSP . 0 0 224 + L: L: L: L: L: L: L: END Rose Expires September 7, 2000 [Page 22] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Of course, not all servers need be as single-minded: L: I: L: RSP . 0 0 284 + L: L: L: L: L: L: L: L: END I: REQ . 1 0 120 0 I: I: I: I: I: I: I: END L: RSP . 1 284 83 + L: L: L: L: L: END ... failed transport security negotation ... L: RSP . 0 0 284 + L: L: L: L: L: L: L: L: END Rose Expires September 7, 2000 [Page 23] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 3.1 The TLS Transport Security Profile Section 6.3 contains the registration for this profile. 3.1.1 Profile Identification and Initialization The TLS transport security profile is identified as http://xml.resource.org/profiles/TLS in the BXXP "profile" element during channel creation. During channel creation, the corresponding "profile" element in the BXXP "start" element may contain a "ready" element. If channel creation is successful, then before sending the corresponding "RSP" message, the BXXP peer processes the "ready" element and includes the resulting response in the "RSP" message, e.g., C: REQ . 1 0 120 0 C: C: C: C: C: C: C: END S: RSP . 1 84 83 + S: S: S: S: S: END in the BXXP "profile" element during channel creation, e.g., Rose Expires September 7, 2000 [Page 24] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g., C: REQ . 1 0 135 0 C: C: C: C: C: C: C: END S: RSP . 1 84 169 + S: S: S: version attribute S: poorly formed in <ready> element S: S: S: END In this case, a positive "RSP" message is returned (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed. 3.1.2 Request and Response Messages Section 6.4 defines the messages that are used in the TLS transport security profile: o "REQ" messages carry only the "ready" element as data; o positive "RSP" messages carry only the "proceed" element as data; and, o negative "RSP" messages carry only the "error" element as data. Rose Expires September 7, 2000 [Page 25] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 3.1.3 Message Semantics 3.1.3.1 The Ready Message The "ready" element contains one optional attribute: o the "version" element defines the earliest version of TLS acceptable for use. When a BXXP peer sends the "ready" element, it no longer sends any traffic on any channels until a corresponding "RSP" message is received; similarly, before processing a "ready" element, the receiving BXXP peer waits until any pending "RSP" messages have been generated and sent. 3.1.3.2 The Proceed Message The "proceed" element is empty and contains no attributes. It is sent in response to the "ready" element. When a BXXP peer receives the "ready" element, it begins the underlying negotiation process for transport security. Rose Expires September 7, 2000 [Page 26] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4. User Authentication When a BXXP session starts, anonymous access, without trace information, is provided. Whenever a successful authentication occurs, on any channel, the authenticated identity is updated for all existing and future channels on the BXXP session. Accordingly, authentication in BXXP is achieved using initial tuning profiles based on SASL[6] mechanisms. This document defines three profiles: o the SASL ANONYMOUS profile, based on the Anonymous SASL mechanism[7]; o the SASL OTP profile, based on the OTP SASL mechanism[8]; and, o the SASL EXTERNAL profile, based on the External SASL mechanism[6]. Other profiles may be defined and deployed on a bilateral basis. Finally, authorization is an internal matter for each BXXP peer. As such, each peer may choose to restrict the operations it allows based on the authentication credentials provided (i.e., unauthorized operations are rejected with error code 530). Rose Expires September 7, 2000 [Page 27] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.1 Profile Identification and Initialization Each profile in the SASL family of user authentication profiles is uniquely named. Consult the appropriate profile registration for the string to use in the BXXP "profile" element during channel creation, e.g., C: REQ . 1 0 171 0 C: C: C: C: C: C: END S: RSP . 1 284 61 + S: S: S: END During channel creation, the corresponding "profile" element in the BXXP "start" element may contain a SASL "identity" element. If channel creation is successful, then before sending the corresponding "RSP" message, the BXXP peer processes the SASL "identity" element and includes the resulting SASL "challenge" or "complete" element in the "RSP" message, e.g., C: REQ . 1 0 222 0 C: C: C: C: C: blockmaster@example.com C: C: C: C: END S: RSP . 1 284 99 + S: S: S: S: S: END Rose Expires September 7, 2000 [Page 28] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Note that it is possible for the SASL channel to be created, but for the encapsulated operation to fail, e.g., C: REQ . 1 0 201 0 C: C: C: C: C: blockmaster C: C: C: C: END S: RSP . 1 284 144 + S: S: S: authentication mechanism is S: too weak S: S: END In this case, a positive "RSP" message is returned (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed. Rose Expires September 7, 2000 [Page 29] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.2 Request and Response Messages Section 6.8 defines the messages that are used for each profile in the SASL family of user authentication profiles: o "REQ" messages carry either the "identity" or "response" elements as data; o positive "RSP" messages carry either the "challenge" or "complete" element as data; and, o negative "RSP" messages carry only the "error" element as data. The sequence of messages corresponds to an authentication protocol exchange: 1. An "identity" element (usually encapsulated within a BXXP "profile" element) is sent, and the exchange proceeds to Step 2. 2. One of three responses is possible: * a (successful) completion indication, in this case, a "complete" element is returned, and the exchange terminates; or, * a failure indication, in this case, an "error" element is returned, and the exchange terminates; otherwise, * further interaction is required, a "challenge" element is returned, and the exchange proceeds to Step 3. 3. If a "challenge" element is returned, then either: * a "response" element (with "abort" set to false) is sent, and the exchange returns to Step 2; or, * an "response" element (with "abort" set to true) is sent, and the exchange proceeds to Step 4. 4. A "complete" element is returned, and the exchange terminates. Note that profiles in the SASL family of user authentication profiles do not negotiate the use of a mechanism-specific security layer. (This is accomplished independently using a transport security profile.) Rose Expires September 7, 2000 [Page 30] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.3 Message Semantics 4.3.1 The Identity Message The "identity" element contains one or two elements: o the "authenticator" element carries an authentication identity; and, o if present, the "authorization" element carries an authorization identity. The authentication and authorization identities may be different to permit agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. If the "authorization" element isn't present (or is empty), then the access privileges of the "authenticator" element are requested. 4.3.2 The Challenge Message The "challenge" element contains character data for the corresponding SASL mechanism's server challenge. 4.3.3 The Response Message The "response" element contains character data for the corresponding SASL mechanism's client response. The optional "abort" attribute, if present, indicates the client is aborting the authentication process. 4.3.4 The Complete Message The "complete" element is empty and signifies that the authentication process is complete. Success or failure is determined according to the value of the "abort" attribute of the preceeding "response" element, if any. Rose Expires September 7, 2000 [Page 31] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.4 The SASL ANONYMOUS Profile Section 6.5 contains the registration for this profile. 4.4.1 Profile Identification The SASL ANONYMOUS profile is identified as http://xml.resource.org/profiles/SASL/ANONYMOUS in the BXXP "profile" element during channel creation. 4.4.2 Message Semantics The "identity" element contains only the "authenticator" element. The contents of this element is either an email-address or trace-information (c.f., [7]'s Section 2). The server always returns a "complete" element in response to a well-formed and valid "identity" element, e.g., C: REQ . 1 0 222 0 C: C: C: C: C: blockmaster@example.com C: C: C: C: END S: RSP . 1 284 99 + S: S: S: S: S: END Rose Expires September 7, 2000 [Page 32] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.5 The SASL OTP Profile Section 6.6 contains the registration for this profile. 4.5.1 Profile Identification The SASL OTP profile is identified as http://xml.resource.org/profiles/SASL/OTP in the BXXP "profile" element during channel creation. 4.5.2 Message Semantics The "identity" element contains at least the "authenticator" element. The contents of this element is a user identity, used in a one-time password authentication system[9]. The server returns an OTP extended challenge (c.f., [10]'s Section 2.1) contained within a "challenge" element, and awaits a reply, e.g., C: REQ . 1 0 201 0 C: C: C: C: C: blockmaster C: C: C: C: END S: RSP . 1 284 132 + S: S: S: otp-sha1 9997 pixymisas85805 ext S: S: END Rose Expires September 7, 2000 [Page 33] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 The client returns the appropriate OTP extended response (c.f., [10]'s Section 3 and 4) contained within a "response" element, and awaits a reply, e.g., C: REQ . 2 201 56 1 C: C: word:fern hang brow bong herd tog C: END S: RSP . 2 416 13 + S: S: S: END Of course, the client could instead abort the authentication process by sending "" instead. Similarly, the server might reject the response with an error: e.g., C: REQ . 2 201 56 1 C: C: word:fern hang brow bong herd tog C: END S: RSP . 2 416 22 - S: S: S: END Finally, note that in addition to supporting the "hex" and "word" responses, a server must also support the "init-hex" and "init-word" responses of [10]. Rose Expires September 7, 2000 [Page 34] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 4.6 The SASL EXTERNAL Profile Section 6.7 contains the registration for this profile. 4.6.1 Profile Identification The SASL EXTERNAL profile is identified as http://xml.resource.org/profiles/SASL/EXTERNAL in the BXXP "profile" element during channel creation. 4.6.2 Message Semantics This profile works with an "external authentication" service, which is provided by either of: o a transport security profile, capable of providing authentication information (e.g., Section 3.1), being active on the connection; or, o a network service, capable of providing strong authentication (e.g., IPSec[11]), underlying the connection. The "identity" element contains at least the "authenticator" element. For the authentication to succeed, two conditions must hold: o an "external authentication" service must be active; and, o if present, the contents of the "authenticator" element must be consistent with the credentials provided by the "external authentication" service (if the "authenticator" element is empty, then an authorization identity is automatically derived from the credentials provided by the "external authentication" service). Rose Expires September 7, 2000 [Page 35] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 If these two conditions are met, then the server returns a "complete" element in response, e.g., C: REQ . 1 0 188 0 C: C: C: S: S: S: END Otherwise, the server rejects the response with an "error" element. Rose Expires September 7, 2000 [Page 36] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 5. Profile Registration Template When a profile is registered, the following information is supplied: Profile Identification: specify a URI[12] that authoritatively identifies this profile. Elements in during channel creation request: specify the elements that may be exchanged during channel creation (note that if the profile doesn't exchange XML elements, then profile messages may not be exchanged during channel creation). Messages in "REQ" frames: specify the datatypes that may be present in a request. Messages in positive "RSP" frames: specify the datatypes that may be present in a positive response. Messages in negative "RSP" frames: specify the datatypes that may be persent in negative response. Message Syntax: specify the syntax of the datatypes exchanged by the profile. Message Semantics: specify the semantics of the datatypes exchanged by the profile. Note that "datatype" refers to any MIME media type, whilst "element" refers to any well-formed XML document. Rose Expires September 7, 2000 [Page 37] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6. Initial Profile Registrations 6.1 BXXP Channel Management Profile Identification: not applicable Messages in Profile Initialization: not applicable Messages in "REQ" frames: "start" Messages in positive "RSP" frames: "greeting" or "profile" Messages in negative "RSP" frames: "error" Message Syntax: c.f., Section 6.2 Message Semantics: c.f., Section 2.3.1 Rose Expires September 7, 2000 [Page 38] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6.2 BXXP Channel Management DTD Rose Expires September 7, 2000 [Page 39] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Rose Expires September 7, 2000 [Page 40] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6.3 TLS Transport Security Profile Registration Profile Identification: http://xml.resource.org/profiles/TLS Messages in Profile Initialization: "ready" Messages in "REQ" frames: "ready" Messages in positive "RSP" frames: "proceed" Messages in negative "RSP" frames: "error" Message Syntax: c.f., Section 6.4 Message Semantics: c.f., Section 3.1.3 Rose Expires September 7, 2000 [Page 41] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6.4 TLS Transport Security Profile DTD Rose Expires September 7, 2000 [Page 42] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6.5 SASL ANONYMOUS User Authentication Profile Registration Profile Identification: http://xml.resource.org/profiles/SASL/ANONYMOUS Messages in Profile Initialization: "identity" Messages in "REQ" frames: "identity" Messages in positive "RSP" frames: "complete" Messages in negative "RSP" frames: "error" Message Syntax: c.f., Section 6.8 Message Semantics: c.f., Section 4.4.2 6.6 SASL OTP User Authentication Profile Registration Profile Identification: http://xml.resource.org/profiles/SASL/OTP Messages in Profile Initialization: "identity" Messages in "REQ" frames: "identity" Messages in positive "RSP" frames: "challenge" or "complete" Messages in negative "RSP" frames: "error" Message Syntax: c.f., Section 6.8 Message Semantics: c.f., Section 4.5.2 6.7 SASL EXTERNAL User Authentication Profile Registration Profile Identification: http://xml.resource.org/profiles/SASL/EXTERNAL Messages in Profile Initialization: "identity" Messages in "REQ" frames: "identity" Messages in positive "RSP" frames: "complete" Messages in negative "RSP" frames: "error" Message Syntax: c.f., Section 6.8 Message Semantics: c.f., Section 4.6.2 Rose Expires September 7, 2000 [Page 43] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 6.8 SASL Family of User Authentication Profiles DTD Rose Expires September 7, 2000 [Page 44] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Rose Expires September 7, 2000 [Page 45] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 7. Reply Codes code meaning ==== ======= 421 service not available 450 requested action not taken (e.g., lock already in use) 451 requested action aborted (e.g., local error in processing) 454 temporary authentication failure 500 general syntax error (e.g., poorly-formed XML) 501 syntax error in parameters (e.g., non-valid XML) 504 parameter not implemented 530 authentication required 534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.) 535 authentication failure 537 action not authorized for user 538 authentication mechanism requires encryption 550 requested action not taken (e.g., no requested profiles are acceptable) 553 parameter invalid (e.g., invalid prevno for release operation) 554 transaction failed (e.g., policy violation) Rose Expires September 7, 2000 [Page 46] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 8. Security Considerations The BXXP framing mechanism, per se, provides no protection against attack; however, judicious use of initial tuning profiles provide varying degrees of assurance: 1. If one of the profiles from the SASL family of user authentication profiles is used, refer to [6]'s Section 9 for a discussion of security considerations. Further: 1. If the SASL ANONYMOUS profile is used, refer to [7]'s Section 4 for a discussion of security considerations; and, 2. If the SASL OTP profile is used, refer to [8]'s Section 6, [9]'s Section 10, and [10]'s Section 5 for a discussion of security considerations. 2. If the TLS transport security profile is used, then: 1. A man-in-the-middle may remove the TLS transport security profile from the BXXP greeting or generate an error response to the "ready" element of the profile. A BXXP peer may be configurable to refuse to proceed without an acceptable level of privacy. 2. A man-in-the-middle may cause a down-negotiation to the weakest cipher suite available. A BXXP peer should be configurable to refuse weak cipher suites. 3. A man-in-the-middle may modify any protocol interactions prior to a successful TLS handshake. Upon completing the TLS handshake, a BXXP peer must discard previously cached information about the session. Rose Expires September 7, 2000 [Page 47] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 References [1] Postel, J., "Transmission Control Protocol", RFC 793, STD 7, Sep 1981. [2] Rose, M.T., "On the Design of Application Protocols", draft-mrose-blocks-appldesign-01 (work in progress), March 2000. [3] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, . [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] Myers, J.G., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [7] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November 1997. [8] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998. [9] Haller, N., Metz, C., Nesser, P.J. and M. Straw, "A One-Time Password System", RFC 2289, February 1998. [10] Metz, C., "OTP Extended Responses", RFC 2243, November 1997. [11] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [12] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [13] mailto:blocks-request@invisible.net [14] http://mappa.mundi.net/ [25] mailto:ddc@lcs.mit.edu [26] mailto:dcrocker@brandenburg.com [27] mailto:deering@cisco.com Rose Expires September 7, 2000 [Page 48] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 [28] mailto:dannyg@dannyg.com [29] mailto:carl@invisible.net [30] mailto:pvm@a21.com [31] mailto:rlmorgan@washington.edu [32] mailto:paul@vix.com [33] mailto:woods@invisible.net Author's Address Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US Phone: +1 707 789 3700 EMail: mrose@invisible.net URI: http://invisible.net/ Rose Expires September 7, 2000 [Page 49] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Appendix A. Acknowledgements The author gratefully acknowledges the contributions of: David Clark[25], Dave Crocker[26], Steve Deering[27], Danny Goodman[28], Carl Malamud[29], Paul Mockapetris[30], RL 'Bob' Morgan[31], Paul Vixie[32], and Daniel Woods[33]. In particular, Dave Crocker provided helpful suggestions on the nature of flow control and segmentation in the framing protocol. Rose Expires September 7, 2000 [Page 50] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Appendix B. Changes from draft-mrose-blocks-protocol-00 o Profiles are now identified using URIs. o The Appendix entitled "Design Comments" was removed. Refer to [2]. o In Section 2.2.1.1, the range of serial-numbers was clarified to be non-negative. o In Section 2.3.1.1, a "serverName" attribute was added to the "start" element. o The SASL EXTERNAL (Section 4.6) profile was added. Rose Expires September 7, 2000 [Page 51] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Invisible Worlds expressly disclaims any and all warranties regarding this contribution including any warranty that (a) this contribution does not violate the rights of others, (b) the owners, if any, of other rights in this contribution have been informed of the rights and permissions granted to IETF herein, and (c) any required authorizations from such owners have been obtained. This document and the information contained herein is provided on an "AS IS" basis and INVISIBLE WORLDS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL INVISIBLE WORLDS BE LIABLE TO ANY OTHER PARTY INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. Rose Expires September 7, 2000 [Page 52] Internet-Draft The Blocks eXtensible eXchange Protocol March 2000 Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Rose Expires September 7, 2000 [Page 53]