idnits 2.17.1
draft-mrose-blocks-protocol-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** The abstract seems to contain references ([12], [13]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 1549 has weird spacing: '... code mea...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 2000) is 8746 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'RFC-2396' on line 1399
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 1405
-- Looks like a reference, but probably isn't: '1-5' on line 1408
-- Looks like a reference, but probably isn't: '1-9' on line 1408
== Unused Reference: '9' is defined on line 1662, but no explicit reference
was found in the text
** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293)
-- Possible downref: Normative reference to a draft: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 2222 (ref. '6') (Obsoleted by RFC
4422, RFC 4752)
** Obsolete normative reference: RFC 1766 (ref. '7') (Obsoleted by RFC
3066, RFC 3282)
** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2401 (ref. '10') (Obsoleted by RFC
4301)
** Obsolete normative reference: RFC 2078 (ref. '11') (Obsoleted by RFC
2743)
-- Possible downref: Non-RFC (?) normative reference: ref. '12'
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
-- Possible downref: Non-RFC (?) normative reference: ref. '16'
-- Possible downref: Non-RFC (?) normative reference: ref. '17'
-- Possible downref: Non-RFC (?) normative reference: ref. '18'
-- Possible downref: Non-RFC (?) normative reference: ref. '19'
-- Possible downref: Non-RFC (?) normative reference: ref. '20'
-- Possible downref: Non-RFC (?) normative reference: ref. '21'
-- Possible downref: Non-RFC (?) normative reference: ref. '22'
-- Possible downref: Non-RFC (?) normative reference: ref. '23'
-- Possible downref: Non-RFC (?) normative reference: ref. '24'
-- Possible downref: Non-RFC (?) normative reference: ref. '25'
-- Possible downref: Non-RFC (?) normative reference: ref. '26'
-- Possible downref: Non-RFC (?) normative reference: ref. '27'
-- Possible downref: Non-RFC (?) normative reference: ref. '28'
-- Possible downref: Non-RFC (?) normative reference: ref. '29'
-- Possible downref: Non-RFC (?) normative reference: ref. '30'
-- Possible downref: Non-RFC (?) normative reference: ref. '31'
-- Possible downref: Non-RFC (?) normative reference: ref. '32'
Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 29 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M.T. Rose
3 Internet-Draft Invisible Worlds, Inc.
4 Expires: October 30, 2000 May 2000
6 The Blocks eXtensible eXchange Protocol Framework
7 draft-mrose-blocks-protocol-04.txt
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026 except that the right to
13 produce derivative works is not granted. (If this document becomes
14 part of an IETF working group activity, then it will be brought into
15 full compliance with Section 10 of RFC2026.)
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as
20 Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other documents
24 at any time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on October 30, 2000.
35 Copyright Notice
37 Copyright (C) The Internet Society (2000). All Rights Reserved.
39 Abstract
41 This memo describes a generic application protocol framework for
42 connection-oriented, asynchronous request/response interactions. The
43 framework permits multiplexing of independent request/response
44 streams over a single transport connection, supporting both textual
45 and binary messages.
47 To subscribe to the Blocks discussion list, send e-mail[12]; there
48 is also a developers' site[13].
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
53 2. The Blocks eXtensible eXchange Protocol . . . . . . . . . 5
54 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 5
55 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 6
56 2.2.1 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 7
57 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 8
58 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 10
59 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 10
60 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 11
61 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 12
62 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 12
63 2.3.1.1 The Start Message . . . . . . . . . . . . . . . . . . . . 12
64 2.3.1.2 The Greeting Message . . . . . . . . . . . . . . . . . . . 15
65 2.3.1.3 The Error Message . . . . . . . . . . . . . . . . . . . . 16
66 2.4 Session Establishment and Release . . . . . . . . . . . . 17
67 2.5 Flow Control . . . . . . . . . . . . . . . . . . . . . . . 19
68 2.5.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . 19
69 2.5.2 Sending REQ or RSP Messages . . . . . . . . . . . . . . . 20
70 2.5.3 Receiving REQ or RSP Messages . . . . . . . . . . . . . . 20
71 2.5.4 Processing SEQ Messages . . . . . . . . . . . . . . . . . 21
72 2.5.5 Use of Flow Control . . . . . . . . . . . . . . . . . . . 22
73 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 23
74 2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 23
75 2.6.2 Between different channels . . . . . . . . . . . . . . . . 23
76 2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 23
77 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 23
78 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 24
79 3. Transport Security . . . . . . . . . . . . . . . . . . . . 25
80 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 28
81 3.1.1 Profile Identification and Initialization . . . . . . . . 28
82 3.1.2 Request and Response Messages . . . . . . . . . . . . . . 29
83 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 30
84 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 30
85 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 30
86 4. User Authentication . . . . . . . . . . . . . . . . . . . 31
87 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 32
88 4.1.1 Profile Identification and Initialization . . . . . . . . 33
89 4.1.2 Request and Response Messages . . . . . . . . . . . . . . 35
90 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 36
91 5. Profile Registration Template . . . . . . . . . . . . . . 37
92 6. Initial Profile Registrations . . . . . . . . . . . . . . 38
93 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 38
94 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 39
95 6.3 Registration: TLS Transport Security Profile . . . . . . . 41
96 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 42
97 6.5 Registration: SASL Family of Profiles . . . . . . . . . . 43
98 6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 44
99 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 45
100 8. Security Considerations . . . . . . . . . . . . . . . . . 46
101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 47
102 References . . . . . . . . . . . . . . . . . . . . . . . . 48
103 Author's Address . . . . . . . . . . . . . . . . . . . . . 49
104 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50
105 Full Copyright Statement . . . . . . . . . . . . . . . . . 51
107 1. Introduction
109 This memo describes a generic application protocol framework for
110 connection-oriented, asynchronous request/response interactions over
111 TCP[1]. Consult [2] for a description of the framework's design
112 principles and a discussion of other transport mappings.
114 At the core of the BXXP framework is a framing mechanism that allows
115 for peer-to-peer exchanges of requests and responses. The framing
116 mechanism permits multiplexing multiple, simultaneous, and
117 independent exchanges over a single transport connection with flow
118 control and segmentation. Requests and responses are either textual
119 (structured using XML[3]) or arbitrary (structured using MIME[4]).
121 Frames are exchanged in the context of a "channel". Each channel has
122 an associated "profile" that defines the syntax and semantics of the
123 messages exchanged. Implicit in the operation of BXXP is the notion
124 of channel management. In addition to defining BXXP's channel
125 management profile, this document defines:
127 o the TLS[5] transport security profile; and,
129 o the SASL[6] family of profiles.
131 Other profiles, such as those used for data exchange, are defined by
132 an application protocol designer. A registration template is
133 provided for this purpose.
135 2. The Blocks eXtensible eXchange Protocol
137 BXXP is a message-oriented protocol. Arbitrary octets are
138 encapsulated within a frame and tagged as either a request or a
139 response. All interactions occur in the context of a channel -- a
140 binding to a well-defined aspect of the application, such as
141 transport security, user authentication, or data exchange.
143 During the creation of a channel, the requestor supplies one or more
144 proposed profiles for that channel. If the responder creates the
145 channel, it selects one of the profiles and returns it in a
146 response; otherwise, it may indicate that none of the profiles are
147 acceptable, and decline creation of the channel.
149 There are no other management capabilities for channels other than
150 creation, as channel usage falls into one of two categories:
152 initial tuning: these are used by profiles that perform
153 initialization once the BXXP session is established (e.g.,
154 negotiating the use of transport security); although several
155 request/response exchanges may be required to perform the
156 initialization, these channels become inactive early in the BXXP
157 session and remain so for the duration.
159 continuous: these are used by profiles that support data exchange;
160 typically, these channels are created after the initial tuning
161 channels have gone quiet.
163 2.1 Roles
165 Although BXXP is a peer-to-peer protocol, it is convenient to label
166 each peer in the context of the role it is performing at a given
167 time:
169 o When a BXXP session is established, we designate the peer that
170 awaits new connections as acting in the listening role, and the
171 other peer, which establishes a connection to the listener, as
172 acting in the initiating role. In the examples which follow,
173 these are referred to as "I:" and "L:", respectively.
175 o We designate a BXXP peer making a request as a client (or
176 requestor); similarly, we designate the other BXXP peer as a
177 server (or responder). In the examples which follow, these are
178 referred to as "C:" and "S:", respectively.
180 Typically, a BXXP peer acting in the server role is also acting in a
181 listening role. However, because BXXP is peer-to-peer in nature, no
182 such requirement exists.
184 2.2 Messages and Frames
186 In BXXP, there are three kinds of messages: requests, responses, and
187 sequence updates.
189 Each request or response conveys data, which is segmented as the
190 payload of one or more frames. Each frame consists of a header, the
191 payload, and a trailer. The header and trailer are each represented
192 using printable ASCII characters and are terminated with a CRLF
193 pair. Between the header and the trailer is the payload, consisting
194 of zero or more octets.
196 For example, here is a request message whose data is contained in a
197 single frame that contains a payload of 94 octets spread over 3
198 lines (each line of the data is terminated with a CRLF pair):
200 C: REQ . 1 14 94 0
201 C:
202 C:
203 C:
204 C:
205 C: END
207 Note that the header is two lines long (the second line is blank
208 signifying a lack of explicit MIME typing information).
210 The sequence update message is used to flow control request and
211 response messages, and is represented using printable ASCII
212 characters terminated by a CRLF pair.
214 For example, here is a sequence update message:
216 C: SEQ 1 0 65535
218 Note that the sequence update message doesn't have a header,
219 payload, or trailer -- it's simply a single line.
221 2.2.1 Message Syntax
223 The ABNF for a message is:
225 message = frame / seq
227 frame = header payload trailer
229 header = req / rsp
231 req = "REQ" SP more SP serial SP seqno SP size SP channel
232 CR LF [[mime] CR LF]
234 rsp = "RSP" SP more SP serial SP seqno SP size SP status
235 CR LF [[mime] CR LF]
237 more = "." / "*"
239 ; use of 0 for is reserved for the initial greeting
240 serial = 0..2147483647
242 seqno = 0..4294967295
244 size = 0..2147483647
246 ; use of 0 for is reserved for BXXP channel management
247 channel = 0..255
249 ; defaults are:
250 ;
251 ; Content-Type: text/xml
252 ; Content-Transfer-Encoding: binary
253 ;
254 mime =
256 status = "+" / "-"
258 payload = *OCTET
260 trailer = "END" CR LF
262 seq = "SEQ" SP channel SP ackno SP window CR LF
264 ackno = seqno
266 window = size
268 2.2.1.1 Frame Header
270 The frame header consists of a three-character keyword (one of:
271 "REQ" or "RSP"), followed by a continuation indicator, a serial
272 number, a sequence number, a payload size, and one additional
273 parameter. A single space character (decimal code 32, " ") separates
274 each component. The header is terminated with a CRLF pair.
276 The "REQ" keyword indicates that this frame is part of a request
277 message. Following the "REQ" keyword, the continuation indicator,
278 the serial number, the sequence number, and the payload size is the
279 channel number for the request.
281 The "RSP" keyword indicates that this frame is part of a response
282 message. Following the "RSP" keyword, the continuation indicator,
283 the serial number, the sequence number, and the payload size is the
284 status indicator for the response.
286 The continuation indicator (one of: decimal code 42, "*", or decimal
287 code 46, ".") specifies whether this is the final frame of the
288 message:
290 intermediate ("*"): at least one other frame follows for the
291 message; or,
293 complete ("."): this frame completes the data for the message.
295 The serial number must be a non-negative integer (in the range
296 0..2147483647) and have a different value than all other outstanding
297 request messages (regardless of channel number).
299 The sequence number must be a non-negative integer (in the range
300 0..4294967295) and specifies the sequence number of the first octet
301 in the payload, for the associated channel.
303 The payload size must be a non-negative integer (in the range
304 0..2147483647) and specifies the exact number of octets in the
305 payload. (This does not include the trailer.)
307 The status indicator (one of: decimal code 43, "+", or decimal code
308 45, "-"), specifies whether the request corresponding to this
309 response was performed:
311 positive ("+"): the request was performed and the response's data
312 contains the corresponding the results; or,
314 negative ("-"): the request could not be performed (either for
315 transient or permanent reasons) and the response's data contains
316 the corresponding error information.
318 There are several rules for identifying poorly-formed frames:
320 o if the header doesn't start with "REQ" or "RSP";
322 o if the header starts with "REQ" or "RSP", but any of the
323 continuation indicator, serial number, sequence number, or
324 payload size cannot be determined or is invalid;
326 o if the header starts with "REQ", but the channel number cannot be
327 determined or is invalid;
329 o if the header starts with "RSP", but the status indicator cannot
330 be determined or is invalid;
332 o if the header starts with "RSP", but the serial number does not
333 refer to an outstanding request message;
335 o if the value of the sequence number doesn't correspond to the
336 expected value for the associated channel (c.f., Section 2.5.3);
338 o if the header starts with "REQ" and refers to a message for which
339 at least one other "REQ" frame has been received, and if the
340 continuation indicator of the immediately-previous received frame
341 for this message is intermediate ("*"), and if the channel
342 numbers aren't identical; or,
344 o if the header starts with "RSP" and refers to a message for which
345 at least one other "RSP" frame has been received, and if the
346 status indicator of this frame and the immediately-previous
347 received frame for this message are not identical.
349 If a frame is poorly-formed, then the connection is closed without
350 generating a response, and it is recommended that a diagnostic entry
351 be logged.
353 The final frame in a message has a continuation indicator of
354 complete ("."), whilst all earlier frames (if any) have a
355 continuation indicator of intermediate ("*"). Note that any of these
356 frames may have an empty payload, e.g.,
358 S: RSP * 1 284 25 +
359 S:
360 S: ...
361 S: ...
362 S: ...
363 S: END
364 S: RSP . 1 309 0 +
365 S:
366 S: END
368 2.2.1.2 Frame Payload
370 The data conveyed with a message is structured according to the
371 rules of MIME. Accordingly, the header of the first frame for a
372 message may include "entity-headers" (c.f., MIME[4]'s Section 3). If
373 none, or only some, of the entity-headers are present:
375 o the default "Content-Type" is "text/xml"; and,
377 o the default "Content-Transfer-Encoding" is "binary".
379 Hence, in the absence of typing information, a message's data is a
380 well-formed XML[3] document.
382 Note that the "entity-headers" (and the empty line that follows) are
383 part of the of the header, not the payload. Thus, they do not
384 contribute to the size of the payload.
386 2.2.1.3 Frame Trailer
388 The frame trailer consists of "END" followed by a CRLF pair.
390 When receiving a frame, if the characters immediately following the
391 payload don't correspond to a trailer, then the connection is closed
392 without generating a response, and it is recommended that a
393 diagnostic entry be logged.
395 2.2.2 Frame Semantics
397 The semantics of the payload of each frame is channel-specific.
398 Accordingly, the profile associated with a channel must define:
400 o the initialization messages, if any, exchanged during channel
401 creation;
403 o the set of request and response messages may be carried in the
404 payload of the channel; and,
406 o the semantics of these messages.
408 A profile registration template (Section 5) organizes this
409 information.
411 Note that if a profile uses XML to structure its messages, then only
412 XML's baseline facilities (as described in the XML 1.0
413 specification[3]) are allowed. Additional XML features (e.g.,
414 namespaces) are made available only by being referenced and allowed
415 in a given profile's specification.
417 In particular this limitation allows use of only the five predefined
418 general entities references ("&", "<", ">", "'", and
419 """) and numeric entity references in the messages exchanged.
421 Finally, because the profile registration template defines the
422 messages exchanged over a channel, the XML documents exchanged in
423 each message needn't have either a "XML" declaration (e.g., ) or a "DOCTYPE" declaration (e.g., ).
425 Of course, all other XML 1.0 instructions (e.g., CDATA blocks,
426 processing instructions, and so on) are allowed.
428 2.3 Channel Management
430 When a BXXP session starts, only channel number 0 is defined, which
431 is used for channel management. Section 6.1 contains the profile
432 registration for BXXP channel management.
434 2.3.1 Message Semantics
436 2.3.1.1 The Start Message
438 When a BXXP peer wants to create a channel, it sends a "start"
439 element as data on channel 0, e.g.,
441 I: REQ . 1 14 94 0
442 I:
443 I:
444 I:
445 I:
446 I: END
448 The "start" element has a "number" attribute, an optional
449 "serverName" attribute, and one or more "profile" elements:
451 o the "number" attribute indicates the channel number (in the range
452 1..255) used to identify the channel in future messages;
454 o the "serverName" attribute, an arbitrary string, indicates the
455 desired server name for this BXXP session; and,
457 o each "profile" element contained within the "start" element
458 identifies a profile, and, optionally, contains an arbitrary XML
459 element exchanged during channel creation as its content.
461 To avoid conflict in assigning channel numbers when requesting the
462 creation of a channel, BXXP peers acting in the initiating role use
463 only positive integers that are odd-numbered; similarly, BXXP peers
464 acting in the listening role use only positive integers that are
465 even-numbered.
467 The "serverName" attribute for the first successful "start" element
468 received by a BXXP peer is memorable. (If the attribute isn't
469 present or it's value is empty, then the sending BXXP peer is
470 requesting a configuration-specific default value.) The BXXP peer
471 decides whether to operate as the indicated "serverName"; if not, an
472 "error" element is returned as data in a negative "RSP" message.
474 When a BXXP peer receives a "start" element as data on channel 0, it
475 examines each of the proposed profiles, and decides whether to use
476 one of them to create the channel. If so, the appropriate "profile"
477 element is returned as data in a positive "RSP" message; otherwise,
478 an "error" element is returned as data in a negative "RSP" message.
480 When creating the channel, the value of the "serverName" attribute
481 from the first successful "start" element is consulted to provide
482 configuration information, e.g., the desired server-side certificate
483 when starting the TLS transport security profile (Section 3.1).
485 For example, a successful channel creation might look like this:
487 I: REQ . 1 14 171 0
488 I:
489 I:
490 I:
491 I:
493 I:
494 I: END
495 L: RSP . 1 284 61 +
496 L:
497 L:
498 L: END
500 Similarly, an unsuccessful channel creation might look like this:
502 I: REQ . 1 14 94 0
503 I:
504 I:
505 I:
506 I:
507 I: END
508 L: RSP . 1 284 89 -
509 L:
510 L: number attribute
511 L: in <start> element must be odd-valued
512 L: END
514 Finally, here's an example in which an initialization element is
515 exchanged during channel creation:
517 C: REQ . 1 14 120 0
518 C:
519 C:
520 C:
521 C:
522 C:
523 C:
524 C: END
525 S: RSP . 1 84 83 +
526 S:
527 S:
528 S:
529 S:
530 S: END
532 2.3.1.2 The Greeting Message
534 When a BXXP session is established, each BXXP peer signifies its
535 availability by immediately sending a positive "RSP" message with a
536 serial number of zero that contains a "greeting" element, e.g.,
538 L:
539 I:
540 L: RSP . 0 0 84 +
541 L:
542 L:
543 L:
544 L:
545 L: END
546 I: RSP . 0 0 14 +
547 I:
548 I:
549 I: END
551 Note that this example implies that the BXXP peer in the initiating
552 role waits until the BXXP peer in the listening role sends its
553 greeting -- this is an artifact of the presentation; in fact, both
554 BXXP peers send their response messages independently.
556 The "greeting" element has two optional attributes ("features" and
557 "localize") and zero or more "profile" elements, one for each
558 profile supported by the BXXP peer acting in a server role:
560 o the "features" attribute, if present, contains one or more
561 feature tokens, each indicating an optional feature of the
562 channel management profile supported by the BXXP peer;
564 o the "localize" attribute, if present, contains one or more
565 language tokens, each identifying a desirable language tag to be
566 used by the remote BXXP peer when generating textual diagnostics
567 for the "error" element (the tokens are ordered from most to
568 least desirable); and,
570 o each "profile" element contained within the "greeting" element
571 identifies a profile, and unlike the "profile" elements that
572 occur within the "start" element, the content of each "profile"
573 element may not contain an optional initialization element.
575 At present, there are no optional features defined for the channel
576 management profile.
578 Each token in the value of the "localize" attribute is defined
579 according to [7]. If not present, the default is "i-default".
581 2.3.1.3 The Error Message
583 When a BXXP peer declines the creation of a channel, it returns an
584 "error" element as data in a negative "RSP" message, e.g.,
586 I: REQ . 1 14 89 0
587 I:
588 I:
589 I:
590 I:
591 I: END
592 L: RSP . 1 284 67 -
593 L:
594 L: all requested profiles are
595 L: unsupported
596 L: END
598 The "error" element has a "code" attribute, an optional "xml:lang"
599 attribute, and an optional textual diagnostic as its content:
601 o the "code" attribute is a three digit reply code meaningful to
602 programs (c.f., Section 7);
604 o the "xml:lang" attribute identifies the language that the
605 element's content is written in (the value is suggested, but not
606 mandated, by the "localize" attribute of the "greeting" element
607 sent by the remote BXXP peer); and,
609 o the textual diagnostic (which may be multiline) is meaningful to
610 implementers, perhaps administrators, and possibly even users.
612 Note that if the textual diagnostic is present, then the "xml:lang"
613 attribute is absent only if the language indicated as the remote
614 BXXP's first choice is used.
616 In addition, a BXXP peer returns an "error" element whenever:
618 o it receives a "REQ" message containing an unexpected element; or,
620 o a BXXP session is established, the BXXP peer is acting in the
621 listening role, and that BXXP peer is unavailable (in this case,
622 the BXXP acting in the listening role does not send a "greeting"
623 element).
625 In the latter case, both BXXP peers close the connection, and it is
626 recommended that a diagnostic entry be logged by both BXXP peers.
628 2.4 Session Establishment and Release
630 When a BXXP session is established, each BXXP peer signifies its
631 availability by immediately sending a positive "RSP" message with a
632 serial number of zero that contains a "greeting" element, e.g.,
634 L:
635 I:
636 L: RSP . 0 0 84 +
637 L:
638 L:
639 L:
640 L:
641 L: END
642 I: RSP . 0 0 14 +
643 I:
644 I:
645 I: END
647 which, for the BXXP peer acting in the listening role, indicates
648 that it is available.
650 Alternatively, if the BXXP peer acting in the listening role is
651 unavailable, it returns a negative response, e.g.,
653 L:
654 I:
655 L: RSP . 0 0 22 -
656 L:
657 L:
658 L: END
659 I:
660 L:
661 L:
663 and the "greeting" element sent by the BXXP peer acting in the
664 initiating role is ignored. It is recommended that a diagnostic
665 entry be logged by both BXXP peers.
667 When a BXXP peer wants to release the BXXP session, it sends a "REQ"
668 message on channel 0 with no data. The other BXXP peer may accept
669 the request (by sending a positive "RSP" message), e.g.,
671 C: REQ . 1 14 0 0
672 C:
673 C: END
674 S: RSP . 1 284 0 +
675 S:
676 S: END
677 C:
678 S:
679 L:
681 If the other BXXP peer sends a negative "RSP" message, then the
682 connection should remain open, if possible.
684 2.5 Flow Control
686 Although the underlying transport service imposes flow control on a
687 per-connection basis, if multiple channels are simultaneously in use
688 on a connection, BXXP must provide a mechanism to avoid starvation
689 and deadlock. To achieve this, BXXP re-introduces mechanisms used by
690 the TCP: sequence numbers and window-based flow control. Briefly,
691 each channel has a sliding window that indicates the number of
692 payload octets that a peer may transmit before receiving further
693 permission.
695 Every payload octet sent in each direction on a channel has an
696 associated sequence number. Numbering of payload octets within a
697 frame is such that the first payload octet is the lowest numbered,
698 and the following payload octets are numbered consecutively.
700 The actual sequence number space is finite, though very large,
701 ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
702 all arithmetic dealing with sequence numbers is performed modulo
703 2**32. This unsigned arithmetic preserves the relationship of
704 sequence numbers as they cycle from 2**32 - 1 to 0 again.
706 2.5.1 Channel Creation
708 When a channel is created, the sequence number associated with the
709 first payload octet of the first frame is 0, and the initial window
710 size for that channel is 4096 octets. After channel creation, a BXXP
711 peer may update the window size by sending a "SEQ" message (Section
712 2.5.4).
714 If a BXXP peer is requested to create a channel and it is unable to
715 allocate at least 4096 octets for that channel, it must decline
716 creation of the channel (Section 2.3.1.3). Similarly, during
717 establishment of the BXXP session, if the BXXP peer acting in the
718 listening role is unable to allocate at least 4096 octets for
719 channel 0, then it must return a negative response (Section 2.4)
720 instead of a greeting.
722 2.5.2 Sending REQ or RSP Messages
724 Before a message is sent, the sending BXXP peer must ensure that the
725 size of the payload is within the window advertised by the receiving
726 BXXP peer. If not, it has three choices:
728 o if the window would allow for at least one payload octet to be
729 sent, the BXXP peer may segment the message and start by sending
730 a smaller frame (up to the size of the remaining window);
732 o the BXXP peer may delay sending the message until the window
733 becomes larger; or,
735 o the BXXP peer may signal to its application that it is unable to
736 send the message, allowing the application to try again at a
737 later time (or perhaps signaling its application when a larger
738 window is available.)
740 The choice is implementation-dependent, although it is recommended
741 that the application using BXXP be given a mechanism for influencing
742 the decision.
744 2.5.3 Receiving REQ or RSP Messages
746 When a frame is received, the sum of its sequence number and payload
747 size, modulo 4294967296 (2**32), gives the expected sequence number
748 associated with the first payload octet of the next frame received.
749 Accordingly, when receiving a frame if the sequence number isn't the
750 expected value for this channel, then the BXXP peers have lost
751 synchronization, then the connection is closed without generating a
752 response, and it is recommended that a diagnostic entry be logged.
754 2.5.4 Processing SEQ Messages
756 As an application accepts responsibility for incoming frames, its
757 BXXP peer should send "SEQ" messages to advertise a new window.
759 The "SEQ" message has three parameters:
761 o a channel number;
763 o an acknowledgement number, that indicates the value of the next
764 sequence number that the sender is expecting to receive on this
765 channel; and,
767 o a window size, that indicates the number of payload octets
768 beginning with the one indicated by the acknowledgement number
769 that the sender is expecting to receive on this channel.
771 A single space character (decimal code 32, " ") separates each
772 component. The "SEQ" message is terminated with a CRLF pair.
774 When a "SEQ" message is received, if any of the channel number,
775 acknowledgement number, or window size cannot be determined or is
776 invalid, then the connection is closed without generating a
777 response, and it is recommended that a diagnostic entry be logged.
779 2.5.5 Use of Flow Control
781 The key to successful use of flow control within BXXP is to balance
782 performance and fairness:
784 o large messages should be segmented into multiple frames (e.g.,
785 the BXXP segment size should be no larger than TCP's negotiated
786 maximum segment size minus some small constant);
788 o frames for different channels with traffic ready to send should
789 be sent in a round-robin fashion; and,
791 o a "SEQ" message should be sent each time a "REQ" or "RSP" message
792 is received (if the transport service presents multiple messages
793 to a BXXP peer simultaneously, then a single consolidating "SEQ"
794 message may be sent).
796 In order to avoid pathological interactions with the transport
797 service, it is important that a BXXP peer advertise windows based on
798 available buffer space, to allow data to be read from the transport
799 service as soon as available. Further, "SEQ" messages for a channel
800 should have higher priority than "REQ" or "RSP messages for that
801 channel.
803 Finally, implementations may wish to provide queue management
804 facilities to the application using BXXP, e.g., channel priorities.
805 In particular, implementations should not allow a given channel to
806 monopolize the underlying transport window (e.g., slow readers
807 should get small windows).
809 2.6 Parallelism
811 2.6.1 Within a single channel
813 A BXXP peer acting in the client role may send multiple "REQ"
814 messages for the same channel without waiting to receive the
815 corresponding "RSP" messages. A BXXP peer acting in the server role
816 must process all "REQ" messages for a given channel in the same
817 order as they are received. As a consequence, that BXXP peer must
818 generate the corresponding "RSP" messages in the same order as the
819 "REQ" messages are received.
821 2.6.2 Between different channels
823 A BXXP peer acting in the client role may send multiple "REQ"
824 messages for different channels without waiting to receive the
825 corresponding "RSP" messages. A BXXP peer acting in the server role
826 may process "REQ" messages received for different channels in
827 parallel. As a consequence, although the "RSP" messages for a given
828 channel are generating according to the order in which the
829 corresponding "REQ" messages are received, there is no ordering
830 constraint between "RSP" messages for different channels.
832 2.6.3 Pre-emptive responses
834 A BXXP peer acting in the server role may send a negative response
835 to a request before it receives the final "REQ" frame of a request.
836 If it does so, that BXXP peer is obliged to ignore any subsequent
837 "REQ" frames for that request, up to and including the final "REQ"
838 frame.
840 If a BXXP peer acting in the client role receives a negative "RSP"
841 frame before it sends the final "REQ" frame for a request, then it
842 is required to send a "REQ" frame with a continuation status of
843 complete (".") and having a zero-length payload.
845 2.6.4 Interference
847 If the processing of a particular frame has sequencing impacts on
848 other frames (either intra-channel or inter-channel), then the
849 corresponding profile should define this behavior, e.g., a profile
850 whose messages alter the underlying transport service.
852 2.7 Peer-to-Peer Behavior
854 BXXP is a peer-to-peer protocol -- as such both peers must be
855 prepared to receive both "REQ" and "RSP" frames. Accordingly, an
856 initiating BXXP peer capable of acting only in the client role must
857 behave gracefully if it receives a "REQ" message. Accordingly, all
858 profiles must provide an appropriate error message for responding to
859 unwanted requests.
861 As a consequence of the peer-to-peer nature of BXXP, serial numbers
862 are unidirectionally-significant. That is, the serial numbers in
863 "REQ" messages sent by a BXXP peer acting in the initiating role are
864 unrelated to the serial numbers in "REQ" messages sent by a BXXP
865 peer acting in the listening role.
867 For example, these two frames
869 I: REQ . 1 14 94 0
870 I:
871 I:
872 I:
873 I:
874 I: END
875 L: REQ . 1 284 89 0
876 L:
877 L:
878 L:
879 L:
880 L: END
882 have no fundamental relationship to each other.
884 3. Transport Security
886 When a BXXP session starts, plaintext transfer, without privacy, is
887 provided. Accordingly, transport security in BXXP is achieved using
888 an initial tuning profile.
890 This document defines one profile:
892 o the TLS transport security profile, based on TLS version one[5].
894 Other profiles may be defined and deployed on a bilateral basis.
896 When a channel associated with transport security begins the
897 underlying negotiation process, all channels (including channel 0),
898 are closed on the BXXP session. Upon completion of the negotiation
899 process, regardless of its outcome, a new greeting is issued by both
900 BXXP peers.
902 A BXXP peer may choose to issue different greetings based on whether
903 privacy is in use, e.g.,
905 L:
906 I:
907 L: RSP . 0 0 84 +
908 L:
909 L:
910 L:
911 L:
912 L: END
913 I: RSP . 0 0 14 +
914 I:
915 I:
916 I: END
917 I: REQ . 1 14 120 0
918 I:
919 I:
920 I:
921 I:
922 I:
923 I:
924 I: END
925 L: RSP . 1 84 83 +
926 L:
927 L:
928 L:
929 L:
930 L: END
932 ... successful transport security negotiation ...
934 L: RSP . 0 0 224 +
935 L:
936 L:
937 L:
939 L:
940 L:
941 L:
942 L: END
943 I: RSP . 0 0 14 +
944 I:
945 I:
946 I: END
948 Of course, not all BXXP peers need be as single-minded:
950 L:
951 I:
952 L: RSP . 0 0 284 +
953 L:
954 L:
955 L:
957 L:
958 L:
959 L:
960 L:
961 L: END
962 I: RSP . 0 0 14 +
963 I:
964 I:
965 I: END
966 I: REQ . 1 14 120 0
967 I:
968 I:
969 I:
970 I:
971 I:
972 I:
973 I: END
974 L: RSP . 1 284 83 +
975 L:
976 L:
977 L:
978 L:
979 L: END
981 ... failed transport security negotiation ...
983 L: RSP . 0 0 284 +
984 L:
985 L:
986 L:
988 L:
989 L:
990 L:
991 L:
992 L: END
993 I: RSP . 0 0 14 +
994 I:
995 I:
996 I: END
998 3.1 The TLS Transport Security Profile
1000 Section 6.3 contains the registration for this profile.
1002 3.1.1 Profile Identification and Initialization
1004 The TLS transport security profile is identified as:
1006 http://xml.resource.org/profiles/TLS
1008 in the BXXP "profile" element during channel creation.
1010 During channel creation, the corresponding "profile" element in the
1011 BXXP "start" element may contain a "ready" element. If channel
1012 creation is successful, then before sending the corresponding "RSP"
1013 message, the BXXP peer processes the "ready" element and includes
1014 the resulting response in the "RSP" message, e.g.,
1016 C: REQ . 1 14 120 0
1017 C:
1018 C:
1019 C:
1020 C:
1021 C:
1022 C:
1023 C: END
1024 S: RSP . 1 84 83 +
1025 S:
1026 S:
1027 S:
1028 S:
1029 S: END
1031 Note that it is possible for the channel to be created, but for the
1032 encapsulated operation to fail, e.g.,
1034 C: REQ . 1 14 135 0
1035 C:
1036 C:
1037 C:
1038 C:
1039 C:
1040 C:
1041 C: END
1042 S: RSP . 1 84 156 +
1043 S:
1044 S:
1045 S: version attribute
1046 S: poorly formed in <ready> element
1047 S:
1048 S: END
1050 In this case, a positive "RSP" message is returned (as channel
1051 creation succeeded), but the encapsulated response contains an
1052 indication as to why the operation failed.
1054 3.1.2 Request and Response Messages
1056 Section 6.4 defines the messages that are used in the TLS transport
1057 security profile:
1059 o "REQ" messages carry only the "ready" element as data;
1061 o positive "RSP" messages carry only the "proceed" element as data;
1062 and,
1064 o negative "RSP" messages carry only the "error" element as data.
1066 3.1.3 Message Semantics
1068 3.1.3.1 The Ready Message
1070 The "ready" element has an optional "version" attribute and no
1071 content:
1073 o the "version" element defines the earliest version of TLS
1074 acceptable for use.
1076 When a BXXP peer sends the "ready" element, it no longer sends any
1077 traffic on any channel until a corresponding "RSP" message is
1078 received; similarly, before processing a "ready" element, the
1079 receiving BXXP peer waits until any pending "RSP" messages have been
1080 generated and sent.
1082 3.1.3.2 The Proceed Message
1084 The "proceed" element has no attributes and no content. It is sent
1085 in response to the "ready" element. When a BXXP peer receives the
1086 "ready" element, it begins the underlying negotiation process for
1087 transport security.
1089 4. User Authentication
1091 When a BXXP session starts, anonymous access, without trace
1092 information, is provided. Accordingly, user authentication in BXXP
1093 is achieved using an initial tuning profile.
1095 This document defines a family of profiles based on SASL mechanisms:
1097 o each mechanism in the IANA SASL registry[14] has an associated
1098 profile.
1100 Other profiles may be defined and deployed on a bilateral basis.
1102 Whenever a successful authentication occurs, on any channel, the
1103 authenticated identity is updated for all existing and future
1104 channels on the BXXP session; further, no additional attempts at
1105 authentication are allowed.
1107 Note that regardless of transport security and user authentication,
1108 authorization is an internal matter for each BXXP peer. As such,
1109 each peer may choose to restrict the operations it allows based on
1110 the authentication credentials provided (i.e., unauthorized
1111 operations are rejected with error code 530).
1113 4.1 The SASL Family of Profiles
1115 Section 6.5 contains the registration for this profile.
1117 Note that SASL may provide both user authentication and transport
1118 security. Once transport security is successfully negotiated for a
1119 BXXP session, then a SASL security layer may not be negotiated;
1120 similarly, once any SASL negotiation is successful, a transport
1121 security profile may not be started or otherwise used.
1123 Section 4 of the SASL specification[6] requires the following
1124 information be supplied by a protocol definition:
1126 service name: "bxxp" will be registered with the IANA as a GSSAPI
1127 service name when this draft is published as an RFC.
1129 initiation sequence: Creating a channel using a BXXP profile
1130 corresponding to a SASL mechanism starts the exchange. An
1131 optional parameter corresponding to the "initial response" sent
1132 by the client is carried within a "blob" element during channel
1133 creation.
1135 exchange sequence: "Challenges" and "responses" are carried in the
1136 "blob" element during data exchange. The "status" attribute of
1137 the "blob" element is used both by a server indicating a
1138 successful completion of the exchange, and a client aborting the
1139 exchange, The server indicates failure of the exchange by sending
1140 an "error" element.
1142 security layer negotiation: Prior to beginning the negotiation of a
1143 security layer, any pending "RSP" messages are generated and
1144 sent; further, once negotiation begins, no traffic is sent on any
1145 other channels until the negotiation completes.
1147 If a security layer is successfully negotiated, it takes effect
1148 immediately following the message that concludes the server's
1149 successful completion reply. When a security layer takes effect,
1150 all channels (including channel 0), are closed on the BXXP
1151 session, and a new greeting is issued by both BXXP peers.
1153 use of the authorization identity: This is made available to all
1154 channels for the duration of the BXXP session.
1156 4.1.1 Profile Identification and Initialization
1158 Each SASL mechanism registered with the IANA is identified as:
1160 http://xml.resource.org/profiles/sasl/MECHANISM
1162 where "MECHANISM" is the token assigned to that mechanism by the
1163 IANA.
1165 Note that during channel creation, a BXXP peer may provide multiple
1166 profiles to the remote peer, e.g.,
1168 C: REQ . 1 14 171 0
1169 C:
1170 C:
1171 C:
1173 C:
1174 C:
1175 C: END
1176 S: RSP . 1 284 61 +
1177 S:
1178 S:
1179 S: END
1181 During channel creation, the corresponding "profile" element in the
1182 BXXP "start" element may provide data in a "blob" element. Note that
1183 it is possible for the channel to be created, but for the
1184 encapsulated operation to fail, e.g.,
1186 C: REQ . 1 14 145 0
1187 C:
1188 C:
1189 C:
1190 C: AGJsb2NrbWFzdGVy
1191 C:
1192 C:
1193 C: END
1194 S: RSP . 1 284 140 +
1195 S:
1196 S:
1197 S: authentication mechanism is
1198 S: too weak
1199 S:
1200 S: END
1202 In this case, a positive "RSP" message is returned (as channel
1203 creation succeeded), but the encapsulated response contains an
1204 indication as to why the operation failed.
1206 Otherwise, the server returns a challenge (or signifies success),
1207 e.g.,
1209 C: REQ . 1 14 145 0
1210 C:
1211 C:
1212 C:
1213 C: AGJsb2NrbWFzdGVy
1214 C:
1215 C:
1216 C: END
1217 S: RSP . 1 284 144 +
1218 S:
1219 S:
1220 S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
1221 S:
1222 S: END
1224 If a challenge is received, then the client responds and awaits a
1225 reply, e.g.,
1227 C: REQ . 2 0 67 1
1228 C:
1229 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1230 C: END
1231 S: RSP . 2 0 13 +
1232 S:
1233 S:
1234 S: END
1236 Of course, the client could abort the authentication process by
1237 sending "" instead.
1239 Alternatively, the server might reject the response with an error:
1240 e.g.,
1242 C: REQ . 2 0 67 1
1243 C:
1244 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1245 C: END
1246 S: RSP . 2 0 22 -
1247 S:
1248 S:
1249 S: END
1251 Finally, depending on the SASL mechanism, an initialization element
1252 may be exchanged unidirectionally during channel creation, e.g.,
1254 C: REQ . 1 14 107 0
1255 C:
1256 C:
1257 C:
1259 C:
1260 C: END
1261 S: RSP . 1 284 148 +
1262 S:
1263 S:
1264 S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
1265
1266 S:
1267 S: END
1269 Note that this example implies that the "blob" element in the
1270 server's reply appears on two lines -- this is an artifact of the
1271 presentation; in fact, only one line is used.
1273 4.1.2 Request and Response Messages
1275 Section 6.6 defines the messages that are used for each profile in
1276 the SASL family:
1278 o "REQ" messages carry only the "blob" element as data;
1280 o positive "RSP" messages carry only the "blob" element as data;
1281 and,
1283 o negative "RSP" messages carry only the "error" element as data.
1285 Because many SASL mechanisms exchange binary data, the content of
1286 the "blob" element is always a base64-encoded string.
1288 4.1.3 Message Semantics
1290 The "blob" element has an optional "status" attribute, and arbitrary
1291 octets as its content:
1293 o the "status" attribute, if present, takes one of three values:
1295 abort: used by a client to indicate that it is aborting the
1296 authentication process;
1298 complete: used by a server to indicate that the exchange is
1299 complete and successful; or,
1301 continue: used by either a client or server, otherwise.
1303 Finally, note that SASL's EXTERNAL mechanism works with an "external
1304 authentication" service, which is provided by one of:
1306 o a transport security profile, capable of providing authentication
1307 information (e.g., Section 3.1), being active on the connection;
1309 o a network service, capable of providing strong authentication
1310 (e.g., IPSec[10]), underlying the connection; or,
1312 o a locally-defined security service.
1314 For authentication to succeed, two conditions must hold:
1316 o an external authentication service must be active; and,
1318 o if present, the authentication identity must be consistent with
1319 the credentials provided by the external authentication service
1320 (if the authentication identity is empty, then an authorization
1321 identity is automatically derived from the credentials provided
1322 by the external authentication service).
1324 5. Profile Registration Template
1326 When a profile is registered, the following information is supplied:
1328 Profile Identification: specify a URI[8] that authoritatively
1329 identifies this profile.
1331 Elements Exchanged during Channel Creation: specify the elements
1332 that may be exchanged during channel creation (note that if the
1333 profile doesn't exchange XML elements, then initialization
1334 information may not be exchanged during channel creation).
1336 Messages in "REQ" frames: specify the datatypes that may be present
1337 in a request.
1339 Messages in positive "RSP" frames: specify the datatypes that may be
1340 present in a positive response.
1342 Messages in negative "RSP" frames: specify the datatypes that may be
1343 present in negative response.
1345 Message Syntax: specify the syntax of the datatypes exchanged by the
1346 profile.
1348 Message Semantics: specify the semantics of the datatypes exchanged
1349 by the profile.
1351 Note that "datatype" refers to any MIME media type, whilst "element"
1352 refers to any well-formed XML document.
1354 6. Initial Profile Registrations
1356 6.1 BXXP Channel Management
1358 Profile Identification: not applicable
1360 Elements Exchanged during Channel Creation: not applicable
1362 Messages in "REQ" frames: "start"
1364 Messages in positive "RSP" frames: "greeting" or "profile"
1366 Messages in negative "RSP" frames: "error"
1368 Message Syntax: c.f., Section 6.2
1370 Message Semantics: c.f., Section 2.3.1
1372 6.2 BXXP Channel Management DTD
1374
1390
1411
1412
1413
1414
1415
1416
1427
1428
1432
1433
1437
1438
1441
1442
1446 6.3 Registration: TLS Transport Security Profile
1448 Profile Identification: http://xml.resource.org/profiles/TLS
1450 Elements Exchanged during Channel Creation: "ready"
1452 Messages in "REQ" frames: "ready"
1454 Messages in positive "RSP" frames: "proceed"
1456 Messages in negative "RSP" frames: "error"
1458 Message Syntax: c.f., Section 6.4
1460 Message Semantics: c.f., Section 3.1.3
1462 6.4 TLS Transport Security Profile DTD
1464
1480
1489
1490
1493
1495 6.5 Registration: SASL Family of Profiles
1497 Profile Identification:
1498 http://xml.resource.org/profiles/sasl/MECHANISM, where
1499 "MECHANISM" is a token registered with the IANA[15]
1501 Elements Exchanged during Channel Creation: "blob"
1503 Messages in "REQ" frames: "blob"
1505 Messages in positive "RSP" frames: "blob"
1507 Messages in negative "RSP" frames: "error"
1509 Message Syntax: c.f., Section 6.6
1511 Message Semantics: c.f., Section 4.1.3
1513 6.6 SASL Family of Profiles DTD
1515
1531
1540
1541
1547 7. Reply Codes
1549 code meaning
1550 ==== =======
1551 421 service not available
1553 450 requested action not taken
1554 (e.g., lock already in use)
1556 451 requested action aborted
1557 (e.g., local error in processing)
1559 454 temporary authentication failure
1561 500 general syntax error
1562 (e.g., poorly-formed XML)
1564 501 syntax error in parameters
1565 (e.g., non-valid XML)
1567 504 parameter not implemented
1569 530 authentication required
1571 534 authentication mechanism insufficient
1572 (e.g., too weak, sequence exhausted, etc.)
1574 535 authentication failure
1576 537 action not authorized for user
1578 538 authentication mechanism requires encryption
1580 550 requested action not taken
1581 (e.g., no requested profiles are acceptable)
1583 553 parameter invalid
1585 554 transaction failed
1586 (e.g., policy violation)
1588 8. Security Considerations
1590 The BXXP framing mechanism, per se, provides no protection against
1591 attack; however, judicious use of initial tuning profiles provides
1592 varying degrees of assurance:
1594 1. If one of the profiles from the SASL family is used, refer to
1595 [6]'s Section 9 for a discussion of security considerations.
1597 2. If the TLS transport security profile is used (or if a SASL
1598 security layer is negotiated), then:
1600 1. A man-in-the-middle may remove the security-related profiles
1601 from the BXXP greeting or generate an error response to the
1602 "ready" element of the TLS transport security profile. A
1603 BXXP peer may be configurable to refuse to proceed without
1604 an acceptable level of privacy.
1606 2. A man-in-the-middle may cause a down-negotiation to the
1607 weakest cipher suite available. A BXXP peer should be
1608 configurable to refuse weak cipher suites.
1610 3. A man-in-the-middle may modify any protocol interactions
1611 prior to a successful negotiation. Upon completing the
1612 negotiation, a BXXP peer must discard previously cached
1613 information about the BXXP session.
1615 As different TLS ciphersuites provide varying levels of
1616 security, administrators should carefully choose which
1617 ciphersuites are provisioned.
1619 9. IANA Considerations
1621 The IANA registers "bxxp" as a GSSAPI[11] service name.
1623 The IANA maintains a list of:
1625 o BXXP reply codes, c.f., Section 7; and,
1627 o BXXP profiles that are defined in the RFC series.
1629 The IANA makes the registrations specified in Section 6.3 and
1630 Section 6.5.
1632 References
1634 [1] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
1635 Sep 1981.
1637 [2] Rose, M.T., "On the Design of Application Protocols",
1638 draft-mrose-blocks-appldesign-02 (work in progress), April
1639 2000.
1641 [3] World Wide Web Consortium, "Extensible Markup Language (XML)
1642 1.0", W3C XML, February 1998,
1643 .
1645 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1646 Extensions (MIME) Part One: Format of Internet Message
1647 Bodies", RFC 2045, November 1996.
1649 [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
1650 2246, January 1999.
1652 [6] Myers, J.G., "Simple Authentication and Security Layer
1653 (SASL)", RFC 2222, October 1997.
1655 [7] Alvestrand, H., "Tags for the Identification of Languages",
1656 RFC 1766, March 1995.
1658 [8] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1659 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1660 1998.
1662 [9] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
1663 October 1998.
1665 [10] Kent, S. and R. Atkinson, "Security Architecture for the
1666 Internet Protocol", RFC 2401, November 1998.
1668 [11] Linn, J., "Generic Security Service Application Program
1669 Interface, Version 2", RFC 2078, January 1997.
1671 [12] mailto:blocks-request@invisible.net
1673 [13] http://mappa.mundi.net/
1675 [14] http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms
1677 [15] http://www.iana.org/
1679 [16] mailto:ddc@lcs.mit.edu
1681 [17] mailto:dcrocker@brandenburg.com
1683 [18] mailto:deering@cisco.com
1685 [19] mailto:gazzetta@invisible.net
1687 [20] mailto:dannyg@dannyg.com
1689 [21] mailto:Robert.Herriot@pahv.xerox.com
1691 [22] mailto:ben@algroup.co.uk
1693 [23] mailto:carl@invisible.net
1695 [24] mailto:michaelm@netsol.com
1697 [25] mailto:pvm@a21.com
1699 [26] mailto:rlmorgan@washington.edu
1701 [27] mailto:fmorton@invisible.net
1703 [28] mailto:dnew@san.rr.com
1705 [29] mailto:chris.newman@innosoft.com
1707 [30] mailto:craig@bbn.com
1709 [31] mailto:paul@vix.com
1711 [32] mailto:woods@invisible.net
1713 Author's Address
1715 Marshall T. Rose
1716 Invisible Worlds, Inc.
1717 1179 North McDowell Boulevard
1718 Petaluma, CA 94954-6559
1719 US
1721 Phone: +1 707 789 3700
1722 EMail: mrose@invisible.net
1723 URI: http://invisible.net/
1725 Appendix A. Acknowledgements
1727 The author gratefully acknowledges the contributions of: David
1728 Clark[16], Dave Crocker[17], Steve Deering[18], Marco Gazzetta[19],
1729 Danny Goodman[20], Robert Herriot[21], Ben Laurie[22], Carl
1730 Malamud[23], Michael Mealling[24], Paul Mockapetris[25], RL 'Bob'
1731 Morgan[26], Frank Morton[27], Darren New[28], Chris Newman[29],
1732 Craig Partridge[30], Paul Vixie[31], and Daniel Woods[32]. In
1733 particular, Dave Crocker provided helpful suggestions on the nature
1734 of flow control and segmentation in the framing protocol.
1736 Full Copyright Statement
1738 Copyright (C) The Internet Society (2000). All Rights Reserved.
1740 This document and translations of it may be copied and furnished to
1741 others, and derivative works that comment on or otherwise explain it
1742 or assist in its implementation may be prepared, copied, published
1743 and distributed, in whole or in part, without restriction of any
1744 kind, provided that the above copyright notice and this paragraph
1745 are included on all such copies and derivative works. However, this
1746 document itself may not be modified in any way, such as by removing
1747 the copyright notice or references to the Internet Society or other
1748 Internet organizations, except as needed for the purpose of
1749 developing Internet standards in which case the procedures for
1750 copyrights defined in the Internet Standards process must be
1751 followed, or as required to translate it into languages other than
1752 English.
1754 The limited permissions granted above are perpetual and will not be
1755 revoked by the Internet Society or its successors or assigns.
1757 This document and the information contained herein is provided on an
1758 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1759 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1760 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1761 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1762 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1764 Invisible Worlds expressly disclaims any and all warranties
1765 regarding this contribution including any warranty that (a) this
1766 contribution does not violate the rights of others, (b) the owners,
1767 if any, of other rights in this contribution have been informed of
1768 the rights and permissions granted to IETF herein, and (c) any
1769 required authorizations from such owners have been obtained. This
1770 document and the information contained herein is provided on an "AS
1771 IS" basis and INVISIBLE WORLDS DISCLAIMS ALL WARRANTIES, EXPRESS OR
1772 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1776 IN NO EVENT WILL INVISIBLE WORLDS BE LIABLE TO ANY OTHER PARTY
1777 INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING
1778 SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF
1779 DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES
1780 WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY
1781 WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT,
1782 WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF
1783 SUCH DAMAGES.
1785 Acknowledgement
1787 Funding for the RFC editor function is currently provided by the
1788 Internet Society.