Network Working Group M.T. Rose
Internet-Draft Invisible Worlds, Inc.
Expires: February 20, 2001 August 22, 2000
The Blocks eXtensible eXchange Protocol Framework
draft-ietf-beep-framework-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of 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 February 20, 2001.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo describes a generic application protocol framework for
connection-oriented, asynchronous request/response interactions. The
framework permits parallel independent request/response streams
within the context of a single application user-identity, supporting
both textual and binary messages.
Rose Expires February 20, 2001 [Page 1]
Internet-Draft The BXXP Framework August 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5
2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18
2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22
2.4 Session Establishment and Release . . . . . . . . . . . . 24
2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26
2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26
2.5.2 Data Exchange . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 27
2.6.2 Between different channels . . . . . . . . . . . . . . . . 27
2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 27
2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28
3. Transport Security . . . . . . . . . . . . . . . . . . . . 29
3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32
3.1.1 Profile Identification and Initialization . . . . . . . . 32
3.1.2 Request and Response Messages . . . . . . . . . . . . . . 33
3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 34
3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 34
3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 34
4. User Authentication . . . . . . . . . . . . . . . . . . . 35
4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36
4.1.1 Profile Identification and Initialization . . . . . . . . 37
4.1.2 Request and Response Messages . . . . . . . . . . . . . . 39
4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 40
5. Profile Registration Template . . . . . . . . . . . . . . 41
6. Initial Profile Registrations . . . . . . . . . . . . . . 42
6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 42
6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 43
6.3 Registration: TLS Transport Security Profile . . . . . . . 46
6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 47
6.5 Registration: SASL Family of Profiles . . . . . . . . . . 48
6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49
7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50
Rose Expires February 20, 2001 [Page 2]
Internet-Draft The BXXP Framework August 2000
8. Security Considerations . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
References . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . 54
A. Changes from draft-mrose-bxxp-framework-01 . . . . . . . . 55
B. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 56
C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57
Full Copyright Statement . . . . . . . . . . . . . . . . . 58
Rose Expires February 20, 2001 [Page 3]
Internet-Draft The BXXP Framework August 2000
1. Introduction
This memo describes a generic application protocol framework for
connection-oriented, asynchronous request/response interactions.
Consult [1] for a description of the framework's design principles.
At the core of the BXXP framework is a framing mechanism that allows
for peer-to-peer exchanges of requests and responses. The framing
mechanism permits multiple simultaneous and independent exchanges.
Requests and responses are arbitrary MIME[3] content, but are
usually textual (structured using XML[2]).
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:
o the TLS[4] transport security profile; and,
o the SASL[5] family of 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 February 20, 2001 [Page 4]
Internet-Draft The BXXP Framework August 2000
2. The BXXP Framework
The BXXP framework is message-oriented. 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.
A BXXP session is mapped onto an underlying transport service. A
separate series of documents describe how a particular transport
service realizes a BXXP session. For example, [6] describes how a
BXXP session is mapped onto a single TCP[7] connection.
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.
Channel usage falls into one of two categories:
initial tuning: these are used by profiles that perform
initialization once the BXXP 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 BXXP
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.
A BXXP peer should support at least 257 concurrently opened channels.
Rose Expires February 20, 2001 [Page 5]
Internet-Draft The BXXP Framework August 2000
2.1 Roles
Although BXXP is peer-to-peer, 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 (or
requestor); similarly, we designate the other BXXP peer as a
server (or responder). 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 February 20, 2001 [Page 6]
Internet-Draft The BXXP Framework August 2000
2.2 Messages and Frames
In BXXP, there are two kinds of messages: requests and responses.
Each message conveys data content. Normally, a message is sent in a
single frame. However, it may be convenient or necesary to segment
the data content of a message into multiple frames. (e.g., if only
part of a message is ready to be sent). When a message is segmented
and sent as several frames, those frames must be sent sequentally,
without any intervening frames from other messages on the same
channel.
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 94 octets spread over 3
lines (each line of the data is terminated with a CRLF pair):
C: REQ . 1 14 94 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
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).
Rose Expires February 20, 2001 [Page 7]
Internet-Draft The BXXP Framework August 2000
2.2.1 Frame Syntax
The ABNF for a message is:
frame = header payload trailer / mapping
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
CR LF [mime] CR LF
more = "." / "*"
; use of 0 for <serial> is reserved for the initial greeting
serial = 0..2147483647
seqno = 0..4294967295
size = 0..2147483647
; use of 0 for <channel> is reserved for BXXP channel management
channel = 0..2147483647
; defaults are:
;
; Content-Type: text/xml
; Content-Transfer-Encoding: binary
;
mime = <MIME Content {entity-headers} from RFC 2045>
status = "+" / "-"
payload = *OCTET
trailer = "END" CR LF
mapping = ;; each transport mapping may define additional frames
Rose Expires February 20, 2001 [Page 8]
Internet-Draft The BXXP Framework August 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 additional
parameter. 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 the
status indicator for the response.
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..2147483647) 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 February 20, 2001 [Page 9]
Internet-Draft The BXXP Framework August 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 cannot be determined or is invalid;
o if the header starts with "REQ", but the channel number cannot be
determined or is invalid;
o if the header starts with "RSP", but the status indicator cannot
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 continuation indicator of the previous frame received on
the same channel was intermediate ("*"), and if its serial number
isn't identical to this frame's serial number;
o if the value of the sequence number doesn't correspond to the
expected value for the associated channel (c.f., Section 2.2.1.2);
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 immediately-previous received frame
for this message is intermediate ("*"), and if the channel
numbers aren't identical;
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 immediately-previous
received frame for this message are not identical; or,
o if the header refers to a mesage for which no other frames has
been received, and if the "entity-headers" portion of the header
is present and poorly-formed; or,
o if the header refers to a mesage for which at least one other
frame has been received, and if the "entity-headers" portion of
the header is present.
If a frame is poorly-formed, then the session is terminated without
generating a response, and it is recommended that a diagnostic entry
be logged.
Rose Expires February 20, 2001 [Page 10]
Internet-Draft The BXXP Framework August 2000
The final frame in a message has a continuation 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
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 "binary".
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.
Finally, note that the use of "entity-headers" is intended to convey
top-level tagging information about the payload. Accordingly, the
headers present should reflect this. Regardless, the size of the
"entity-headers" in a frame header is may not exceed 1024 octets.
Rose Expires February 20, 2001 [Page 11]
Internet-Draft The BXXP Framework August 2000
2.2.1.2 Frame Payload
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. (When a
channel is created, the sequence number associated with the first
payload octet of the first frame is 0.)
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.
When receiving a frame, 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, then the session is terminated without generating a
response, and it is recommended that a diagnostic entry be logged.
Rose Expires February 20, 2001 [Page 12]
Internet-Draft The BXXP Framework August 2000
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 session is
terminated without generating a response, and it is recommended that
a diagnostic entry be logged.
Rose Expires February 20, 2001 [Page 13]
Internet-Draft The BXXP Framework August 2000
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 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) organizes this
information.
When defining the behavior of the profile, the template must specify
how poorly-formed requests are responded to, e.g., with an negative
response containing an error message. However, if a poorly-formed
response is received, then the channel must be closed (c.f., Section
2.3.1.3), unless this occurs on channel 0, in which case the session
is terminated without generating a response, and it is recommended
that a diagnostic entry be logged.
Note that if a profile uses XML to structure its messages, then only
XML's baseline facilities (as described in the XML 1.0
specification[2]) are allowed. Additional XML features (e.g.,
namespaces) are made available only by being referenced and allowed
in a given profile's specification.
In particular this limitation allows use of only the five predefined
general entities references ("&", "<", ">", "'", and
""") and numeric entity references in the messages exchanged.
Finally, because the profile registration template defines the
messages exchanged over a channel, the XML documents exchanged in
each message needn't have either a "XML" declaration (e.g., <?xml
version="1.0" ?>) or a "DOCTYPE" declaration (e.g., <!DOCTYPE ...>).
Of course, all other XML 1.0 instructions (e.g., CDATA blocks,
processing instructions, and so on) are allowed.
Because the "XML" declaration isn't present, the default character
set for XML-based profiles is UTF-8. If another character set is
desired, a "Content-Type" entity-header should be used to specify
the character set in question.
Rose Expires February 20, 2001 [Page 14]
Internet-Draft The BXXP Framework August 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.
Channel management allows each BXXP peer to advertise the profiles
that it supports (using the greeting message), bind an instance of
one of those profiles to a channel (using the start message), and
then later close any channels (using the close message).
Rose Expires February 20, 2001 [Page 15]
Internet-Draft The BXXP Framework August 2000
2.3.1 Message Semantics
2.3.1.1 The Greeting Message
When a BXXP session is established, each BXXP peer signifies its
availability by immediately sending 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 84 +
L:
L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
Note that this example implies that the BXXP peer in the initiating
role waits until the BXXP peer in the listening role sends its
greeting -- this is an artifact of the presentation; in fact, both
BXXP peers send their response messages independently.
The "greeting" element has two optional attributes ("features" and
"localize") and zero or more "profile" elements, one for each
profile supported by the BXXP peer acting in a server role:
o the "features" attribute, if present, contains one or more
feature tokens, each indicating an optional feature of the
channel management profile supported by the BXXP peer;
o the "localize" attribute, if present, contains one or more
language tokens, each identifying a desirable language tag to be
used by the remote BXXP peer when generating textual diagnostics
for the "close" and "error" elements (the tokens are ordered from
most to least desirable); and,
o each "profile" element contained within the "greeting" element
identifies a profile, and unlike the "profile" elements that
occur within the "start" element, the content of each "profile"
element may not contain an optional initialization element.
At present, there are no optional features defined for the channel
management profile.
Rose Expires February 20, 2001 [Page 16]
Internet-Draft The BXXP Framework August 2000
Each token in the value of the "localize" attribute is defined
according to [8]. If not present, the default is "i-default".
Rose Expires February 20, 2001 [Page 17]
Internet-Draft The BXXP Framework August 2000
2.3.1.2 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 14 94 0
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start>
I: END
The "start" element has 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..2147483647) used to identify the channel in future messages;
o the "serverName" attribute, an arbitrary string, indicates the
desired server name for this BXXP session; and,
o each "profile" element contained within the "start" element
identifies a profile, and, optionally, contains an XML element
exchanged during channel creation as its content.
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 for the first successful "start" element
received by a BXXP peer is memorable. (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 "serverName"; 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"
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 successful "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).
Rose Expires February 20, 2001 [Page 18]
Internet-Draft The BXXP Framework August 2000
For example, a successful channel creation might look like this:
I: REQ . 1 14 171 0
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: <profile
I: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
I: </start>
I: END
L: RSP . 1 284 61 +
L:
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: END
Similarly, an unsuccessful channel creation might look like this:
I: REQ . 1 14 94 0
I:
I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start>
I: END
L: RSP . 1 284 89 -
L:
L: <error code='501'>number attribute
L: in <start> element must be odd-valued</error>
L: END
Finally, here's an example in which an initialization element is
exchanged during channel creation:
C: REQ . 1 14 120 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready />
C: </profile>
C: </start>
C: END
S: RSP . 1 84 83 +
S:
S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <proceed />
S: </profile>
S: END
Rose Expires February 20, 2001 [Page 19]
Internet-Draft The BXXP Framework August 2000
2.3.1.3 The Close Message
When a BXXP peer wants to close a channel, it sends a "close"
element on channel 0, e.g.,
I: REQ . 1 185 33 0
I:
I: <close number='1' code='200' />
I: END
The "close" element has a "number" attribute, a "code" attribute, an
optional "xml:lang" attribute, and an optional textual diagnostic as
its content:
o the "number" attribute indicates the channel number;
o the "code" attribute is a three digit reply code meaningful to
programs (c.f., Section 7);
o the "xml:lang" attribute identifies the language that the
element's content is written in (the value is suggested, but not
mandated, by the "localize" attribute of the "greeting" element
sent by the remote BXXP peer); and,
o the textual diagnostic (which may be multiline) is meaningful to
implementers, perhaps administrators, and possibly even users,
but never programs.
Note that if the textual diagnostic is present, then the "xml:lang"
attribute is absent only if the language indicated as the remote
BXXP's first choice is used.
When a BXXP peer receives a "close" element as data on channel 0, it
decides whether it is willing to close the channel. If so, an "ok"
element is returned as data in a positive "RSP" message; otherwise,
an "error" element is returned as data in a negative "RSP" message.
For example, a successful channel close might look like this:
I: REQ . 1 185 33 0
I:
I: <close number='1' code='200' />
I: END
L: RSP . 1 345 8 +
L:
L: <ok />
L: END
Rose Expires February 20, 2001 [Page 20]
Internet-Draft The BXXP Framework August 2000
Similarly, an unsuccessful channel creation might look like this:
I: REQ . 1 185 33 0
I:
I: <close number='1' code='200' />
I: END
L: RSP . 1 345 41 -
L:
L: <error code='550'>still working</error>
L: END
2.3.1.4 The OK Message
When a BXXP peer agrees to close a channel, it returns an "ok"
element as data in a positive "RSP" message.
The "ok" element has no attributes and no content.
Rose Expires February 20, 2001 [Page 21]
Internet-Draft The BXXP Framework August 2000
2.3.1.5 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 14 89 0
I:
I: <start number='2'>
I: <profile uri='http://xml.resource.org/profiles/FOO' />
I: </start>
I: END
L: RSP . 1 284 67 -
L:
L: <error code='550'>all requested profiles are
L: unsupported</error>
L: END
The "error" element has a "code" attribute, an optional "xml:lang"
attribute, and an optional textual diagnostic as its content:
o the "code" attribute is a three digit reply code meaningful to
programs (c.f., Section 7);
o the "xml:lang" attribute identifies the language that the
element's content is written in (the value is suggested, but not
mandated, by the "localize" attribute of the "greeting" element
sent by the remote BXXP peer); and,
o the textual diagnostic (which may be multiline) is meaningful to
implementers, perhaps administrators, and possibly even users,
but never programs.
Note that if the textual diagnostic is present, then the "xml:lang"
attribute is absent only if the language indicated as the remote
BXXP's first choice is used.
In addition, a BXXP peer returns an "error" element whenever:
o it receives a "REQ" message containing poorly-formed request;
o it receives a "REQ" message asking to close a channel and it
declines to do so; or
o a BXXP session is established, the BXXP peer is acting in the
listening role, and that BXXP peer is unavailable (in this case,
the BXXP acting in the listening role does not send a "greeting"
element).
Rose Expires February 20, 2001 [Page 22]
Internet-Draft The BXXP Framework August 2000
In the final case, both BXXP peers terminate the session, and it is
recommended that a diagnostic entry be logged by both BXXP peers.
Rose Expires February 20, 2001 [Page 23]
Internet-Draft The BXXP Framework August 2000
2.4 Session Establishment and Release
When a BXXP session is established, each BXXP peer signifies its
availability by immediately sending 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 84 +
L:
L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
which, for the BXXP peer acting in the listening role, indicates
that it is available.
Alternatively, if the BXXP peer acting in the listening role is
unavailable, it returns a negative response, e.g.,
L: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 22 -
L:
L: <error code='421' />
L: END
I: <close connection>
L: <close connection>
L: <wait for next connection>
and the "greeting" element sent by the BXXP peer acting in the
initiating role is ignored. It is recommended that a diagnostic
entry be logged by both BXXP peers.
Rose Expires February 20, 2001 [Page 24]
Internet-Draft The BXXP Framework August 2000
When a BXXP peer wants to release the BXXP 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 14 0 0
C:
C: END
S: RSP . 1 284 0 +
S:
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 BXXP
session should not be terminated, if possible.
Rose Expires February 20, 2001 [Page 25]
Internet-Draft The BXXP Framework August 2000
2.5 Transport Mappings
The BXXP framework isn't tied to a particular transport protocol.
All transport interactions occur in the context of a session -- a
mapping onto a particular transport service. Accordingly, this memo
defines the requirements that must be satisified by any document
describing how a particular transport service realizes a BXXP
session.
2.5.1 Session Management
A BXXP session is connection-oriented. A mapping document must
define:
o how a BXXP session is established;
o how a BXXP peer is identified as acting in the listening role;
o how a BXXP peer is identified as acting in the initiating role;
o how a BXXP session is released; and,
o how a BXXP session is terminated.
2.5.2 Data Exchange
A BXXP session is message-oriented. A mapping document must define:
o how messages are reliably sent and received;
o how messages on the same channel are received in the same order
as they were sent; and,
o how messages on different channels are sent without ordering
constraint.
Rose Expires February 20, 2001 [Page 26]
Internet-Draft The BXXP Framework August 2000
2.6 Parallelism
2.6.1 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 are received. As a consequence, that BXXP peer must
generate the corresponding "RSP" messages in the same order as the
"REQ" messages are received.
2.6.2 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 are received, there is no ordering
constraint between "RSP" messages for different channels.
2.6.3 Pre-emptive 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, up to 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.
2.6.4 Interference
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 mapping.
Rose Expires February 20, 2001 [Page 27]
Internet-Draft The BXXP Framework August 2000
2.7 Peer-to-Peer Behavior
BXXP is peer-to-peer -- as such both peers must be prepared to
receive both "REQ" and "RSP" frames. Accordingly, 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 peer acting in the initiating role are
unrelated to the serial numbers in "REQ" messages sent by a BXXP
peer acting in the listening role.
For example, these two frames
I: REQ . 1 14 94 0
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
I: </start>
I: END
L: REQ . 1 284 89 0
L:
L: <start number='2'>
L: <profile uri='http://xml.resource.org/profiles/SEP' />
L: </start>
L: END
have no fundamental relationship to each other.
Rose Expires February 20, 2001 [Page 28]
Internet-Draft The BXXP Framework August 2000
3. Transport Security
When a BXXP session is established, 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 one[4].
Other profiles may be defined and deployed on a bilateral basis.
Note that because of their intimate relationship with the tranpsort
service, a given transport security profile tends to be relevant to
a single transort mapping (c.f., Section 2.5).
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 greeting is issued by both
BXXP peers.
Rose Expires February 20, 2001 [Page 29]
Internet-Draft The BXXP Framework August 2000
A BXXP peer 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 84 +
L:
L: <greeting>
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
I: REQ . 1 14 120 0
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <ready />
I: </profile>
I: </start>
I: END
L: RSP . 1 84 83 +
L:
L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <proceed />
L: </profile>
L: END
... successful transport security negotiation ...
L: RSP . 0 0 224 +
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
Rose Expires February 20, 2001 [Page 30]
Internet-Draft The BXXP Framework August 2000
Of course, not all BXXP peers need be as single-minded:
L: <wait for incoming connection>
I: <open connection>
L: RSP . 0 0 284 +
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' />
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
I: REQ . 1 14 120 0
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/TLS'>
I: <ready />
I: </profile>
I: </start>
I: END
L: RSP . 1 284 83 +
L:
L: <profile uri='http://xml.resource.org/profiles/TLS'>
L: <proceed />
L: </profile>
L: END
... failed transport security negotiation ...
L: RSP . 0 0 284 +
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
L: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
L: <profile uri='http://xml.resource.org/profiles/SEP' />
L: <profile uri='http://xml.resource.org/profiles/TLS' />
L: </greeting>
L: END
I: RSP . 0 0 14 +
I:
I: <greeting />
I: END
Rose Expires February 20, 2001 [Page 31]
Internet-Draft The BXXP Framework August 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 14 120 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready />
C: </profile>
C: </start>
C: END
S: RSP . 1 84 83 +
S:
S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <proceed />
S: </profile>
S: END
Rose Expires February 20, 2001 [Page 32]
Internet-Draft The BXXP Framework August 2000
Note that it is possible for the channel to be created, but for the
encapsulated operation to fail, e.g.,
C: REQ . 1 14 135 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/TLS'>
C: <ready version="oops" />
C: </profile>
C: </start>
C: END
S: RSP . 1 84 156 +
S:
S: <profile uri='http://xml.resource.org/profiles/TLS'>
S: <error code='501'>version attribute
S: poorly formed in <ready> element</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 February 20, 2001 [Page 33]
Internet-Draft The BXXP Framework August 2000
3.1.3 Message Semantics
3.1.3.1 The Ready Message
The "ready" element has an optional "version" attribute and no
content:
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 channel 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 has no attributes and no content. 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 February 20, 2001 [Page 34]
Internet-Draft The BXXP Framework August 2000
4. User Authentication
When a BXXP session is established, anonymous access, without trace
information, is provided. Accordingly, user authentication in BXXP
is achieved using an initial tuning profile.
This document defines a family of profiles based on SASL mechanisms:
o each mechanism in the IANA SASL registry[13] has an associated
profile.
Other profiles may be defined and deployed on a bilateral basis.
Whenever a successful authentication occurs, on any channel, the
authenticated identity is updated for all existing and future
channels on the BXXP session; further, no additional attempts at
authentication are allowed.
Note that regardless of transport security and user authentication,
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 February 20, 2001 [Page 35]
Internet-Draft The BXXP Framework August 2000
4.1 The SASL Family of Profiles
Section 6.5 contains the registration for this profile.
Note that SASL may provide both user authentication and transport
security. Once transport security is successfully negotiated for a
BXXP session, then a SASL security layer may not be negotiated;
similarly, once any SASL negotiation is successful, a transport
security profile may not be started or otherwise used.
Section 4 of the SASL specification[5] requires the following
information be supplied by a protocol definition:
service name: "bxxp" will be registered with the IANA as a GSSAPI
service name when this draft is published as an RFC.
initiation sequence: Creating a channel using a BXXP profile
corresponding to a SASL mechanism starts the exchange. An
optional parameter corresponding to the "initial response" sent
by the client is carried within a "blob" element during channel
creation.
exchange sequence: "Challenges" and "responses" are carried in the
"blob" element during data exchange. The "status" attribute of
the "blob" element is used both by a server indicating a
successful completion of the exchange, and a client aborting the
exchange, The server indicates failure of the exchange by sending
an "error" element.
security layer negotiation: Prior to beginning the negotiation of a
security layer, any pending "RSP" messages are generated and
sent; further, once negotiation begins, no traffic is sent on any
other channels until the negotiation completes.
If a security layer is successfully negotiated, it takes effect
immediately following the message that concludes the server's
successful completion reply. When a security layer takes effect,
all channels (including channel 0), are closed on the BXXP
session, and a new greeting is issued by both BXXP peers.
use of the authorization identity: This is made available to all
channels for the duration of the BXXP session.
Rose Expires February 20, 2001 [Page 36]
Internet-Draft The BXXP Framework August 2000
4.1.1 Profile Identification and Initialization
Each SASL mechanism registered with the IANA is identified as:
http://xml.resource.org/profiles/sasl/MECHANISM
where "MECHANISM" is the token assigned to that mechanism by the
IANA.
Note that during channel creation, a BXXP peer may provide multiple
profiles to the remote peer, e.g.,
C: REQ . 1 14 171 0
C:
C: <start number='1'>
C: <profile
C: uri='http://xml.resource.org/profiles/sasl/ANONYMOUS' />
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
C: </start>
C: END
S: RSP . 1 284 61 +
S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP' />
S: END
During channel creation, the corresponding "profile" element in the
BXXP "start" element may provide data in a "blob" element. Note that
it is possible for the channel to be created, but for the
encapsulated operation to fail, e.g.,
C: REQ . 1 14 145 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <blob>AGJsb2NrbWFzdGVy</blob>
C: </profile>
C: </start>
C: END
S: RSP . 1 284 140 +
S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
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 February 20, 2001 [Page 37]
Internet-Draft The BXXP Framework August 2000
Otherwise, the server returns a challenge (or signifies success),
e.g.,
C: REQ . 1 14 145 0
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
C: <blob>AGJsb2NrbWFzdGVy</blob>
C: </profile>
C: </start>
C: END
S: RSP . 1 284 144 +
S:
S: <profile uri='http://xml.resource.org/profiles/sasl/OTP'>
S: <blob>b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=</blob>
S: </profile>
S: END
If a challenge is received, then the client responds and awaits a
reply, e.g.,
C: REQ . 2 0 67 1
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RSP . 2 0 13 +
S:
S: <blob status='complete' />
S: END
Of course, the client could abort the authentication process by
sending "<blob status='abort' />" instead.
Alternatively, the server might reject the response with an error:
e.g.,
C: REQ . 2 0 67 1
C:
C: <blob>d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n</blob>
C: END
S: RSP . 2 0 22 -
S:
S: <error code='535' />
S: END
Rose Expires February 20, 2001 [Page 38]
Internet-Draft The BXXP Framework August 2000
Finally, depending on the SASL mechanism, an initialization element
may be exchanged unidirectionally during channel creation, e.g.,
C: REQ . 1 14 107 0
C:
C: <start number='1'>
C: <profile
C: uri='http://xml.resource.org/profiles/sasl/CRAM-MD5' />
C: </start>
C: END
S: RSP . 1 284 148 +
S:
S: <profile uri='http://xml.resource.org/profiles/sasl/CRAM-MD5'>
S: <blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
</blob>
S: </profile>
S: END
Note that this example implies that the "blob" element in the
server's reply appears on two lines -- this is an artifact of the
presentation; in fact, only one line is used.
4.1.2 Request and Response Messages
Section 6.6 defines the messages that are used for each profile in
the SASL family:
o "REQ" messages carry only the "blob" element as data;
o positive "RSP" messages carry only the "blob" element as data;
and,
o negative "RSP" messages carry only the "error" element as data.
Because many SASL mechanisms exchange binary data, the content of
the "blob" element is always a base64-encoded string.
Rose Expires February 20, 2001 [Page 39]
Internet-Draft The BXXP Framework August 2000
4.1.3 Message Semantics
The "blob" element has an optional "status" attribute, and arbitrary
octets as its content:
o the "status" attribute, if present, takes one of three values:
abort: used by a client to indicate that it is aborting the
authentication process;
complete: used by a server to indicate that the exchange is
complete and successful; or,
continue: used by either a client or server, otherwise.
Finally, note that SASL's EXTERNAL mechanism works with an "external
authentication" service, which is provided by one of:
o a transport security profile, capable of providing authentication
information (e.g., Section 3.1), being active on the connection;
o a network service, capable of providing strong authentication
(e.g., IPSec[11]), underlying the connection; or,
o a locally-defined security service.
For authentication to succeed, two conditions must hold:
o an external authentication service must be active; and,
o if present, the authentication identity must be consistent with
the credentials provided by the external authentication service
(if the authentication identity is empty, then an authorization
identity is automatically derived from the credentials provided
by the external authentication service).
Rose Expires February 20, 2001 [Page 40]
Internet-Draft The BXXP Framework August 2000
5. Profile Registration Template
When a profile is registered, the following information is supplied:
Profile Identification: specify a URI[9] that authoritatively
identifies this profile.
Elements Exchanged during Channel Creation: specify the elements
that may be exchanged during channel creation (If the profile
doesn't exchange XML elements, then initialization information
may not be exchanged during channel creation). Regardless, the
size of any initialization element may not exceed 4K octets.
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
present 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 February 20, 2001 [Page 41]
Internet-Draft The BXXP Framework August 2000
6. Initial Profile Registrations
6.1 BXXP Channel Management
Profile Identification: not applicable
Elements Exchanged during Channel Creation: not applicable
Messages in "REQ" frames: "start" or "close"
Messages in positive "RSP" frames: "greeting", "profile", or "ok"
Messages in negative "RSP" frames: "error"
Message Syntax: c.f., Section 6.2
Message Semantics: c.f., Section 2.3.1
Rose Expires February 20, 2001 [Page 42]
Internet-Draft The BXXP Framework August 2000
6.2 BXXP Channel Management DTD
<!--
DTD for BXXP Channel Management, as of 2000-08-06
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/profiles/BXXP/bxxp.dtd">
%BXXP;
-->
<!--
DTD data types:
entity syntax/reference example
====== ================ =======
a channel number
CHAN 1..2147483647 1
authoritative profile identification
URI c.f., [RFC-2396] http://invisible.net/
one or more feature tokens, seperated by space
FTRS NMTOKENS "magic"
zero or more language tags
LOCS NMTOKENS "en-US"
a language tag
LANG c.f., [RFC-1766] "en", "en-US", etc.
a 3-digit reply code
XYZ [1-5][1-9][1-9] 500
-->
<!ENTITY % CHAN "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % FTRS "NMTOKENS">
Rose Expires February 20, 2001 [Page 43]
Internet-Draft The BXXP Framework August 2000
<!ENTITY % LOCS "NMTOKEN">
<!ENTITY % LANG "NMTOKEN">
<!ENTITY % XYZ "CDATA">
<!--
BXXP messages
role REQ RSP
======= === ===
I and L +: greeting
-: error
I or L start +: profile
-: error
I or L close +: ok
-: error
-->
<!ELEMENT greeting (profile)*>
<!ATTLIST greeting
features %FTRS; #IMPLIED
localize %LOCS; "i-default">
<!ELEMENT start (profile)+>
<!ATTLIST start
number %CHAN; #REQUIRED
serverName CDATA #IMPLIED>
<!-- profile element is empty if contained in a greeting -->
<!ELEMENT profile ANY>
<!ATTLIST profile
uri %URI; #REQUIRED>
<!ELEMENT close (#PCDATA)*>
<!ATTLIST close
number %CHAN; #REQUIRED
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
<!ELEMENT ok EMPTY>
<!ELEMENT error (#PCDATA)*>
<!ATTLIST error
code %XYZ; #REQUIRED
xml:lang %LANG; #IMPLIED>
Rose Expires February 20, 2001 [Page 44]
Internet-Draft The BXXP Framework August 2000
Rose Expires February 20, 2001 [Page 45]
Internet-Draft The BXXP Framework August 2000
6.3 Registration: TLS Transport Security Profile
Profile Identification: http://xml.resource.org/profiles/TLS
Elements Exchanged during Channel Creation: "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 February 20, 2001 [Page 46]
Internet-Draft The BXXP Framework August 2000
6.4 TLS Transport Security Profile DTD
<!--
DTD for the TLS Transport Security Profile, as of 2000-03-03
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/profiles/TLS/tls.dtd">
%TLS;
-->
<!--
TLS messages
role REQ RSP
====== === ===
I or L ready +: proceed
-: error
-->
<!ELEMENT ready EMPTY>
<!ATTLIST ready
version CDATA "1">
<!ELEMENT proceed EMPTY>
Rose Expires February 20, 2001 [Page 47]
Internet-Draft The BXXP Framework August 2000
6.5 Registration: SASL Family of Profiles
Profile Identification:
http://xml.resource.org/profiles/sasl/MECHANISM, where
"MECHANISM" is a token registered with the IANA[14]
Elements Exchanged during Channel Creation: "blob"
Messages in "REQ" frames: "blob"
Messages in positive "RSP" frames: "blob"
Messages in negative "RSP" frames: "error"
Message Syntax: c.f., Section 6.6
Message Semantics: c.f., Section 4.1.3
Rose Expires February 20, 2001 [Page 48]
Internet-Draft The BXXP Framework August 2000
6.6 SASL Family of Profiles DTD
<!--
DTD for the SASL Family of Profiles, as of 2000-04-04
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/profiles/sasl/sasl.dtd">
%SASL;
-->
<!--
SASL messages
role REQ RSP
====== === ===
I or L blob +: blob
-: error
-->
<!ELEMENT blob (#PCDATA)*>
<!ATTLIST blob
xml:space (default|preserve)
"preserve"
status (abort|complete|continue)
"continue">
Rose Expires February 20, 2001 [Page 49]
Internet-Draft The BXXP Framework August 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
554 transaction failed
(e.g., policy violation)
Rose Expires February 20, 2001 [Page 50]
Internet-Draft The BXXP Framework August 2000
8. Security Considerations
The BXXP framing mechanism, per se, provides no protection against
attack; however, judicious use of initial tuning profiles provides
varying degrees of assurance:
1. If one of the profiles from the SASL family is used, refer to
[5]'s Section 9 for a discussion of security considerations.
2. If the TLS transport security profile is used (or if a SASL
security layer is negotiated), then:
1. A man-in-the-middle may remove the security-related profiles
from the BXXP greeting or generate an error response to the
"ready" element of the TLS transport security 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 negotiation. Upon completing the
negotiation, a BXXP peer must discard previously cached
information about the BXXP session.
As different TLS ciphersuites provide varying levels of
security, administrators should carefully choose which
ciphersuites are provisioned.
Rose Expires February 20, 2001 [Page 51]
Internet-Draft The BXXP Framework August 2000
9. IANA Considerations
The IANA registers "bxxp" as a GSSAPI[12] service name.
The IANA maintains a list of:
o BXXP reply codes, c.f., Section 7; and,
o BXXP profiles that are defined in the RFC series.
The IANA makes the registrations specified in Section 6.3 and
Section 6.5. It is recommended that the IANA register these profiles
using the IANA as a URI-prefix.
Rose Expires February 20, 2001 [Page 52]
Internet-Draft The BXXP Framework August 2000
References
[1] Rose, M.T., "On the Design of Application Protocols",
draft-mrose-beep-design-00 (work in progress), July 2000.
[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0", W3C XML, February 1998,
<URL: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., Allen, C., Treese, W., Karlton, P. L., Freier, A.
O. and P. C. Kocher, "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] Rose, M.T., "Mapping the BXXP Framework onto TCP",
draft-ietf-beep-tcpmapping-00 (work in progress), August 2000.
[7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
Sep 1981.
[8] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
October 1998.
[11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[12] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[13] <URL:http://www.isi.edu/in-notes/iana/assignments/sasl-mechanis
ms>
[14] <URL:http://www.iana.org/>
Rose Expires February 20, 2001 [Page 53]
Internet-Draft The BXXP Framework August 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 February 20, 2001 [Page 54]
Internet-Draft The BXXP Framework August 2000
Appendix A. Changes from draft-mrose-bxxp-framework-01
o Channel numbers are now 31-bits wide (instead of 8-bits).
o Peers should support at least 257 concurrently opened channels.
o The consistency rules in Section 2.2.1.1 now mandate that any
MIME entity-headers occur only in the first frame of a message.
o Discussion of the role of the entity-headers is moved to Section
2.2.1.1.
o Section 2.2.2 requires that a BXXP peer close a channel when a
poorly-formed response is received (unless it's channel 0, in
which case the BXXP session is terminated).
o Section 2.2.2 explains that in an XML-based profile, if something
other than UTF-8 is sent, then a "Content-Type:" entity-header
must be present to specify the character set.
o The close (Section 2.3.1.3) and ok (Section 2.3.1.4) messages
were added.
o Both Section 2.3.1.3 and Section 2.3.1.5 clarify that diagnostic
text is not to be interpreted by programs.
o Section 5 limits the the size of an initialization element to 4K
octets.
Rose Expires February 20, 2001 [Page 55]
Internet-Draft The BXXP Framework August 2000
Appendix B. Changes from draft-mrose-bxxp-framework-00
o The IPR notice is changed to be in full conformance with all
provisions of Section 10 of RFC2026.
o At the beginning of Section 2.2 (and in the ABNF in Section
2.2.1) the relationship between messages and frames is clarified.
o A typo involving the final CR LF in the ABNF in Section 2.2.1 is
corrected.
o In Section 2.2.1.1, the "contiguous message" rule replaces the
"transport-specific" assertion (the sixth rule for identifying
poorly-formed frames).
o At the beginning of Section 2.3, an explanation of the
relstionship between profiles and channels (and the greeting and
start messages) is added.
o In Section 2.3.1, the order of the sections for the greeting and
start messages is reversed for readability.
Rose Expires February 20, 2001 [Page 56]
Internet-Draft The BXXP Framework August 2000
Appendix C. Acknowledgements
The author gratefully acknowledges the contributions of: David
Clark, Dave Crocker, Steve Deering, Marco Gazzetta, Danny Goodman,
Steve Harris, Robert Herriot, Ken Hirsch, Ben Laurie, Carl Malamud,
Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob'
Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul
Vixie, Gabe Wachob, and, Daniel Woods. In particular, Dave Crocker
provided helpful suggestions on the nature of segmentation in the
framing protocol.
Rose Expires February 20, 2001 [Page 57]
Internet-Draft The BXXP Framework August 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Rose Expires February 20, 2001 [Page 58]
