One document matched: draft-mrose-blocks-protocol-00.txt
Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc.
Expires: July 22, 2000 January 22, 2000
The Blocks eXtensible eXchange Protocol
draft-mrose-blocks-protocol-00.txt
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 July 22, 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 both
multiplexing of independent request/response streams over a single
transport connection, as well as segmentation and flow control of
both textual and binary messages.
To subscribe to the Blocks discussion list, send e-mail[10]; there
is also a developers' site[11].
Rose Expires July 22, 2000 [Page 1]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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
5. Profile Registration Template . . . . . . . . . . . . . . 35
6. Initial Profile Registrations . . . . . . . . . . . . . . 36
6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 36
Rose Expires July 22, 2000 [Page 2]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 37
6.3 TLS Transport Security Profile Registration . . . . . . . 39
6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 40
6.5 SASL ANONYMOUS User Authentication Profile Registration . 41
6.6 SASL OTP User Authentication Profile Registration . . . . 41
6.7 SASL Family of User Authentication Profiles DTD . . . . . 42
7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . 45
References . . . . . . . . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . 46
A. Design Comments . . . . . . . . . . . . . . . . . . . . . 47
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48
Full Copyright Statement . . . . . . . . . . . . . . . . . 49
Rose Expires July 22, 2000 [Page 3]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
1. Introduction
BXXP provides a generic application protocol framework for
connection-oriented, asynchronous request-response interactions over
TCP[1].
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. Requests and responses are either textual (structured using
XML[2]) or arbitrary (structured using MIME[3]), and both may be
segmented.
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[4] transport security profile; and,
o the SASL[5] 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 July 22, 2000 [Page 4]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 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 July 22, 2000 [Page 5]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 81 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
C: </start>
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. Unlike the request and
response messages, the sequence update message is never segmented.
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 July 22, 2000 [Page 6]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 <serial> is reserved for the listener's greeting
serial = 0..32767
seqno = 0..4294967295
size = 0..2147483647
; use of 0 for <channel> is reserved for BXXP channel management
channel = 0..255
; defaults are:
;
; Content-Type: text/xml
; Content-Transfer-Encoding: 8bit
;
mime = <MIME Content {entity-headers} from RFC 2045>
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 July 22, 2000 [Page 7]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 positive integer (in the range 1..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 July 22, 2000 [Page 8]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 218 25 +
S:
S: ...
S: ...
S: ...
S: END
S: RSP . 1 243 0 +
S: END
Rose Expires July 22, 2000 [Page 9]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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[3]'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[2] 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 July 22, 2000 [Page 10]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 81 0
I:
I: <start number='1'>
I: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
I: </start>
I: END
The "start" element contains a "number" 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; 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.
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"
element is returned as data in a positive "RSP" message; otherwise,
an "error" element is returned as data in a negative "RSP" message.
Rose Expires July 22, 2000 [Page 11]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
For example, a successful channel creation might look like this:
I: REQ . 1 0 136 0
I:
I: <start number='1'>
I: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
I: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN' />
I: </start>
I: END
L: RSP . 1 218 47 +
L:
L: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
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 81 0
I:
I: <start number='2'>
I: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
I: </start>
I: END
L: RSP . 1 218 89 -
L:
L: <error code='501'>number attribute
L: in <start> element must be odd-valued</error>
L: END
Rose Expires July 22, 2000 [Page 12]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 71 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD TLS//EN' />
L: </greeting>
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 July 22, 2000 [Page 13]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 77 0
I:
I: <start number='2'>
I: <profile dtd='-//Blocks//DTD EXCH//EN' />
I: </start>
I: END
L: RSP . 1 218 67 -
L:
L: <error code='550'>all requested profiles are
L: unsupported</error>
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 July 22, 2000 [Page 14]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 71 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD TLS//EN' />
L: </greeting>
L: END
which indicates that the BXXP peer is available.
Alternatively, a negative response may also be returned, e.g.,
L: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 22 - system load too high
L:
L: <error code='421' />
L: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
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 . 7 100 0 0
C: END
S: RSP . 7 200 0 +
S: END
C: <close connection>
S: <close connection>
L: <wait for next connection>
If the other BXXP peer sends a negative "RSP" message, then the
connection should remain open, if possible.
Rose Expires July 22, 2000 [Page 15]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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, the BXXP must provide a mechanism to avoid
starvation and deadlock. To achieve this, the 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 July 22, 2000 [Page 16]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 the 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 July 22, 2000 [Page 17]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 18]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 19]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 81 0
I:
I: <start number='1'>
I: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
I: </start>
I: END
L: REQ . 1 0 77 0
L:
L: <start number='1'>
L: <profile dtd='-//Blocks//DTD EXCH//EN' />
L: </start>
L: END
have no fundamental relationship to each other.
Rose Expires July 22, 2000 [Page 20]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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[4].
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 July 22, 2000 [Page 21]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
A BXXP listener may choose to issue different greetings based on
whether privacy is in use, e.g.,
L: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 71 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD TLS//EN' />
L: </greeting>
L: END
I: REQ . 1 0 109 0
I:
I: <start number='1'>
I: <profile dtd='-//Blocks//DTD TLS//EN'>
I: <ready />
I: </profile>
I: </start>
I: END
L: RSP . 1 71 69 +
L:
L: <profile dtd='-//Blocks//DTD TLS//EN'>
L: <proceed />
L: </profile>
L: END
... successful transport security negotation ...
L: RSP . 0 0 180 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN' />
L: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
L: <profile dtd='-//Blocks//DTD EXCH//EN' />
L: </greeting>
L: END
Rose Expires July 22, 2000 [Page 22]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
Of course, not all servers need be as single-minded:
L: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 218 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN' />
L: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
L: <profile dtd='-//Blocks//DTD EXCH//EN' />
L: <profile dtd='-//Blocks//DTD TLS//EN' />
L: </greeting>
L: END
I: REQ . 1 0 109 0
I:
I: <start number='1'>
I: <profile dtd='-//Blocks//DTD TLS//EN'>
I: <ready />
I: </profile>
I: </start>
I: END
L: RSP . 1 218 69 +
L:
L: <profile dtd='-//Blocks//DTD TLS//EN'>
L: <proceed />
L: </profile>
L: END
... failed transport security negotation ...
L: RSP . 0 0 226 +
L:
L: <greeting>
L: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN' />
L: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
L: <profile dtd='-//Blocks//DTD EXCH//EN' />
L: <profile dtd='-//Blocks//DTD TLS//EN' />
L: </greeting>
L: END
Rose Expires July 22, 2000 [Page 23]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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
"-//Blocks//DTD TLS//EN"
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 109 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD TLS//EN'>
C: <ready />
C: </profile>
C: </start>
C: END
S: RSP . 1 71 69 +
S:
S: <profile dtd='-//Blocks//DTD TLS//EN'>
S: <proceed />
S: </profile>
S: END
in the BXXP "profile" element during channel creation, e.g.,
Rose Expires July 22, 2000 [Page 24]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 124 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD TLS//EN'>
C: <ready version="oops" />
C: </profile>
C: </start>
C: END
S: RSP . 1 71 155 +
S:
S: <profile dtd='-//Blocks//DTD TLS//EN'>
S: <error code='501'>version attribute
S: poorly formed in <ready> element</error>
S: </error>
S: </profile>
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 July 22, 2000 [Page 25]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 26]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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[5] mechanisms.
This document defines two profiles:
o the SASL ANONYMOUS profile, based on the Anonymous SASL
mechanism[6]; and,
o the SASL OTP profile, based on the OTP SASL mechanism[7].
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 July 22, 2000 [Page 27]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 138 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN' />
C: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
C: </start>
C: END
S: RSP . 1 180 47 +
S:
S: <profile dtd='-//Blocks//DTD SASL OTP//EN' />
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 213 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN'>
C: <identity>
C: <authenticator>blockmaster@example.com</authenticator>
C: </identity>
C: </profile>
C: </start>
C: END
S: RSP . 1 180 81 +
S:
S: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN'>
S: <complete />
S: </profile>
S: END
Rose Expires July 22, 2000 [Page 28]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 209 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL OTP//EN'>
C: <identity>
C: <authenticator>blockmaster</authenticator>
C: </identity>
C: </profile>
C: </start>
C: END
S: RSP . 1 180 129 +
S:
S: <profile dtd='-//Blocks//DTD SASL OTP//EN'>
S: <error code='534'>authentication mechanism is
S: too weak</error>
S: </profile>
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 July 22, 2000 [Page 29]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
4.2 Request and Response Messages
Section 6.7 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 July 22, 2000 [Page 30]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 31]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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
"-//Blocks//DTD SASL ANONYMOUS//EN"
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., [6]'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 213 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN'>
C: <identity>
C: <authenticator>blockmaster@example.com</authenticator>
C: </identity>
C: </profile>
C: </start>
C: END
S: RSP . 1 180 81 +
S:
S: <profile dtd='-//Blocks//DTD SASL ANONYMOUS//EN'>
S: <complete />
S: </profile>
S: END
Rose Expires July 22, 2000 [Page 32]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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
"-//Blocks//DTD SASL OTP//EN"
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[8].
The server returns an OTP extended challenge (c.f., [9]'s Section
2.1) contained within a "challenge" element, and awaits a reply,
e.g.,
C: REQ . 1 0 209 0
C:
C: <start number='1'>
C: <profile dtd='-//Blocks//DTD SASL OTP//EN'>
C: <identity>
C: <authenticator>blockmaster</authenticator>
C: </identity>
C: </profile>
C: </start>
C: END
S: RSP . 1 180 121 +
S:
S: <profile dtd='-//Blocks//DTD SASL OTP//EN'>
S: <challenge>otp-sha1 9997 pixymisas85805 ext</challenge>
S: </profile>
S: END
Rose Expires July 22, 2000 [Page 33]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
The client returns the appropriate OTP extended response (c.f.,
[9]'s Section 3 and 4) contained within a "response" element, and
awaits a reply, e.g.,
C: REQ . 2 209 56 1
C:
C: <response>word:fern hang brow bong herd tog</response>
C: END
S: RSP . 2 301 13 +
S:
S: <success />
S: END
Of course, the client could instead abort the authentication process
by sending "<response abort='true' />" instead.
Similarly, the server might reject the response with an error: e.g.,
C: REQ . 2 209 56 1
C:
C: <response>word:fern hang brow bong herd tog</response>
C: END
S: RSP . 2 301 22 -
S:
S: <error code='535' />
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 [9].
Rose Expires July 22, 2000 [Page 34]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
5. Profile Registration Template
When a profile is registered, the following information is supplied:
Profile Identification:
Elements in during channel creation request:
Messages in "REQ" frames:
Messages in positive "RSP" frames:
Messages in negative "RSP" frames:
Message Syntax:
Message Semantics:
Rose Expires July 22, 2000 [Page 35]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 36]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.2 BXXP Channel Management DTD
<!--
DTD for BXXP Channel Management, as of 99-03-25
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as:
<!ENTITY % BXXP PUBLIC "-//Blocks//DTD BXXP//EN"
"http://xml.resource.org/bxxp.dtd">
%BXXP;
-->
<!--
Contents
DTD data types
BXXP messages
-->
<!--
DTD data types:
entity syntax/reference example
====== ================ =======
a channel number
PINT8 1..255 1
a document type definition
DTD c.f., [W3C-XML] "-//Blocks//DTD EXCH//EN"
a 3-digit reply code
XYZ [1-5][1-9][1-9] 500
-->
<!ENTITY % PINT8 "CDATA">
<!ENTITY % DTD "CDATA">
<!ENTITY % XYZ "CDATA">
Rose Expires July 22, 2000 [Page 37]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
<!--
BXXP messages
role REQ RSP
====== === ===
L +: greeting
I or L start +: profile
-: error
-->
<!ELEMENT greeting (profile)+>
<!ELEMENT start (profile)+>
<!ATTLIST start
number %PINT8; #REQUIRED>
<!ELEMENT profile ANY>
<!ATTLIST profile
dtd %DTD; #REQUIRED>
<!ELEMENT error (#PCDATA)*>
<!ATTLIST error
code %XYZ; #REQUIRED>
Rose Expires July 22, 2000 [Page 38]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.3 TLS Transport Security Profile Registration
Profile Identification: "-//Blocks//DTD TLS//EN"
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 July 22, 2000 [Page 39]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.4 TLS Transport Security Profile DTD
<!--
DTD for the TLS Transport Security Profile, as of 99-06-08
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as:
<!ENTITY % TLS PUBLIC "-//Blocks//DTD TLS//EN"
"http://xml.resource.org/tls.dtd">
%TLS;
-->
<!--
Contents
TLS messages
-->
<!--
TLS messages
role REQ RSP
====== === ===
I or L ready +: proceed
-: error
-->
<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">
<!ELEMENT proceed EMPTY>
Rose Expires July 22, 2000 [Page 40]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.5 SASL ANONYMOUS User Authentication Profile Registration
Profile Identification: "-//Blocks//DTD SASL ANONYMOUS//EN"
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.7
Message Semantics: c.f., Section 4.4.2
6.6 SASL OTP User Authentication Profile Registration
Profile Identification: "-//Blocks//DTD SASL OTP//EN"
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.7
Message Semantics: c.f., Section 4.5.2
Rose Expires July 22, 2000 [Page 41]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
6.7 SASL Family of User Authentication Profiles DTD
<!--
DTD for the SASL Family of User Authentication Profiles,
as of 99-05-10
Copyright 1999, 2000 Invisible Worlds, Inc.
This document is a DTD and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Refer to this DTD as:
<!ENTITY % SASL PUBLIC "-//Blocks//DTD SASL//EN"
"http://xml.resource.org/sasl.dtd">
%SASL;
-->
<!--
Contents
SASL profiles
SASL messages
-->
<!--
SASL profiles
"-//Blocks//DTD SASL ANONYMOUS//EN" (c.f., [RFC-2245])
"-//Blocks//DTD SASL OTP//EN" (c.f., [RFC-2444], [RFC-2243])
-->
Rose Expires July 22, 2000 [Page 42]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
<!--
SASL messages
role REQ RSP
====== === ===
I or L identity +: challenge
+: complete
-: error
I or L response +: challenge
+: complete
-: error
-->
<!ELEMENT identity (authenticator,authorization?)>
<!ELEMENT authenticator
(#PCDATA)*>
<!ELEMENT authorization
(#PCDATA)*>
<!ELEMENT challenge (#PCDATA)*>
<!ELEMENT response (#PCDATA)*>
<!ATTLIST response
abort (true|false) "false">
<!ELEMENT complete EMPTY>
Rose Expires July 22, 2000 [Page 43]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 44]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 [5]'s Section 9 for a
discussion of security considerations. Further:
1. If the SASL ANONYMOUS profile is used, refer to [6]'s
Section 4 for a discussion of security considerations; and,
2. If the SASL OTP profile is used, refer to [7]'s Section 6,
[8]'s Section 10, and [9]'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 July 22, 2000 [Page 45]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
References
[1] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981.
[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[5] Myers, J.G., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[6] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November 1997.
[7] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998.
[8] Haller, N., Metz, C., Nesser, P.J. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[9] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
[10] mailto:blocks-request@invisible.net
[11] http://mappa.mundi.net/
[12] mailto:ddc@lcs.mit.edu
[13] mailto:dcrocker@brandenburg.com
[14] mailto:deering@cisco.com
[15] mailto:dannyg@dannyg.com
[16] mailto:carl@invisible.net
[17] mailto:pvm@a21.com
[18] mailto:paul@vix.com
[19] mailto:woods@invisible.net
Rose Expires July 22, 2000 [Page 46]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
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 July 22, 2000 [Page 47]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
Appendix A. Design Comments
BXXP has five design goals:
extensible: BXXP may encounter new requirements in the field, e.g.,
a need for stronger authentication frameworks. The channel
mechanism allows BXXP to become an evolutionary protocol, with a
minimal impact on its ease of deployment.
scalable: BXXP is both server- and network-friendly as it allows
multiple operations to be active simultaneously over the same
transport connection. For example, a BXXP peer acting in the
client role may choose to start several data exchange channels to
exploit the performance characteristics of a multi-threaded
server. Even so, the client's impact is limited to a single
session which both the transport service and the BXXP peer acting
in the server role can rate-limit as appropriate. Such a strategy
retains network-friendly properties whilst behaving correctly
when encountering a single-threaded server.
simple: BXXP is simple to implement. For example, the framing
mechanism provides a minimalist mechanism to envelop complex
structures, allowing for the resulting MIME and XML parsers to be
fast and small. Further, the framing mechanism is purposefully
lightweight -- an implementation of the mechanism should be small
and easy to code correctly. (If an incorrect implementation is
fielded, recovery from framing errors is a false economy.)
bilateral: BXXP is a peer-to-peer protocol. As such, the term
"unsolicited message" is oxymoronic in the context of BXXP. A
peer acting in the client role may receive requests that it is
not prepared to handle, and, in such cases, it is easy to return
an error response within negative "RSP" message.
efficient: BXXP's nested nature offers considerable efficiencies to
the implementer. For example, during channel creation for a
profile, service latency is reduced by piggybacking the first
protocol exchange.
Rose Expires July 22, 2000 [Page 48]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
Appendix B. Acknowledgements
The author gratefully acknowledges the contributions of: David
Clark[12], Dave Crocker[13], Steve Deering[14], Danny Goodman[15],
Carl Malamud[16], Paul Mockapetris[17], Paul Vixie[18], and Daniel
Woods[19]. In particular, Dave Crocker provided helpful suggestions
on the nature of segmentation and flow control in the framing
protocol.
Rose Expires July 22, 2000 [Page 49]
Internet-Draft The Blocks eXtensible eXchange Protocol January 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 July 22, 2000 [Page 50]
Internet-Draft The Blocks eXtensible eXchange Protocol January 2000
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Rose Expires July 22, 2000 [Page 51]
| PAFTECH AB 2003-2026 | 2026-04-24 06:47:04 |