idnits 2.17.1
draft-ietf-beep-framework-00.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.
== There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 1595 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 (August 22, 2000) is 8640 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 1427
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 1436
-- Looks like a reference, but probably isn't: '1-5' on line 1439
-- Looks like a reference, but probably isn't: '1-9' on line 1439
== Unused Reference: '10' is defined on line 1712, but no explicit
reference was found in the text
== Outdated reference: A later version (-03) exists of
draft-mrose-beep-design-00
** Downref: Normative reference to an Informational draft:
draft-mrose-beep-design (ref. '1')
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 2222 (ref. '5') (Obsoleted by RFC
4422, RFC 4752)
== Outdated reference: A later version (-06) exists of
draft-ietf-beep-tcpmapping-00
** Obsolete normative reference: RFC 793 (ref. '7') (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 1766 (ref. '8') (Obsoleted by RFC
3066, RFC 3282)
** Obsolete normative reference: RFC 2396 (ref. '9') (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2401 (ref. '11') (Obsoleted by RFC
4301)
** Obsolete normative reference: RFC 2078 (ref. '12') (Obsoleted by RFC
2743)
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 9 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: February 20, 2001 August 22, 2000
6 The Blocks eXtensible eXchange Protocol Framework
7 draft-ietf-beep-framework-00
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.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that
16 other groups may also distribute working documents as
17 Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six
20 months and may be updated, replaced, or obsoleted by other documents
21 at any time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt.
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 This Internet-Draft will expire on February 20, 2001.
32 Copyright Notice
34 Copyright (C) The Internet Society (2000). All Rights Reserved.
36 Abstract
38 This memo describes a generic application protocol framework for
39 connection-oriented, asynchronous request/response interactions. The
40 framework permits parallel independent request/response streams
41 within the context of a single application user-identity, supporting
42 both textual and binary messages.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
47 2. The BXXP Framework . . . . . . . . . . . . . . . . . . . . 5
48 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
49 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
50 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
51 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
52 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
53 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
54 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
55 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
56 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
57 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
58 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 18
59 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
60 2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 21
61 2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22
62 2.4 Session Establishment and Release . . . . . . . . . . . . 24
63 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26
64 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26
65 2.5.2 Data Exchange . . . . . . . . . . . . . . . . . . . . . . 26
66 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27
67 2.6.1 Within a single channel . . . . . . . . . . . . . . . . . 27
68 2.6.2 Between different channels . . . . . . . . . . . . . . . . 27
69 2.6.3 Pre-emptive responses . . . . . . . . . . . . . . . . . . 27
70 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27
71 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28
72 3. Transport Security . . . . . . . . . . . . . . . . . . . . 29
73 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32
74 3.1.1 Profile Identification and Initialization . . . . . . . . 32
75 3.1.2 Request and Response Messages . . . . . . . . . . . . . . 33
76 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 34
77 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 34
78 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 34
79 4. User Authentication . . . . . . . . . . . . . . . . . . . 35
80 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36
81 4.1.1 Profile Identification and Initialization . . . . . . . . 37
82 4.1.2 Request and Response Messages . . . . . . . . . . . . . . 39
83 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 40
84 5. Profile Registration Template . . . . . . . . . . . . . . 41
85 6. Initial Profile Registrations . . . . . . . . . . . . . . 42
86 6.1 BXXP Channel Management . . . . . . . . . . . . . . . . . 42
87 6.2 BXXP Channel Management DTD . . . . . . . . . . . . . . . 43
88 6.3 Registration: TLS Transport Security Profile . . . . . . . 46
89 6.4 TLS Transport Security Profile DTD . . . . . . . . . . . . 47
90 6.5 Registration: SASL Family of Profiles . . . . . . . . . . 48
91 6.6 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49
92 7. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50
93 8. Security Considerations . . . . . . . . . . . . . . . . . 51
94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
95 References . . . . . . . . . . . . . . . . . . . . . . . . 53
96 Author's Address . . . . . . . . . . . . . . . . . . . . . 54
97 A. Changes from draft-mrose-bxxp-framework-01 . . . . . . . . 55
98 B. Changes from draft-mrose-bxxp-framework-00 . . . . . . . . 56
99 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57
100 Full Copyright Statement . . . . . . . . . . . . . . . . . 58
102 1. Introduction
104 This memo describes a generic application protocol framework for
105 connection-oriented, asynchronous request/response interactions.
106 Consult [1] for a description of the framework's design principles.
108 At the core of the BXXP framework is a framing mechanism that allows
109 for peer-to-peer exchanges of requests and responses. The framing
110 mechanism permits multiple simultaneous and independent exchanges.
111 Requests and responses are arbitrary MIME[3] content, but are
112 usually textual (structured using XML[2]).
114 Frames are exchanged in the context of a "channel". Each channel has
115 an associated "profile" that defines the syntax and semantics of the
116 messages exchanged. Implicit in the operation of BXXP is the notion
117 of channel management. In addition to defining BXXP's channel
118 management profile, this document defines:
120 o the TLS[4] transport security profile; and,
122 o the SASL[5] family of profiles.
124 Other profiles, such as those used for data exchange, are defined by
125 an application protocol designer. A registration template is
126 provided for this purpose.
128 2. The BXXP Framework
130 The BXXP framework is message-oriented. Arbitrary octets are
131 encapsulated within a frame and tagged as either a request or a
132 response. All interactions occur in the context of a channel -- a
133 binding to a well-defined aspect of the application, such as
134 transport security, user authentication, or data exchange.
136 A BXXP session is mapped onto an underlying transport service. A
137 separate series of documents describe how a particular transport
138 service realizes a BXXP session. For example, [6] describes how a
139 BXXP session is mapped onto a single TCP[7] connection.
141 During the creation of a channel, the requestor supplies one or more
142 proposed profiles for that channel. If the responder creates the
143 channel, it selects one of the profiles and returns it in a
144 response; otherwise, it may indicate that none of the profiles are
145 acceptable, and decline creation of the channel.
147 Channel usage falls into one of two categories:
149 initial tuning: these are used by profiles that perform
150 initialization once the BXXP session is established (e.g.,
151 negotiating the use of transport security); although several
152 request/response exchanges may be required to perform the
153 initialization, these channels become inactive early in the BXXP
154 session and remain so for the duration.
156 continuous: these are used by profiles that support data exchange;
157 typically, these channels are created after the initial tuning
158 channels have gone quiet.
160 A BXXP peer should support at least 257 concurrently opened channels.
162 2.1 Roles
164 Although BXXP is peer-to-peer, it is convenient to label each peer
165 in the context of the role it is performing at a given time:
167 o When a BXXP session is established, we designate the peer that
168 awaits new connections as acting in the listening role, and the
169 other peer, which establishes a connection to the listener, as
170 acting in the initiating role. In the examples which follow,
171 these are referred to as "I:" and "L:", respectively.
173 o We designate a BXXP peer making a request as a client (or
174 requestor); similarly, we designate the other BXXP peer as a
175 server (or responder). In the examples which follow, these are
176 referred to as "C:" and "S:", respectively.
178 Typically, a BXXP peer acting in the server role is also acting in a
179 listening role. However, because BXXP is peer-to-peer in nature, no
180 such requirement exists.
182 2.2 Messages and Frames
184 In BXXP, there are two kinds of messages: requests and responses.
186 Each message conveys data content. Normally, a message is sent in a
187 single frame. However, it may be convenient or necesary to segment
188 the data content of a message into multiple frames. (e.g., if only
189 part of a message is ready to be sent). When a message is segmented
190 and sent as several frames, those frames must be sent sequentally,
191 without any intervening frames from other messages on the same
192 channel.
194 Each frame consists of a header, the payload, and a trailer. The
195 header and trailer are each represented using printable ASCII
196 characters and are terminated with a CRLF pair. Between the header
197 and the trailer is the payload, consisting of zero or more octets.
199 For example, here is a request message whose data is contained in a
200 single frame that contains a payload of 94 octets spread over 3
201 lines (each line of the data is terminated with a CRLF pair):
203 C: REQ . 1 14 94 0
204 C:
205 C:
206 C:
207 C:
208 C: END
210 Note that the header is two lines long (the second line is blank
211 signifying a lack of explicit MIME typing information).
213 2.2.1 Frame Syntax
215 The ABNF for a message is:
217 frame = header payload trailer / mapping
219 header = req / rsp
221 req = "REQ" SP more SP serial SP seqno SP size SP channel
222 CR LF [mime] CR LF
224 rsp = "RSP" SP more SP serial SP seqno SP size SP status
225 CR LF [mime] CR LF
227 more = "." / "*"
229 ; use of 0 for is reserved for the initial greeting
230 serial = 0..2147483647
232 seqno = 0..4294967295
234 size = 0..2147483647
236 ; use of 0 for is reserved for BXXP channel management
237 channel = 0..2147483647
239 ; defaults are:
240 ;
241 ; Content-Type: text/xml
242 ; Content-Transfer-Encoding: binary
243 ;
244 mime =
246 status = "+" / "-"
248 payload = *OCTET
250 trailer = "END" CR LF
252 mapping = ;; each transport mapping may define additional frames
254 2.2.1.1 Frame Header
256 The frame header consists of a three-character keyword (one of:
257 "REQ" or "RSP"), followed by a continuation indicator, a serial
258 number, a sequence number, a payload size, and one additional
259 parameter. A single space character (decimal code 32, " ") separates
260 each component. The header is terminated with a CRLF pair.
262 The "REQ" keyword indicates that this frame is part of a request
263 message. Following the "REQ" keyword, the continuation indicator,
264 the serial number, the sequence number, and the payload size is the
265 channel number for the request.
267 The "RSP" keyword indicates that this frame is part of a response
268 message. Following the "RSP" keyword, the continuation indicator,
269 the serial number, the sequence number, and the payload size is the
270 status indicator for the response.
272 The continuation indicator (one of: decimal code 42, "*", or decimal
273 code 46, ".") specifies whether this is the final frame of the
274 message:
276 intermediate ("*"): at least one other frame follows for the
277 message; or,
279 complete ("."): this frame completes the data for the message.
281 The serial number must be a non-negative integer (in the range
282 0..2147483647) and have a different value than all other outstanding
283 request messages (regardless of channel number).
285 The sequence number must be a non-negative integer (in the range
286 0..4294967295) and specifies the sequence number of the first octet
287 in the payload, for the associated channel.
289 The payload size must be a non-negative integer (in the range
290 0..2147483647) and specifies the exact number of octets in the
291 payload. (This does not include the trailer.)
293 The status indicator (one of: decimal code 43, "+", or decimal code
294 45, "-"), specifies whether the request corresponding to this
295 response was performed:
297 positive ("+"): the request was performed and the response's data
298 contains the corresponding the results; or,
300 negative ("-"): the request could not be performed (either for
301 transient or permanent reasons) and the response's data contains
302 the corresponding error information.
304 There are several rules for identifying poorly-formed frames:
306 o if the header doesn't start with "REQ" or "RSP";
308 o if the header starts with "REQ" or "RSP", but any of the
309 continuation indicator, serial number, sequence number, or
310 payload size cannot be determined or is invalid;
312 o if the header starts with "REQ", but the channel number cannot be
313 determined or is invalid;
315 o if the header starts with "RSP", but the status indicator cannot
316 be determined or is invalid;
318 o if the header starts with "RSP", but the serial number does not
319 refer to an outstanding request message;
321 o if the continuation indicator of the previous frame received on
322 the same channel was intermediate ("*"), and if its serial number
323 isn't identical to this frame's serial number;
325 o if the value of the sequence number doesn't correspond to the
326 expected value for the associated channel (c.f., Section 2.2.1.2);
328 o if the header starts with "REQ" and refers to a message for which
329 at least one other "REQ" frame has been received, and if the
330 continuation indicator of the immediately-previous received frame
331 for this message is intermediate ("*"), and if the channel
332 numbers aren't identical;
334 o if the header starts with "RSP" and refers to a message for which
335 at least one other "RSP" frame has been received, and if the
336 status indicator of this frame and the immediately-previous
337 received frame for this message are not identical; or,
339 o if the header refers to a mesage for which no other frames has
340 been received, and if the "entity-headers" portion of the header
341 is present and poorly-formed; or,
343 o if the header refers to a mesage for which at least one other
344 frame has been received, and if the "entity-headers" portion of
345 the header is present.
347 If a frame is poorly-formed, then the session is terminated without
348 generating a response, and it is recommended that a diagnostic entry
349 be logged.
351 The final frame in a message has a continuation indicator of
352 complete ("."), whilst all earlier frames (if any) have a
353 continuation indicator of intermediate ("*"). Note that any of these
354 frames may have an empty payload, e.g.,
356 S: RSP * 1 284 25 +
357 S:
358 S: ...
359 S: ...
360 S: ...
361 S: END
362 S: RSP . 1 309 0 +
363 S:
364 S: END
366 The data conveyed with a message is structured according to the
367 rules of MIME. Accordingly, the header of the first frame for a
368 message may include "entity-headers" (c.f., MIME[3]'s Section 3). If
369 none, or only some, of the entity-headers are present:
371 o the default "Content-Type" is "text/xml"; and,
373 o the default "Content-Transfer-Encoding" is "binary".
375 Hence, in the absence of typing information, a message's data is a
376 well-formed XML[2] document.
378 Note that the "entity-headers" (and the empty line that follows) are
379 part of the of the header, not the payload. Thus, they do not
380 contribute to the size of the payload.
382 Finally, note that the use of "entity-headers" is intended to convey
383 top-level tagging information about the payload. Accordingly, the
384 headers present should reflect this. Regardless, the size of the
385 "entity-headers" in a frame header is may not exceed 1024 octets.
387 2.2.1.2 Frame Payload
389 Every payload octet sent in each direction on a channel has an
390 associated sequence number. Numbering of payload octets within a
391 frame is such that the first payload octet is the lowest numbered,
392 and the following payload octets are numbered consecutively. (When a
393 channel is created, the sequence number associated with the first
394 payload octet of the first frame is 0.)
396 The actual sequence number space is finite, though very large,
397 ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
398 all arithmetic dealing with sequence numbers is performed modulo
399 2**32. This unsigned arithmetic preserves the relationship of
400 sequence numbers as they cycle from 2**32 - 1 to 0 again.
402 When receiving a frame, the sum of its sequence number and payload
403 size, modulo 4294967296 (2**32), gives the expected sequence number
404 associated with the first payload octet of the next frame received.
405 Accordingly, when receiving a frame if the sequence number isn't the
406 expected value for this channel, then the BXXP peers have lost
407 synchronization, then the session is terminated without generating a
408 response, and it is recommended that a diagnostic entry be logged.
410 2.2.1.3 Frame Trailer
412 The frame trailer consists of "END" followed by a CRLF pair.
414 When receiving a frame, if the characters immediately following the
415 payload don't correspond to a trailer, then the session is
416 terminated without generating a response, and it is recommended that
417 a diagnostic entry be logged.
419 2.2.2 Frame Semantics
421 The semantics of the payload of each frame is channel-specific.
422 Accordingly, the profile associated with a channel must define:
424 o the initialization messages, if any, exchanged during channel
425 creation;
427 o the set of request and response messages may be carried in the
428 payload of the channel; and,
430 o the semantics of these messages.
432 A profile registration template (Section 5) organizes this
433 information.
435 When defining the behavior of the profile, the template must specify
436 how poorly-formed requests are responded to, e.g., with an negative
437 response containing an error message. However, if a poorly-formed
438 response is received, then the channel must be closed (c.f., Section
439 2.3.1.3), unless this occurs on channel 0, in which case the session
440 is terminated without generating a response, and it is recommended
441 that a diagnostic entry be logged.
443 Note that if a profile uses XML to structure its messages, then only
444 XML's baseline facilities (as described in the XML 1.0
445 specification[2]) are allowed. Additional XML features (e.g.,
446 namespaces) are made available only by being referenced and allowed
447 in a given profile's specification.
449 In particular this limitation allows use of only the five predefined
450 general entities references ("&", "<", ">", "'", and
451 """) and numeric entity references in the messages exchanged.
453 Finally, because the profile registration template defines the
454 messages exchanged over a channel, the XML documents exchanged in
455 each message needn't have either a "XML" declaration (e.g., ) or a "DOCTYPE" declaration (e.g., ).
457 Of course, all other XML 1.0 instructions (e.g., CDATA blocks,
458 processing instructions, and so on) are allowed.
460 Because the "XML" declaration isn't present, the default character
461 set for XML-based profiles is UTF-8. If another character set is
462 desired, a "Content-Type" entity-header should be used to specify
463 the character set in question.
465 2.3 Channel Management
467 When a BXXP session starts, only channel number 0 is defined, which
468 is used for channel management. Section 6.1 contains the profile
469 registration for BXXP channel management.
471 Channel management allows each BXXP peer to advertise the profiles
472 that it supports (using the greeting message), bind an instance of
473 one of those profiles to a channel (using the start message), and
474 then later close any channels (using the close message).
476 2.3.1 Message Semantics
478 2.3.1.1 The Greeting Message
480 When a BXXP session is established, each BXXP peer signifies its
481 availability by immediately sending a positive "RSP" message with a
482 serial number of zero that contains a "greeting" element, e.g.,
484 L:
485 I:
486 L: RSP . 0 0 84 +
487 L:
488 L:
489 L:
490 L:
491 L: END
492 I: RSP . 0 0 14 +
493 I:
494 I:
495 I: END
497 Note that this example implies that the BXXP peer in the initiating
498 role waits until the BXXP peer in the listening role sends its
499 greeting -- this is an artifact of the presentation; in fact, both
500 BXXP peers send their response messages independently.
502 The "greeting" element has two optional attributes ("features" and
503 "localize") and zero or more "profile" elements, one for each
504 profile supported by the BXXP peer acting in a server role:
506 o the "features" attribute, if present, contains one or more
507 feature tokens, each indicating an optional feature of the
508 channel management profile supported by the BXXP peer;
510 o the "localize" attribute, if present, contains one or more
511 language tokens, each identifying a desirable language tag to be
512 used by the remote BXXP peer when generating textual diagnostics
513 for the "close" and "error" elements (the tokens are ordered from
514 most to least desirable); and,
516 o each "profile" element contained within the "greeting" element
517 identifies a profile, and unlike the "profile" elements that
518 occur within the "start" element, the content of each "profile"
519 element may not contain an optional initialization element.
521 At present, there are no optional features defined for the channel
522 management profile.
524 Each token in the value of the "localize" attribute is defined
525 according to [8]. If not present, the default is "i-default".
527 2.3.1.2 The Start Message
529 When a BXXP peer wants to create a channel, it sends a "start"
530 element as data on channel 0, e.g.,
532 I: REQ . 1 14 94 0
533 I:
534 I:
535 I:
536 I:
537 I: END
539 The "start" element has a "number" attribute, an optional
540 "serverName" attribute, and one or more "profile" elements:
542 o the "number" attribute indicates the channel number (in the range
543 1..2147483647) used to identify the channel in future messages;
545 o the "serverName" attribute, an arbitrary string, indicates the
546 desired server name for this BXXP session; and,
548 o each "profile" element contained within the "start" element
549 identifies a profile, and, optionally, contains an XML element
550 exchanged during channel creation as its content.
552 To avoid conflict in assigning channel numbers when requesting the
553 creation of a channel, BXXP peers acting in the initiating role use
554 only positive integers that are odd-numbered; similarly, BXXP peers
555 acting in the listening role use only positive integers that are
556 even-numbered.
558 The "serverName" attribute for the first successful "start" element
559 received by a BXXP peer is memorable. (If the attribute isn't
560 present or it's value is empty, then the sending BXXP peer is
561 requesting a configuration-specific default value.) The BXXP peer
562 decides whether to operate as the indicated "serverName"; if not, an
563 "error" element is returned as data in a negative "RSP" message.
565 When a BXXP peer receives a "start" element as data on channel 0, it
566 examines each of the proposed profiles, and decides whether to use
567 one of them to create the channel. If so, the appropriate "profile"
568 element is returned as data in a positive "RSP" message; otherwise,
569 an "error" element is returned as data in a negative "RSP" message.
571 When creating the channel, the value of the "serverName" attribute
572 from the first successful "start" element is consulted to provide
573 configuration information, e.g., the desired server-side certificate
574 when starting the TLS transport security profile (Section 3.1).
576 For example, a successful channel creation might look like this:
578 I: REQ . 1 14 171 0
579 I:
580 I:
581 I:
582 I:
584 I:
585 I: END
586 L: RSP . 1 284 61 +
587 L:
588 L:
589 L: END
591 Similarly, an unsuccessful channel creation might look like this:
593 I: REQ . 1 14 94 0
594 I:
595 I:
596 I:
597 I:
598 I: END
599 L: RSP . 1 284 89 -
600 L:
601 L: number attribute
602 L: in <start> element must be odd-valued
603 L: END
605 Finally, here's an example in which an initialization element is
606 exchanged during channel creation:
608 C: REQ . 1 14 120 0
609 C:
610 C:
611 C:
612 C:
613 C:
614 C:
615 C: END
616 S: RSP . 1 84 83 +
617 S:
618 S:
619 S:
620 S:
621 S: END
623 2.3.1.3 The Close Message
625 When a BXXP peer wants to close a channel, it sends a "close"
626 element on channel 0, e.g.,
628 I: REQ . 1 185 33 0
629 I:
630 I:
631 I: END
633 The "close" element has a "number" attribute, a "code" attribute, an
634 optional "xml:lang" attribute, and an optional textual diagnostic as
635 its content:
637 o the "number" attribute indicates the channel number;
639 o the "code" attribute is a three digit reply code meaningful to
640 programs (c.f., Section 7);
642 o the "xml:lang" attribute identifies the language that the
643 element's content is written in (the value is suggested, but not
644 mandated, by the "localize" attribute of the "greeting" element
645 sent by the remote BXXP peer); and,
647 o the textual diagnostic (which may be multiline) is meaningful to
648 implementers, perhaps administrators, and possibly even users,
649 but never programs.
651 Note that if the textual diagnostic is present, then the "xml:lang"
652 attribute is absent only if the language indicated as the remote
653 BXXP's first choice is used.
655 When a BXXP peer receives a "close" element as data on channel 0, it
656 decides whether it is willing to close the channel. If so, an "ok"
657 element is returned as data in a positive "RSP" message; otherwise,
658 an "error" element is returned as data in a negative "RSP" message.
660 For example, a successful channel close might look like this:
662 I: REQ . 1 185 33 0
663 I:
664 I:
665 I: END
666 L: RSP . 1 345 8 +
667 L:
668 L:
669 L: END
671 Similarly, an unsuccessful channel creation might look like this:
673 I: REQ . 1 185 33 0
674 I:
675 I:
676 I: END
677 L: RSP . 1 345 41 -
678 L:
679 L: still working
680 L: END
682 2.3.1.4 The OK Message
684 When a BXXP peer agrees to close a channel, it returns an "ok"
685 element as data in a positive "RSP" message.
687 The "ok" element has no attributes and no content.
689 2.3.1.5 The Error Message
691 When a BXXP peer declines the creation of a channel, it returns an
692 "error" element as data in a negative "RSP" message, e.g.,
694 I: REQ . 1 14 89 0
695 I:
696 I:
697 I:
698 I:
699 I: END
700 L: RSP . 1 284 67 -
701 L:
702 L: all requested profiles are
703 L: unsupported
704 L: END
706 The "error" element has a "code" attribute, an optional "xml:lang"
707 attribute, and an optional textual diagnostic as its content:
709 o the "code" attribute is a three digit reply code meaningful to
710 programs (c.f., Section 7);
712 o the "xml:lang" attribute identifies the language that the
713 element's content is written in (the value is suggested, but not
714 mandated, by the "localize" attribute of the "greeting" element
715 sent by the remote BXXP peer); and,
717 o the textual diagnostic (which may be multiline) is meaningful to
718 implementers, perhaps administrators, and possibly even users,
719 but never programs.
721 Note that if the textual diagnostic is present, then the "xml:lang"
722 attribute is absent only if the language indicated as the remote
723 BXXP's first choice is used.
725 In addition, a BXXP peer returns an "error" element whenever:
727 o it receives a "REQ" message containing poorly-formed request;
729 o it receives a "REQ" message asking to close a channel and it
730 declines to do so; or
732 o a BXXP session is established, the BXXP peer is acting in the
733 listening role, and that BXXP peer is unavailable (in this case,
734 the BXXP acting in the listening role does not send a "greeting"
735 element).
737 In the final case, both BXXP peers terminate the session, and it is
738 recommended that a diagnostic entry be logged by both BXXP peers.
740 2.4 Session Establishment and Release
742 When a BXXP session is established, each BXXP peer signifies its
743 availability by immediately sending a positive "RSP" message with a
744 serial number of zero that contains a "greeting" element, e.g.,
746 L:
747 I:
748 L: RSP . 0 0 84 +
749 L:
750 L:
751 L:
752 L:
753 L: END
754 I: RSP . 0 0 14 +
755 I:
756 I:
757 I: END
759 which, for the BXXP peer acting in the listening role, indicates
760 that it is available.
762 Alternatively, if the BXXP peer acting in the listening role is
763 unavailable, it returns a negative response, e.g.,
765 L:
766 I:
767 L: RSP . 0 0 22 -
768 L:
769 L:
770 L: END
771 I:
772 L:
773 L:
775 and the "greeting" element sent by the BXXP peer acting in the
776 initiating role is ignored. It is recommended that a diagnostic
777 entry be logged by both BXXP peers.
779 When a BXXP peer wants to release the BXXP session, it sends a "REQ"
780 message on channel 0 with no data. The other BXXP peer may accept
781 the request (by sending a positive "RSP" message), e.g.,
783 C: REQ . 1 14 0 0
784 C:
785 C: END
786 S: RSP . 1 284 0 +
787 S:
788 S: END
789 C:
790 S:
791 L:
793 If the other BXXP peer sends a negative "RSP" message, then the BXXP
794 session should not be terminated, if possible.
796 2.5 Transport Mappings
798 The BXXP framework isn't tied to a particular transport protocol.
800 All transport interactions occur in the context of a session -- a
801 mapping onto a particular transport service. Accordingly, this memo
802 defines the requirements that must be satisified by any document
803 describing how a particular transport service realizes a BXXP
804 session.
806 2.5.1 Session Management
808 A BXXP session is connection-oriented. A mapping document must
809 define:
811 o how a BXXP session is established;
813 o how a BXXP peer is identified as acting in the listening role;
815 o how a BXXP peer is identified as acting in the initiating role;
817 o how a BXXP session is released; and,
819 o how a BXXP session is terminated.
821 2.5.2 Data Exchange
823 A BXXP session is message-oriented. A mapping document must define:
825 o how messages are reliably sent and received;
827 o how messages on the same channel are received in the same order
828 as they were sent; and,
830 o how messages on different channels are sent without ordering
831 constraint.
833 2.6 Parallelism
835 2.6.1 Within a single channel
837 A BXXP peer acting in the client role may send multiple "REQ"
838 messages for the same channel without waiting to receive the
839 corresponding "RSP" messages. A BXXP peer acting in the server role
840 must process all "REQ" messages for a given channel in the same
841 order as they are received. As a consequence, that BXXP peer must
842 generate the corresponding "RSP" messages in the same order as the
843 "REQ" messages are received.
845 2.6.2 Between different channels
847 A BXXP peer acting in the client role may send multiple "REQ"
848 messages for different channels without waiting to receive the
849 corresponding "RSP" messages. A BXXP peer acting in the server role
850 may process "REQ" messages received for different channels in
851 parallel. As a consequence, although the "RSP" messages for a given
852 channel are generating according to the order in which the
853 corresponding "REQ" messages are received, there is no ordering
854 constraint between "RSP" messages for different channels.
856 2.6.3 Pre-emptive responses
858 A BXXP peer acting in the server role may send a negative response
859 to a request before it receives the final "REQ" frame of a request.
860 If it does so, that BXXP peer is obliged to ignore any subsequent
861 "REQ" frames for that request, up to and including the final "REQ"
862 frame.
864 If a BXXP peer acting in the client role receives a negative "RSP"
865 frame before it sends the final "REQ" frame for a request, then it
866 is required to send a "REQ" frame with a continuation status of
867 complete (".") and having a zero-length payload.
869 2.6.4 Interference
871 If the processing of a particular frame has sequencing impacts on
872 other frames (either intra-channel or inter-channel), then the
873 corresponding profile should define this behavior, e.g., a profile
874 whose messages alter the underlying transport mapping.
876 2.7 Peer-to-Peer Behavior
878 BXXP is peer-to-peer -- as such both peers must be prepared to
879 receive both "REQ" and "RSP" frames. Accordingly, an initiating BXXP
880 peer capable of acting only in the client role must behave
881 gracefully if it receives a "REQ" message. Accordingly, all profiles
882 must provide an appropriate error message for responding to unwanted
883 requests.
885 As a consequence of the peer-to-peer nature of BXXP, serial numbers
886 are unidirectionally-significant. That is, the serial numbers in
887 "REQ" messages sent by a BXXP peer acting in the initiating role are
888 unrelated to the serial numbers in "REQ" messages sent by a BXXP
889 peer acting in the listening role.
891 For example, these two frames
893 I: REQ . 1 14 94 0
894 I:
895 I:
896 I:
897 I:
898 I: END
899 L: REQ . 1 284 89 0
900 L:
901 L:
902 L:
903 L:
904 L: END
906 have no fundamental relationship to each other.
908 3. Transport Security
910 When a BXXP session is established, plaintext transfer, without
911 privacy, is provided. Accordingly, transport security in BXXP is
912 achieved using an initial tuning profile.
914 This document defines one profile:
916 o the TLS transport security profile, based on TLS version one[4].
918 Other profiles may be defined and deployed on a bilateral basis.
919 Note that because of their intimate relationship with the tranpsort
920 service, a given transport security profile tends to be relevant to
921 a single transort mapping (c.f., Section 2.5).
923 When a channel associated with transport security begins the
924 underlying negotiation process, all channels (including channel 0),
925 are closed on the BXXP session. Upon completion of the negotiation
926 process, regardless of its outcome, a new greeting is issued by both
927 BXXP peers.
929 A BXXP peer may choose to issue different greetings based on whether
930 privacy is in use, e.g.,
932 L:
933 I:
934 L: RSP . 0 0 84 +
935 L:
936 L:
937 L:
938 L:
939 L: END
940 I: RSP . 0 0 14 +
941 I:
942 I:
943 I: END
944 I: REQ . 1 14 120 0
945 I:
946 I:
947 I:
948 I:
949 I:
950 I:
951 I: END
952 L: RSP . 1 84 83 +
953 L:
954 L:
955 L:
956 L:
957 L: END
959 ... successful transport security negotiation ...
961 L: RSP . 0 0 224 +
962 L:
963 L:
964 L:
966 L:
967 L:
968 L:
969 L: END
970 I: RSP . 0 0 14 +
971 I:
972 I:
973 I: END
975 Of course, not all BXXP peers need be as single-minded:
977 L:
978 I:
979 L: RSP . 0 0 284 +
980 L:
981 L:
982 L:
984 L:
985 L:
986 L:
987 L:
988 L: END
989 I: RSP . 0 0 14 +
990 I:
991 I:
992 I: END
993 I: REQ . 1 14 120 0
994 I:
995 I:
996 I:
997 I:
998 I:
999 I:
1000 I: END
1001 L: RSP . 1 284 83 +
1002 L:
1003 L:
1004 L:
1005 L:
1006 L: END
1008 ... failed transport security negotiation ...
1010 L: RSP . 0 0 284 +
1011 L:
1012 L:
1013 L:
1015 L:
1016 L:
1017 L:
1018 L:
1019 L: END
1020 I: RSP . 0 0 14 +
1021 I:
1022 I:
1023 I: END
1025 3.1 The TLS Transport Security Profile
1027 Section 6.3 contains the registration for this profile.
1029 3.1.1 Profile Identification and Initialization
1031 The TLS transport security profile is identified as:
1033 http://xml.resource.org/profiles/TLS
1035 in the BXXP "profile" element during channel creation.
1037 During channel creation, the corresponding "profile" element in the
1038 BXXP "start" element may contain a "ready" element. If channel
1039 creation is successful, then before sending the corresponding "RSP"
1040 message, the BXXP peer processes the "ready" element and includes
1041 the resulting response in the "RSP" message, e.g.,
1043 C: REQ . 1 14 120 0
1044 C:
1045 C:
1046 C:
1047 C:
1048 C:
1049 C:
1050 C: END
1051 S: RSP . 1 84 83 +
1052 S:
1053 S:
1054 S:
1055 S:
1056 S: END
1058 Note that it is possible for the channel to be created, but for the
1059 encapsulated operation to fail, e.g.,
1061 C: REQ . 1 14 135 0
1062 C:
1063 C:
1064 C:
1065 C:
1066 C:
1067 C:
1068 C: END
1069 S: RSP . 1 84 156 +
1070 S:
1071 S:
1072 S: version attribute
1073 S: poorly formed in <ready> element
1074 S:
1075 S: END
1077 In this case, a positive "RSP" message is returned (as channel
1078 creation succeeded), but the encapsulated response contains an
1079 indication as to why the operation failed.
1081 3.1.2 Request and Response Messages
1083 Section 6.4 defines the messages that are used in the TLS transport
1084 security profile:
1086 o "REQ" messages carry only the "ready" element as data;
1088 o positive "RSP" messages carry only the "proceed" element as data;
1089 and,
1091 o negative "RSP" messages carry only the "error" element as data.
1093 3.1.3 Message Semantics
1095 3.1.3.1 The Ready Message
1097 The "ready" element has an optional "version" attribute and no
1098 content:
1100 o the "version" element defines the earliest version of TLS
1101 acceptable for use.
1103 When a BXXP peer sends the "ready" element, it no longer sends any
1104 traffic on any channel until a corresponding "RSP" message is
1105 received; similarly, before processing a "ready" element, the
1106 receiving BXXP peer waits until any pending "RSP" messages have been
1107 generated and sent.
1109 3.1.3.2 The Proceed Message
1111 The "proceed" element has no attributes and no content. It is sent
1112 in response to the "ready" element. When a BXXP peer receives the
1113 "ready" element, it begins the underlying negotiation process for
1114 transport security.
1116 4. User Authentication
1118 When a BXXP session is established, anonymous access, without trace
1119 information, is provided. Accordingly, user authentication in BXXP
1120 is achieved using an initial tuning profile.
1122 This document defines a family of profiles based on SASL mechanisms:
1124 o each mechanism in the IANA SASL registry[13] has an associated
1125 profile.
1127 Other profiles may be defined and deployed on a bilateral basis.
1129 Whenever a successful authentication occurs, on any channel, the
1130 authenticated identity is updated for all existing and future
1131 channels on the BXXP session; further, no additional attempts at
1132 authentication are allowed.
1134 Note that regardless of transport security and user authentication,
1135 authorization is an internal matter for each BXXP peer. As such,
1136 each peer may choose to restrict the operations it allows based on
1137 the authentication credentials provided (i.e., unauthorized
1138 operations are rejected with error code 530).
1140 4.1 The SASL Family of Profiles
1142 Section 6.5 contains the registration for this profile.
1144 Note that SASL may provide both user authentication and transport
1145 security. Once transport security is successfully negotiated for a
1146 BXXP session, then a SASL security layer may not be negotiated;
1147 similarly, once any SASL negotiation is successful, a transport
1148 security profile may not be started or otherwise used.
1150 Section 4 of the SASL specification[5] requires the following
1151 information be supplied by a protocol definition:
1153 service name: "bxxp" will be registered with the IANA as a GSSAPI
1154 service name when this draft is published as an RFC.
1156 initiation sequence: Creating a channel using a BXXP profile
1157 corresponding to a SASL mechanism starts the exchange. An
1158 optional parameter corresponding to the "initial response" sent
1159 by the client is carried within a "blob" element during channel
1160 creation.
1162 exchange sequence: "Challenges" and "responses" are carried in the
1163 "blob" element during data exchange. The "status" attribute of
1164 the "blob" element is used both by a server indicating a
1165 successful completion of the exchange, and a client aborting the
1166 exchange, The server indicates failure of the exchange by sending
1167 an "error" element.
1169 security layer negotiation: Prior to beginning the negotiation of a
1170 security layer, any pending "RSP" messages are generated and
1171 sent; further, once negotiation begins, no traffic is sent on any
1172 other channels until the negotiation completes.
1174 If a security layer is successfully negotiated, it takes effect
1175 immediately following the message that concludes the server's
1176 successful completion reply. When a security layer takes effect,
1177 all channels (including channel 0), are closed on the BXXP
1178 session, and a new greeting is issued by both BXXP peers.
1180 use of the authorization identity: This is made available to all
1181 channels for the duration of the BXXP session.
1183 4.1.1 Profile Identification and Initialization
1185 Each SASL mechanism registered with the IANA is identified as:
1187 http://xml.resource.org/profiles/sasl/MECHANISM
1189 where "MECHANISM" is the token assigned to that mechanism by the
1190 IANA.
1192 Note that during channel creation, a BXXP peer may provide multiple
1193 profiles to the remote peer, e.g.,
1195 C: REQ . 1 14 171 0
1196 C:
1197 C:
1198 C:
1200 C:
1201 C:
1202 C: END
1203 S: RSP . 1 284 61 +
1204 S:
1205 S:
1206 S: END
1208 During channel creation, the corresponding "profile" element in the
1209 BXXP "start" element may provide data in a "blob" element. Note that
1210 it is possible for the channel to be created, but for the
1211 encapsulated operation to fail, e.g.,
1213 C: REQ . 1 14 145 0
1214 C:
1215 C:
1216 C:
1217 C: AGJsb2NrbWFzdGVy
1218 C:
1219 C:
1220 C: END
1221 S: RSP . 1 284 140 +
1222 S:
1223 S:
1224 S: authentication mechanism is
1225 S: too weak
1226 S:
1227 S: END
1229 In this case, a positive "RSP" message is returned (as channel
1230 creation succeeded), but the encapsulated response contains an
1231 indication as to why the operation failed.
1233 Otherwise, the server returns a challenge (or signifies success),
1234 e.g.,
1236 C: REQ . 1 14 145 0
1237 C:
1238 C:
1239 C:
1240 C: AGJsb2NrbWFzdGVy
1241 C:
1242 C:
1243 C: END
1244 S: RSP . 1 284 144 +
1245 S:
1246 S:
1247 S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
1248 S:
1249 S: END
1251 If a challenge is received, then the client responds and awaits a
1252 reply, e.g.,
1254 C: REQ . 2 0 67 1
1255 C:
1256 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1257 C: END
1258 S: RSP . 2 0 13 +
1259 S:
1260 S:
1261 S: END
1263 Of course, the client could abort the authentication process by
1264 sending "" instead.
1266 Alternatively, the server might reject the response with an error:
1267 e.g.,
1269 C: REQ . 2 0 67 1
1270 C:
1271 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1272 C: END
1273 S: RSP . 2 0 22 -
1274 S:
1275 S:
1276 S: END
1278 Finally, depending on the SASL mechanism, an initialization element
1279 may be exchanged unidirectionally during channel creation, e.g.,
1281 C: REQ . 1 14 107 0
1282 C:
1283 C:
1284 C:
1286 C:
1287 C: END
1288 S: RSP . 1 284 148 +
1289 S:
1290 S:
1291 S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
1292
1293 S:
1294 S: END
1296 Note that this example implies that the "blob" element in the
1297 server's reply appears on two lines -- this is an artifact of the
1298 presentation; in fact, only one line is used.
1300 4.1.2 Request and Response Messages
1302 Section 6.6 defines the messages that are used for each profile in
1303 the SASL family:
1305 o "REQ" messages carry only the "blob" element as data;
1307 o positive "RSP" messages carry only the "blob" element as data;
1308 and,
1310 o negative "RSP" messages carry only the "error" element as data.
1312 Because many SASL mechanisms exchange binary data, the content of
1313 the "blob" element is always a base64-encoded string.
1315 4.1.3 Message Semantics
1317 The "blob" element has an optional "status" attribute, and arbitrary
1318 octets as its content:
1320 o the "status" attribute, if present, takes one of three values:
1322 abort: used by a client to indicate that it is aborting the
1323 authentication process;
1325 complete: used by a server to indicate that the exchange is
1326 complete and successful; or,
1328 continue: used by either a client or server, otherwise.
1330 Finally, note that SASL's EXTERNAL mechanism works with an "external
1331 authentication" service, which is provided by one of:
1333 o a transport security profile, capable of providing authentication
1334 information (e.g., Section 3.1), being active on the connection;
1336 o a network service, capable of providing strong authentication
1337 (e.g., IPSec[11]), underlying the connection; or,
1339 o a locally-defined security service.
1341 For authentication to succeed, two conditions must hold:
1343 o an external authentication service must be active; and,
1345 o if present, the authentication identity must be consistent with
1346 the credentials provided by the external authentication service
1347 (if the authentication identity is empty, then an authorization
1348 identity is automatically derived from the credentials provided
1349 by the external authentication service).
1351 5. Profile Registration Template
1353 When a profile is registered, the following information is supplied:
1355 Profile Identification: specify a URI[9] that authoritatively
1356 identifies this profile.
1358 Elements Exchanged during Channel Creation: specify the elements
1359 that may be exchanged during channel creation (If the profile
1360 doesn't exchange XML elements, then initialization information
1361 may not be exchanged during channel creation). Regardless, the
1362 size of any initialization element may not exceed 4K octets.
1364 Messages in "REQ" frames: specify the datatypes that may be present
1365 in a request.
1367 Messages in positive "RSP" frames: specify the datatypes that may be
1368 present in a positive response.
1370 Messages in negative "RSP" frames: specify the datatypes that may be
1371 present in negative response.
1373 Message Syntax: specify the syntax of the datatypes exchanged by the
1374 profile.
1376 Message Semantics: specify the semantics of the datatypes exchanged
1377 by the profile.
1379 Note that "datatype" refers to any MIME media type, whilst "element"
1380 refers to any well-formed XML document.
1382 6. Initial Profile Registrations
1384 6.1 BXXP Channel Management
1386 Profile Identification: not applicable
1388 Elements Exchanged during Channel Creation: not applicable
1390 Messages in "REQ" frames: "start" or "close"
1392 Messages in positive "RSP" frames: "greeting", "profile", or "ok"
1394 Messages in negative "RSP" frames: "error"
1396 Message Syntax: c.f., Section 6.2
1398 Message Semantics: c.f., Section 2.3.1
1400 6.2 BXXP Channel Management DTD
1402
1418
1442
1443
1444
1445
1446
1447
1449
1464
1465
1469
1470
1474
1475
1476
1479
1480
1485
1487
1488
1492 6.3 Registration: TLS Transport Security Profile
1494 Profile Identification: http://xml.resource.org/profiles/TLS
1496 Elements Exchanged during Channel Creation: "ready"
1498 Messages in "REQ" frames: "ready"
1500 Messages in positive "RSP" frames: "proceed"
1502 Messages in negative "RSP" frames: "error"
1504 Message Syntax: c.f., Section 6.4
1506 Message Semantics: c.f., Section 3.1.3
1508 6.4 TLS Transport Security Profile DTD
1510
1526
1535
1536
1539
1541 6.5 Registration: SASL Family of Profiles
1543 Profile Identification:
1544 http://xml.resource.org/profiles/sasl/MECHANISM, where
1545 "MECHANISM" is a token registered with the IANA[14]
1547 Elements Exchanged during Channel Creation: "blob"
1549 Messages in "REQ" frames: "blob"
1551 Messages in positive "RSP" frames: "blob"
1553 Messages in negative "RSP" frames: "error"
1555 Message Syntax: c.f., Section 6.6
1557 Message Semantics: c.f., Section 4.1.3
1559 6.6 SASL Family of Profiles DTD
1561
1577
1586
1587
1593 7. Reply Codes
1595 code meaning
1596 ==== =======
1597 421 service not available
1599 450 requested action not taken
1600 (e.g., lock already in use)
1602 451 requested action aborted
1603 (e.g., local error in processing)
1605 454 temporary authentication failure
1607 500 general syntax error
1608 (e.g., poorly-formed XML)
1610 501 syntax error in parameters
1611 (e.g., non-valid XML)
1613 504 parameter not implemented
1615 530 authentication required
1617 534 authentication mechanism insufficient
1618 (e.g., too weak, sequence exhausted, etc.)
1620 535 authentication failure
1622 537 action not authorized for user
1624 538 authentication mechanism requires encryption
1626 550 requested action not taken
1627 (e.g., no requested profiles are acceptable)
1629 553 parameter invalid
1631 554 transaction failed
1632 (e.g., policy violation)
1634 8. Security Considerations
1636 The BXXP framing mechanism, per se, provides no protection against
1637 attack; however, judicious use of initial tuning profiles provides
1638 varying degrees of assurance:
1640 1. If one of the profiles from the SASL family is used, refer to
1641 [5]'s Section 9 for a discussion of security considerations.
1643 2. If the TLS transport security profile is used (or if a SASL
1644 security layer is negotiated), then:
1646 1. A man-in-the-middle may remove the security-related profiles
1647 from the BXXP greeting or generate an error response to the
1648 "ready" element of the TLS transport security profile. A
1649 BXXP peer may be configurable to refuse to proceed without
1650 an acceptable level of privacy.
1652 2. A man-in-the-middle may cause a down-negotiation to the
1653 weakest cipher suite available. A BXXP peer should be
1654 configurable to refuse weak cipher suites.
1656 3. A man-in-the-middle may modify any protocol interactions
1657 prior to a successful negotiation. Upon completing the
1658 negotiation, a BXXP peer must discard previously cached
1659 information about the BXXP session.
1661 As different TLS ciphersuites provide varying levels of
1662 security, administrators should carefully choose which
1663 ciphersuites are provisioned.
1665 9. IANA Considerations
1667 The IANA registers "bxxp" as a GSSAPI[12] service name.
1669 The IANA maintains a list of:
1671 o BXXP reply codes, c.f., Section 7; and,
1673 o BXXP profiles that are defined in the RFC series.
1675 The IANA makes the registrations specified in Section 6.3 and
1676 Section 6.5. It is recommended that the IANA register these profiles
1677 using the IANA as a URI-prefix.
1679 References
1681 [1] Rose, M.T., "On the Design of Application Protocols",
1682 draft-mrose-beep-design-00 (work in progress), July 2000.
1684 [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1685 1.0", W3C XML, February 1998,
1686 .
1688 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1689 Extensions (MIME) Part One: Format of Internet Message
1690 Bodies", RFC 2045, November 1996.
1692 [4] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
1693 O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
1694 January 1999.
1696 [5] Myers, J.G., "Simple Authentication and Security Layer
1697 (SASL)", RFC 2222, October 1997.
1699 [6] Rose, M.T., "Mapping the BXXP Framework onto TCP",
1700 draft-ietf-beep-tcpmapping-00 (work in progress), August 2000.
1702 [7] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
1703 Sep 1981.
1705 [8] Alvestrand, H., "Tags for the Identification of Languages",
1706 RFC 1766, March 1995.
1708 [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1709 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1710 1998.
1712 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
1713 October 1998.
1715 [11] Kent, S. and R. Atkinson, "Security Architecture for the
1716 Internet Protocol", RFC 2401, November 1998.
1718 [12] Linn, J., "Generic Security Service Application Program
1719 Interface, Version 2", RFC 2078, January 1997.
1721 [13]
1724 [14]
1726 Author's Address
1728 Marshall T. Rose
1729 Invisible Worlds, Inc.
1730 1179 North McDowell Boulevard
1731 Petaluma, CA 94954-6559
1732 US
1734 Phone: +1 707 789 3700
1735 EMail: mrose@invisible.net
1736 URI: http://invisible.net/
1738 Appendix A. Changes from draft-mrose-bxxp-framework-01
1740 o Channel numbers are now 31-bits wide (instead of 8-bits).
1742 o Peers should support at least 257 concurrently opened channels.
1744 o The consistency rules in Section 2.2.1.1 now mandate that any
1745 MIME entity-headers occur only in the first frame of a message.
1747 o Discussion of the role of the entity-headers is moved to Section
1748 2.2.1.1.
1750 o Section 2.2.2 requires that a BXXP peer close a channel when a
1751 poorly-formed response is received (unless it's channel 0, in
1752 which case the BXXP session is terminated).
1754 o Section 2.2.2 explains that in an XML-based profile, if something
1755 other than UTF-8 is sent, then a "Content-Type:" entity-header
1756 must be present to specify the character set.
1758 o The close (Section 2.3.1.3) and ok (Section 2.3.1.4) messages
1759 were added.
1761 o Both Section 2.3.1.3 and Section 2.3.1.5 clarify that diagnostic
1762 text is not to be interpreted by programs.
1764 o Section 5 limits the the size of an initialization element to 4K
1765 octets.
1767 Appendix B. Changes from draft-mrose-bxxp-framework-00
1769 o The IPR notice is changed to be in full conformance with all
1770 provisions of Section 10 of RFC2026.
1772 o At the beginning of Section 2.2 (and in the ABNF in Section
1773 2.2.1) the relationship between messages and frames is clarified.
1775 o A typo involving the final CR LF in the ABNF in Section 2.2.1 is
1776 corrected.
1778 o In Section 2.2.1.1, the "contiguous message" rule replaces the
1779 "transport-specific" assertion (the sixth rule for identifying
1780 poorly-formed frames).
1782 o At the beginning of Section 2.3, an explanation of the
1783 relstionship between profiles and channels (and the greeting and
1784 start messages) is added.
1786 o In Section 2.3.1, the order of the sections for the greeting and
1787 start messages is reversed for readability.
1789 Appendix C. Acknowledgements
1791 The author gratefully acknowledges the contributions of: David
1792 Clark, Dave Crocker, Steve Deering, Marco Gazzetta, Danny Goodman,
1793 Steve Harris, Robert Herriot, Ken Hirsch, Ben Laurie, Carl Malamud,
1794 Michael Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob'
1795 Morgan, Frank Morton, Darren New, Chris Newman, Joe Touch, Paul
1796 Vixie, Gabe Wachob, and, Daniel Woods. In particular, Dave Crocker
1797 provided helpful suggestions on the nature of segmentation in the
1798 framing protocol.
1800 Full Copyright Statement
1802 Copyright (C) The Internet Society (2000). All Rights Reserved.
1804 This document and translations of it may be copied and furnished to
1805 others, and derivative works that comment on or otherwise explain it
1806 or assist in its implementation may be prepared, copied, published
1807 and distributed, in whole or in part, without restriction of any
1808 kind, provided that the above copyright notice and this paragraph
1809 are included on all such copies and derivative works. However, this
1810 document itself may not be modified in any way, such as by removing
1811 the copyright notice or references to the Internet Society or other
1812 Internet organizations, except as needed for the purpose of
1813 developing Internet standards in which case the procedures for
1814 copyrights defined in the Internet Standards process must be
1815 followed, or as required to translate it into languages other than
1816 English.
1818 The limited permissions granted above are perpetual and will not be
1819 revoked by the Internet Society or its successors or assigns.
1821 This document and the information contained herein is provided on an
1822 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1823 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1824 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1825 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1826 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1828 Acknowledgement
1830 Funding for the RFC editor function is currently provided by the
1831 Internet Society.