idnits 2.17.1
draft-ietf-beep-framework-08.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 an Authors' Addresses Section.
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
== There are 2 instances 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 1631 has weird spacing: '...reeting err...'
== Line 1722 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 (November 13, 2000) is 8564 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 1605
-- Looks like a reference, but probably isn't: 'RFC-1766' on line 1614
-- Looks like a reference, but probably isn't: '1-5' on line 1617
-- Looks like a reference, but probably isn't: '0-9' on line 1617
== Unused Reference: '11' is defined on line 1833, but no explicit
reference was found in the text
== Unused Reference: '13' is defined on line 1839, but no explicit
reference was found in the text
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 2222 (ref. '4') (Obsoleted by RFC
4422, RFC 4752)
== Outdated reference: A later version (-06) exists of
draft-ietf-beep-tcpmapping-04
** Obsolete normative reference: RFC 793 (ref. '6') (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234)
** Obsolete normative reference: RFC 1766 (ref. '9') (Obsoleted by RFC
3066, RFC 3282)
** Obsolete normative reference: RFC 2396 (ref. '10') (Obsoleted by RFC
3986)
** Obsolete normative reference: RFC 2401 (ref. '12') (Obsoleted by RFC
4301)
** Obsolete normative reference: RFC 2279 (ref. '13') (Obsoleted by RFC
3629)
** Obsolete normative reference: RFC 2078 (ref. '14') (Obsoleted by RFC
2743)
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
-- Possible downref: Non-RFC (?) normative reference: ref. '16'
Summary: 12 errors (**), 0 flaws (~~), 8 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: May 14, 2001 November 13, 2000
6 The Blocks Extensible Exchange Protocol Framework
7 draft-ietf-beep-framework-08
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 May 14, 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 interactions. The framework
40 permits simultaneous and independent exchanges within the context of
41 a single application user-identity, supporting both textual and
42 binary messages.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
47 2. The BEEP Framework . . . . . . . . . . . . . . . . . . . . 5
48 2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 6
49 2.1.1 Exchange Styles . . . . . . . . . . . . . . . . . . . . . 6
50 2.2 Messages and Frames . . . . . . . . . . . . . . . . . . . 7
51 2.2.1 Frame Syntax . . . . . . . . . . . . . . . . . . . . . . . 8
52 2.2.1.1 Frame Header . . . . . . . . . . . . . . . . . . . . . . . 9
53 2.2.1.2 Frame Payload . . . . . . . . . . . . . . . . . . . . . . 12
54 2.2.1.3 Frame Trailer . . . . . . . . . . . . . . . . . . . . . . 13
55 2.2.2 Frame Semantics . . . . . . . . . . . . . . . . . . . . . 14
56 2.2.2.1 Poorly-formed Messages . . . . . . . . . . . . . . . . . . 14
57 2.3 Channel Management . . . . . . . . . . . . . . . . . . . . 15
58 2.3.1 Message Semantics . . . . . . . . . . . . . . . . . . . . 16
59 2.3.1.1 The Greeting Message . . . . . . . . . . . . . . . . . . . 16
60 2.3.1.2 The Start Message . . . . . . . . . . . . . . . . . . . . 17
61 2.3.1.3 The Close Message . . . . . . . . . . . . . . . . . . . . 20
62 2.3.1.4 The OK Message . . . . . . . . . . . . . . . . . . . . . . 22
63 2.3.1.5 The Error Message . . . . . . . . . . . . . . . . . . . . 22
64 2.4 Session Establishment and Release . . . . . . . . . . . . 24
65 2.5 Transport Mappings . . . . . . . . . . . . . . . . . . . . 26
66 2.5.1 Session Management . . . . . . . . . . . . . . . . . . . . 26
67 2.5.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . 26
68 2.6 Parallelism . . . . . . . . . . . . . . . . . . . . . . . 27
69 2.6.1 Within a Single Channel . . . . . . . . . . . . . . . . . 27
70 2.6.2 Between Different Channels . . . . . . . . . . . . . . . . 27
71 2.6.3 Pre-emptive Replies . . . . . . . . . . . . . . . . . . . 27
72 2.6.4 Interference . . . . . . . . . . . . . . . . . . . . . . . 27
73 2.7 Peer-to-Peer Behavior . . . . . . . . . . . . . . . . . . 28
74 3. Transport Security . . . . . . . . . . . . . . . . . . . . 29
75 3.1 The TLS Transport Security Profile . . . . . . . . . . . . 32
76 3.1.1 Profile Identification and Initialization . . . . . . . . 32
77 3.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 33
78 3.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 34
79 3.1.3.1 The Ready Message . . . . . . . . . . . . . . . . . . . . 34
80 3.1.3.2 The Proceed Message . . . . . . . . . . . . . . . . . . . 34
81 4. User Authentication . . . . . . . . . . . . . . . . . . . 35
82 4.1 The SASL Family of Profiles . . . . . . . . . . . . . . . 36
83 4.1.1 Profile Identification and Initialization . . . . . . . . 37
84 4.1.2 Message Syntax . . . . . . . . . . . . . . . . . . . . . . 40
85 4.1.3 Message Semantics . . . . . . . . . . . . . . . . . . . . 41
86 5. Registration Templates . . . . . . . . . . . . . . . . . . 42
87 5.1 Profile Registration Template . . . . . . . . . . . . . . 42
88 5.2 Feature Registration Template . . . . . . . . . . . . . . 42
89 6. Initial Registrations . . . . . . . . . . . . . . . . . . 43
90 6.1 Registration: BEEP Channel Management . . . . . . . . . . 43
91 6.2 Registration: TLS Transport Security Profile . . . . . . . 43
92 6.3 Registration: SASL Family of Profiles . . . . . . . . . . 44
93 6.4 Registration: application/beep+xml . . . . . . . . . . . . 45
94 7. DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
95 7.1 BEEP Channel Management DTD . . . . . . . . . . . . . . . 46
96 7.2 TLS Transport Security Profile DTD . . . . . . . . . . . . 48
97 7.3 SASL Family of Profiles DTD . . . . . . . . . . . . . . . 49
98 8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . 50
99 9. Security Considerations . . . . . . . . . . . . . . . . . 51
100 References . . . . . . . . . . . . . . . . . . . . . . . . 52
101 Author's Address . . . . . . . . . . . . . . . . . . . . . 53
102 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 54
103 B. IANA Considerations . . . . . . . . . . . . . . . . . . . 55
104 Full Copyright Statement . . . . . . . . . . . . . . . . . 56
106 1. Introduction
108 This memo describes a generic application protocol framework for
109 connection-oriented, asynchronous interactions.
111 At the core of the BEEP framework is a framing mechanism that
112 permits simultaneous and independent exchanges of messages between
113 peers. Messages are arbitrary MIME[1] content, but are usually
114 textual (structured using XML[2]).
116 All exchanges occur in the context of a channel -- a binding to a
117 well-defined aspect of the application, such as transport security,
118 user authentication, or data exchange.
120 Each channel has an associated "profile" that defines the syntax and
121 semantics of the messages exchanged. Implicit in the operation of
122 BEEP is the notion of channel management. In addition to defining
123 BEEP's channel management profile, this document defines:
125 o the TLS[3] transport security profile; and,
127 o the SASL[4] family of profiles.
129 Other profiles, such as those used for data exchange, are defined by
130 an application protocol designer.
132 2. The BEEP Framework
134 A BEEP session is mapped onto an underlying transport service. A
135 separate series of documents describe how a particular transport
136 service realizes a BEEP session. For example, [5] describes how a
137 BEEP session is mapped onto a single TCP[6] connection.
139 When a session is established, each BEEP peer advertises the profile
140 it supports. Later on, during the creation of a channel, the client
141 supplies one or more proposed profiles for that channel. If the
142 server creates the channel, it selects one of the profiles and sends
143 it in a reply; otherwise, it may indicate that none of the profiles
144 are acceptable, and decline creation of the channel.
146 Channel usage falls into one of two categories:
148 initial tuning: these are used by profiles that perform
149 initialization once the BEEP session is established (e.g.,
150 negotiating the use of transport security); although several
151 exchanges may be required to perform the initialization, these
152 channels become inactive early in the BEEP session and remain so
153 for the duration.
155 continuous: these are used by profiles that support data exchange;
156 typically, these channels are created after the initial tuning
157 channels have gone quiet.
159 2.1 Roles
161 Although BEEP is peer-to-peer, it is convenient to label each peer
162 in the context of the role it is performing at a given time:
164 o When a BEEP session is established, the peer that awaits new
165 connections is acting in the listening role, and the other peer,
166 which establishes a connection to the listener, is acting in the
167 initiating role. In the examples which follow, these are referred
168 to as "L:" and "I:", respectively.
170 o A BEEP peer starting an exchange is termed the client; similarly,
171 the other BEEP peer is termed the server. In the examples which
172 follow, these are referred to as "C:" and "S:", respectively.
174 Typically, a BEEP peer acting in the server role is also acting in a
175 listening role. However, because BEEP is peer-to-peer in nature, no
176 such requirement exists.
178 2.1.1 Exchange Styles
180 BEEP allows three styles of exchange:
182 MSG/RPY: the client sends a "MSG" message asking the server to
183 perform some task, the server performs the task and replies with
184 a "RPY" message (termed a positive reply).
186 MSG/ERR: the client sends a "MSG" message, the server does not
187 perform any task and replies with an "ERR" message (termed a
188 negative reply).
190 MSG/ANS: the client sends a "MSG" message, the server, during the
191 course of performing some task, replies with zero or more "ANS"
192 messages, and, upon completion of the task, sends a "NUL"
193 message, which signifies the end of the reply.
195 The first two styles are termed one-to-one exchanges, whilst the
196 third style is termed a one-to-many exchange.
198 2.2 Messages and Frames
200 A message is structured according to the rules of MIME. Accordingly,
201 each message may begin with "entity-headers" (c.f., MIME[1]'s
202 Section 3). If none, or only some, of the "entity-headers" are
203 present:
205 o the default "Content-Type" is "application/octet-stream"; and,
207 o the default "Content-Transfer-Encoding" is "binary".
209 Normally, a message is sent in a single frame. However, it may be
210 convenient or necesary to segment a message into multiple frames
211 (e.g., if only part of a message is ready to be sent).
213 Each frame consists of a header, the payload, and a trailer. The
214 header and trailer are each represented using printable ASCII
215 characters and are terminated with a CRLF pair. Between the header
216 and the trailer is the payload, consisting of zero or more octets.
218 For example, here is a message contained in a single frame that
219 contains a payload of 119 octets spread over 5 lines (each line is
220 terminated with a CRLF pair):
222 C: MSG 0 1 . 52 132
223 C: Content-Type: application/beep+xml
224 C:
225 C:
226 C:
227 C:
228 C: END
230 In this example, note that the entire message is represented in a
231 single frame.
233 2.2.1 Frame Syntax
235 The ABNF[7] for a frame is:
237 frame = data / mapping
239 data = header payload trailer
241 header = msg / rpy / err / ans / nul
243 msg = "MSG" SP common CR LF
244 rpy = "RPY" SP common CR LF
245 ans = "ANS" SP common SP ansno CR LF
246 err = "ERR" SP common CR LF
247 nul = "NUL" SP common CR LF
249 common = channel SP msgno SP more SP seqno SP size
250 channel = 0..2147483647
251 msgno = 0..2147483647
252 more = "." / "*"
253 seqno = 0..4294967295
254 size = 0..2147483647
255 ansno = 0..2147483647
257 payload = *OCTET
259 trailer = "END" CR LF
261 mapping = ;; each transport mapping may define additional frames
263 2.2.1.1 Frame Header
265 The frame header consists of a three-character keyword (one of:
266 "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
267 parameters. A single space character (decimal code 32, " ")
268 separates each component. The header is terminated with a CRLF pair.
270 The channel number ("channel") must be a non-negative integer (in
271 the range 0..2147483647).
273 The message number ("msgno") must be a non-negative integer (in the
274 range 0..2147483647) and have a different value than all other "MSG"
275 messages on the same channel for which a reply has not been
276 completely received.
278 The continuation indicator ("more", one of: decimal code 42, "*", or
279 decimal code 46, ".") specifies whether this is the final frame of
280 the message:
282 intermediate ("*"): at least one other frame follows for the
283 message; or,
285 complete ("."): this frame completes the message.
287 The sequence number ("seqno") must be a non-negative integer (in the
288 range 0..4294967295) and specifies the sequence number of the first
289 octet in the payload, for the associated channel.
291 The payload size ("size") must be a non-negative integer (in the
292 range 0..2147483647) and specifies the exact number of octets in the
293 payload. (This does not include either the header or trailer.)
295 Note that a frame may have an empty payload, e.g.,
297 S: RPY 0 1 * 287 20
298 S: ...
299 S: ...
300 S: END
301 S: RPY 0 1 . 307 0
302 S: END
304 The answer number ("ansno") must be a non-negative integer (in the
305 range 0..4294967295) and must have a different value than all other
306 answers in progress for the message being replied to.
308 There are two kinds of frames: data and mapping. each transport
309 mapping (c.f., Section 2.5) may define its own frames. For example,
310 [5] defines the SEQ frame. The remainder of this section discusses
311 data frames.
313 When a message is segmented and sent as several frames, those frames
314 must be sent sequentally, without any intervening frames from other
315 messages on the same channel. However, there are two exceptions:
316 first, no restriction is made with respect to the interleaving of
317 frames for other channels; and, second, in a one-to-many exchange,
318 multiple answers may be simultaneously in progress. Accordingly,
319 frames for "ANS" messages may be interleaved on the same channel --
320 the answer number is used for collation, e.g.,
322 S: ANS 1 0 * 0 20 0
323 S: ...
324 S: ...
325 S: END
326 S: ANS 1 0 * 20 20 1
327 S: ...
328 S: ...
329 S: END
330 S: ANS 1 0 . 40 10 0
331 S: ...
332 S: END
334 which shows two "ANS" messages interleaved on channel 1 as part of a
335 reply to message number 0. Note that the sequence number is advanced
336 for each frame sent on the channel, and is independent of the
337 messages sent in those frames.
339 There are several rules for identifying poorly-formed frames:
341 o if the header doesn't start with "MSG", "RPY", "ERR", "ANS", or
342 "NUL";
344 o if any of the parameters in the header cannot be determined or
345 are invalid (i.e., syntactically incorrect);
347 o if the value of the channel number doesn't refer to an existing
348 channel;
350 o if the header starts with "MSG", and the message number refers to
351 a "MSG" message that has been completely received but for which a
352 reply has not been completely sent;
354 o if the header doesn't start with "MSG", and refers to a message
355 number for which a reply has already been completely received;
357 o if the header doesn't start with "MSG", and refers to a message
358 number that has never been sent (except during session
359 establishment, c.f., Section 2.3.1.1);
361 o if the header starts with "MSG", "RPY", "ERR", or "ANS", and
362 refers to a message number for which at least one other frame has
363 been received, and the three-character keyword starting this
364 frame and the immediately-previous received frame for this
365 message number are not identical;
367 o if the header starts with "NUL", and refers to a message number
368 for which at least one other frame has been received, and the
369 keyword of of the immediately-previous received frame for this
370 reply isn't "ANS";
372 o if the continuation indicator of the previous frame received on
373 the same channel was intermediate ("*"), and its message number
374 isn't identical to this frame's message number;
376 o if the value of the sequence number doesn't correspond to the
377 expected value for the associated channel (c.f., Section
378 2.2.1.2); or,
380 o if the header starts with "NUL", and the continuation indicator
381 is intermediate ("*") or the payload size is non-zero.
383 If a frame is poorly-formed, then the session is terminated without
384 generating a response, and it is recommended that a diagnostic entry
385 be logged.
387 2.2.1.2 Frame Payload
389 The frame payload consists of zero or more octets.
391 Every payload octet sent in each direction on a channel has an
392 associated sequence number. Numbering of payload octets within a
393 frame is such that the first payload octet is the lowest numbered,
394 and the following payload octets are numbered consecutively. (When a
395 channel is created, the sequence number associated with the first
396 payload octet of the first frame is 0.)
398 The actual sequence number space is finite, though very large,
399 ranging from 0..4294967295 (2**32 - 1). Since the space is finite,
400 all arithmetic dealing with sequence numbers is performed modulo
401 2**32. This unsigned arithmetic preserves the relationship of
402 sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult
403 Sections 2 through 5 of [8] for a discussion of the arithmetic
404 properties of sequence numbers.
406 When receiving a frame, the sum of its sequence number and payload
407 size, modulo 4294967296 (2**32), gives the expected sequence number
408 associated with the first payload octet of the next frame received.
409 Accordingly, when receiving a frame if the sequence number isn't the
410 expected value for this channel, then the BEEP peers have lost
411 synchronization, then the session is terminated without generating a
412 response, and it is recommended that a diagnostic entry be logged.
414 2.2.1.3 Frame Trailer
416 The frame trailer consists of "END" followed by a CRLF pair.
418 When receiving a frame, if the characters immediately following the
419 payload don't correspond to a trailer, then the session is
420 terminated without generating a response, and it is recommended that
421 a diagnostic entry be logged.
423 2.2.2 Frame Semantics
425 The semantics of each message is channel-specific. Accordingly, the
426 profile associated with a channel must define:
428 o the initialization messages, if any, exchanged during channel
429 creation;
431 o the messages that may be exchanged in the payload of the channel;
432 and,
434 o the semantics of these messages.
436 A profile registration template (Section 5.1) organizes this
437 information.
439 2.2.2.1 Poorly-formed Messages
441 When defining the behavior of the profile, the template must specify
442 how poorly-formed "MSG" messages are replied to. For example, the
443 channel management profile sends a negative reply containing an
444 error message (c.f., Section 2.3.1.5).
446 If a poorly-formed reply is received on channel zero, the session is
447 terminated without generating a response, and it is recommended that
448 a diagnostic entry be logged.
450 If a poorly-formed reply is received on another channel, then the
451 channel must be closed using the procedure in Section 2.3.1.3.
453 2.3 Channel Management
455 When a BEEP session starts, only channel number zero is defined,
456 which is used for channel management. Section 6.1 contains the
457 profile registration for BEEP channel management.
459 Channel management allows each BEEP peer to advertise the profiles
460 that it supports (c.f., Section 2.3.1.1), bind an instance of one of
461 those profiles to a channel (c.f., Section 2.3.1.2), and then later
462 close any channels or release the BEEP session (c.f., Section
463 2.3.1.3).
465 A BEEP peer should support at least 257 concurrent channels.
467 2.3.1 Message Semantics
469 2.3.1.1 The Greeting Message
471 When a BEEP session is established, each BEEP peer signifies its
472 availability by immediately sending a positive reply with a message
473 number of zero that contains a "greeting" element, e.g.,
475 L:
476 I:
477 L: RPY 0 0 . 0 122
478 L: Content-Type: application/beep+xml
479 L:
480 L:
481 L:
482 L:
483 L: END
484 I: RPY 0 0 . 0 52
485 I: Content-Type: application/beep+xml
486 I:
487 I:
488 I: END
490 Note that this example implies that the BEEP peer in the initiating
491 role waits until the BEEP peer in the listening role sends its
492 greeting -- this is an artifact of the presentation; in fact, both
493 BEEP peers send their replies independently.
495 The "greeting" element has two optional attributes ("features" and
496 "localize") and zero or more "profile" elements, one for each
497 profile supported by the BEEP peer acting in a server role:
499 o the "features" attribute, if present, contains one or more
500 feature tokens, each indicating an optional feature of the
501 channel management profile supported by the BEEP peer;
503 o the "localize" attribute, if present, contains one or more
504 language tokens (defined in [9]), each identifying a desirable
505 language tag to be used by the remote BEEP peer when generating
506 textual diagnostics for the "close" and "error" elements (the
507 tokens are ordered from most to least desirable); and,
509 o each "profile" element contained within the "greeting" element
510 identifies a profile, and unlike the "profile" elements that
511 occur within the "start" element, the content of each "profile"
512 element may not contain an optional initialization message.
514 Section 5.2 defines a registration template for optional features.
516 2.3.1.2 The Start Message
518 When a BEEP peer wants to create a channel, it sends a "start"
519 element on channel zero, e.g.,
521 C: MSG 0 1 . 52 132
522 C: Content-Type: application/beep+xml
523 C:
524 C:
525 C:
526 C:
527 C: END
529 The "start" element has a "number" attribute, an optional
530 "serverName" attribute, and one or more "profile" elements:
532 o the "number" attribute indicates the channel number (in the range
533 1..2147483647) used to identify the channel in future messages;
535 o the "serverName" attribute, an arbitrary string, indicates the
536 desired server name for this BEEP session; and,
538 o each "profile" element contained with the "start" element has a
539 "uri" attribute, an optional "encoding" attribute, and arbitrary
540 character data as content:
542 * the "uri" attribute authoritatively identifies the profile;
544 * the "encoding" attribute, if present, specifies whether the
545 content of the "profile" element is represented as a
546 base64-encoded string; and,
548 * the content of the "profile" element, if present, must be no
549 longer than 4K octets in length and specifies an
550 initialization message given to the channel as soon as it is
551 created.
553 To avoid conflict in assigning channel numbers when requesting the
554 creation of a channel, BEEP peers acting in the initiating role use
555 only positive integers that are odd-numbered; similarly, BEEP peers
556 acting in the listening role use only positive integers that are
557 even-numbered.
559 The "serverName" attribute for the first successful "start" element
560 received by a BEEP peer is meaningful for the duration of the BEEP
561 session. If present, the BEEP peer decides whether to operate as the
562 indicated "serverName"; if not, an "error" element is sent in a
563 negative reply.
565 When a BEEP peer receives a "start" element on channel zero, 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 sent in a positive reply; otherwise, an "error" element
569 is sent in a negative reply.
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 C: MSG 0 1 . 52 209
579 C: Content-Type: application/beep+xml
580 C:
581 C:
582 C:
583 C:
585 C:
586 C: END
587 S: RPY 0 1 . 264 99
588 S: Content-Type: application/beep+xml
589 S:
590 S:
591 S: END
593 Similarly, an unsuccessful channel creation might look like this:
595 C: MSG 0 1 . 52 132
596 C: Content-Type: application/beep+xml
597 C:
598 C:
599 C:
600 C:
601 C: END
602 S: ERR 0 1 . 264 127
603 S: Content-Type: application/beep+xml
604 S:
605 S: number attribute
606 S: in <start> element must be odd-valued
607 S: END
609 Finally, here's an example in which an initialization element is
610 exchanged during channel creation:
612 C: MSG 0 1 . 52 170
613 C: Content-Type: application/beep+xml
614 C:
615 C:
616 C:
617 C: ]]>
618 C:
619 C:
620 C: END
621 S: RPY 0 1 . 122 133
622 S: Content-Type: application/beep+xml
623 S:
624 S:
625 S: ]]>
626 S:
627 S: END
629 2.3.1.3 The Close Message
631 When a BEEP peer wants to close a channel, it sends a "close"
632 element on channel zero, e.g.,
634 C: MSG 0 2 . 247 71
635 C: Content-Type: application/beep+xml
636 C:
637 C:
638 C: END
640 The "close" element has a "number" attribute, a "code" attribute, an
641 optional "xml:lang" attribute, and an optional textual diagnostic as
642 its content:
644 o the "number" attribute indicates the channel number;
646 o the "code" attribute is a three-digit reply code meaningful to
647 programs (c.f., Section 8);
649 o the "xml:lang" attribute identifies the language that the
650 element's content is written in (the value is suggested, but not
651 mandated, by the "localize" attribute of the "greeting" element
652 sent by the remote BEEP peer); and,
654 o the textual diagnostic (which may be multiline) is meaningful to
655 implementers, perhaps administrators, and possibly even users,
656 but never programs.
658 Note that if the textual diagnostic is present, then the "xml:lang"
659 attribute is absent only if the language indicated as the remote
660 BEEP peer's first choice is used.
662 If the value of the "number" attribute is zero, then the BEEP peer
663 wants to release the BEEP session (c.f., Section 2.4) -- otherwise
664 the value of the "number" attribute refers to an existing channel.
666 When a BEEP peer receives a "close" element on channel zero, it
667 decides whether it is willing to close the channel. If so, an "ok"
668 element is sent in a positive reply; otherwise, an "error" element
669 is sent in a negative reply.
671 For example, a successful channel close might look like this:
673 C: MSG 0 2 . 247 71
674 C: Content-Type: application/beep+xml
675 C:
676 C:
677 C: END
678 S: RPY 0 2 . 447 46
679 S: Content-Type: application/beep+xml
680 S:
681 S:
682 S: END
684 Similarly, an unsuccessful channel close might look like this:
686 C: MSG 0 2 . 247 71
687 C: Content-Type: application/beep+xml
688 C:
689 C:
690 C: END
691 S: ERR 0 2 . 447 79
692 S: Content-Type: application/beep+xml
693 S:
694 S: still working
695 S: END
697 2.3.1.4 The OK Message
699 When a BEEP peer agrees to close a channel (or release the BEEP
700 session), it sends an "ok" element in a positive reply.
702 The "ok" element has no attributes and no content.
704 2.3.1.5 The Error Message
706 When a BEEP peer declines the creation of a channel, it sends an
707 "error" element in a negative reply, e.g.,
709 I: MSG 0 1 . 52 127
710 I: Content-Type: application/beep+xml
711 I:
712 I:
713 I:
714 I:
715 I: END
716 L: ERR 0 1 . 264 105
717 L: Content-Type: application/beep+xml
718 L:
719 L: all requested profiles are
720 L: unsupported
721 L: END
723 The "error" element has a "code" attribute, an optional "xml:lang"
724 attribute, and an optional textual diagnostic as its content:
726 o the "code" attribute is a three-digit reply code meaningful to
727 programs (c.f., Section 8);
729 o the "xml:lang" attribute identifies the language that the
730 element's content is written in (the value is suggested, but not
731 mandated, by the "localize" attribute of the "greeting" element
732 sent by the remote BEEP peer); and,
734 o the textual diagnostic (which may be multiline) is meaningful to
735 implementers, perhaps administrators, and possibly even users,
736 but never programs.
738 Note that if the textual diagnostic is present, then the "xml:lang"
739 attribute is absent only if the language indicated as the remote
740 BEEP peer's first choice is used.
742 In addition, a BEEP peer sends an "error" element whenever:
744 o it receives a "MSG" message containing a poorly-formed or
745 unexpected element;
747 o it receives a "MSG" message asking to close a channel (or release
748 the BEEP session) and it declines to do so; or
750 o a BEEP session is established, the BEEP peer is acting in the
751 listening role, and that BEEP peer is unavailable (in this case,
752 the BEEP acting in the listening role does not send a "greeting"
753 element).
755 In the final case, both BEEP peers terminate the session, and it is
756 recommended that a diagnostic entry be logged by both BEEP peers.
758 2.4 Session Establishment and Release
760 When a BEEP session is established, each BEEP peer signifies its
761 availability by immediately sending a positive reply with a message
762 number of zero on channel zero that contains a "greeting" element,
763 e.g.,
765 L:
766 I:
767 L: RPY 0 0 . 0 122
768 L: Content-Type: application/beep+xml
769 L:
770 L:
771 L:
772 L:
773 L: END
774 I: RPY 0 0 . 0 52
775 I: Content-Type: application/beep+xml
776 I:
777 I:
778 I: END
780 Alternatively, if the BEEP peer acting in the listening role is
781 unavailable, it sends a negative reply, e.g.,
783 L:
784 I:
785 L: ERR 0 0 . 0 60
786 L: Content-Type: application/beep+xml
787 L:
788 L:
789 L: END
790 I: RPY 0 0 . 0 52
791 I: Content-Type: application/beep+xml
792 I:
793 I:
794 I: END
795 I:
796 L:
797 L:
799 and the "greeting" element sent by the BEEP peer acting in the
800 initiating role is ignored. It is recommended that a diagnostic
801 entry be logged by both BEEP peers.
803 Note that both of these examples imply that the BEEP peer in the
804 initiating role waits until the BEEP peer in the listening role
805 sends its greeting -- this is an artifact of the presentation; in
806 fact, both BEEP peers send their replies independently.
808 When a BEEP peer wants to release the BEEP session, it sends a
809 "close" element with a zero-valued "number" attribute on channel
810 zero. The other BEEP peer indicates its willingness by sending an
811 "ok" element in a positive reply, e.g.,
813 C: MSG 0 1 . 52 60
814 C: Content-Type: application/beep+xml
815 C:
816 C:
817 C: END
818 S: RPY 0 1 . 264 46
819 S: Content-Type: application/beep+xml
820 S:
821 S:
822 S: END
823 I:
824 L:
825 L:
827 Alternatively, if the other BEEP doesn't want to release the BEEP
828 session, the exchange might look like this:
830 C: MSG 0 1 . 52 60
831 C: Content-Type: application/beep+xml
832 C:
833 C:
834 C: END
835 S: ERR 0 1 . 264 79
836 S: Content-Type: application/beep+xml
837 S:
838 S: still working
839 S: END
841 If session release is declined, the BEEP session should not be
842 terminated, if possible.
844 2.5 Transport Mappings
846 All transport interactions occur in the context of a session -- a
847 mapping onto a particular transport service. Accordingly, this memo
848 defines the requirements that must be satisified by any document
849 describing how a particular transport service realizes a BEEP
850 session.
852 2.5.1 Session Management
854 A BEEP session is connection-oriented. A mapping document must
855 define:
857 o how a BEEP session is established;
859 o how a BEEP peer is identified as acting in the listening role;
861 o how a BEEP peer is identified as acting in the initiating role;
863 o how a BEEP session is released; and,
865 o how a BEEP session is terminated.
867 2.5.2 Message Exchange
869 A BEEP session is message-oriented. A mapping document must define:
871 o how messages are reliably sent and received;
873 o how messages on the same channel are received in the same order
874 as they were sent; and,
876 o how messages on different channels are sent without ordering
877 constraint.
879 2.6 Parallelism
881 2.6.1 Within a Single Channel
883 A BEEP peer acting in the client role may send multiple "MSG"
884 messages on the same channel without waiting to receive the
885 corresponding replies.
887 A BEEP peer acting in the server role must process all "MSG"
888 messages for a given channel in the same order as they are received.
889 As a consequence, the BEEP peer must generate replies in the same
890 order as the corresponding "MSG" messages are received on a given
891 channel.
893 2.6.2 Between Different Channels
895 A BEEP peer acting in the client role may send multiple "MSG"
896 messages on different channels without waiting to receive the
897 corresponding replies.
899 A BEEP peer acting in the server role may process "MSG" messages
900 received on different channels in any order it chooses. As a
901 consequence, although the replies for a given channel appear to be
902 generated in the same order in which the corresponding "MSG"
903 messages are received, there is no ordering constraint for replies
904 on different channels.
906 2.6.3 Pre-emptive Replies
908 A BEEP peer acting in the server role may send a negative reply
909 before it receives the final "MSG" frame of a message. If it does
910 so, that BEEP peer is obliged to ignore any subsequent "MSG" frames
911 for that message, up to and including the final "MSG" frame.
913 If a BEEP peer acting in the client role receives a negative reply
914 before it sends the final "MSG" frame for a message, then it is
915 required to send a "MSG" frame with a continuation status of
916 complete (".") and having a zero-length payload.
918 2.6.4 Interference
920 If the processing of a particular message has sequencing impacts on
921 other messages (either intra-channel or inter-channel), then the
922 corresponding profile should define this behavior, e.g., a profile
923 whose messages alter the underlying transport mapping.
925 2.7 Peer-to-Peer Behavior
927 BEEP is peer-to-peer -- as such both peers must be prepared to
928 receive all messages defined in this memo. Accordingly, an
929 initiating BEEP peer capable of acting only in the client role must
930 behave gracefully if it receives a "MSG" message. Accordingly, all
931 profiles must provide an appropriate error message for replying to
932 unexpected "MSG" messages.
934 As a consequence of the peer-to-peer nature of BEEP, message numbers
935 are unidirectionally-significant. That is, the message numbers in
936 "MSG" messages sent by a BEEP peer acting in the initiating role are
937 unrelated to the message numbers in "MSG" messages sent by a BEEP
938 peer acting in the listening role.
940 For example, these two messages
942 I: MSG 0 1 . 52 132
943 I: Content-Type: application/beep+xml
944 I:
945 I:
946 I:
947 I:
948 I: END
949 L: MSG 0 1 . 264 128
950 L: Content-Type: application/beep+xml
951 L:
952 L:
953 L:
954 L:
955 L: END
957 refer to different messages sent on channel zero.
959 3. Transport Security
961 When a BEEP session is established, plaintext transfer, without
962 privacy, is provided. Accordingly, transport security in BEEP is
963 achieved using an initial tuning profile.
965 This document defines one profile:
967 o the TLS transport security profile, based on TLS version one[3].
969 Other profiles may be defined and deployed on a bilateral basis.
970 Note that because of their intimate relationship with the tranpsort
971 service, a given transport security profile tends to be relevant to
972 a single transort mapping (c.f., Section 2.5).
974 When a channel associated with transport security begins the
975 underlying negotiation process, all channels (including channel
976 zero) are closed on the BEEP session. Accordingly, upon completion
977 of the negotiation process, regardless of its outcome, a new
978 greeting is issued by both BEEP peers. (If the negotiation process
979 fails, then either BEEP peer may instead terminate the session, and
980 it is recommended that a diagnostic entry be logged.)
982 A BEEP peer may choose to issue different greetings based on whether
983 privacy is in use, e.g.,
985 L:
986 I:
987 L: RPY 0 0 . 0 122
988 L: Content-Type: application/beep+xml
989 L:
990 L:
991 L:
992 L:
993 L: END
994 I: RPY 0 0 . 0 52
995 I: Content-Type: application/beep+xml
996 I:
997 I:
998 I: END
999 I: MSG 0 1 . 52 170
1000 I: Content-Type: application/beep+xml
1001 I:
1002 I:
1003 I:
1004 I: ]]>
1005 I:
1006 I:
1007 I: END
1008 L: RPY 0 1 . 122 133
1009 L: Content-Type: application/beep+xml
1010 L:
1011 L:
1012 L: ]]>
1013 L:
1014 L: END
1016 ... successful transport security negotiation ...
1018 L: RPY 0 0 . 0 264
1019 L: Content-Type: application/beep+xml
1020 L:
1021 L:
1022 L:
1024 L:
1025 L:
1026 L:
1027 L: END
1028 I: RPY 0 0 . 0 52
1029 I: Content-Type: application/beep+xml
1030 I:
1031 I:
1032 I: END
1034 Of course, not all BEEP peers need be as single-minded:
1036 L:
1037 I:
1038 L: RPY 0 0 . 0 323
1039 L: Content-Type: application/beep+xml
1040 L:
1041 L:
1042 L:
1044 L:
1045 L:
1046 L:
1047 L:
1048 L: END
1049 I: RPY 0 0 . 0 52
1050 I: Content-Type: application/beep+xml
1051 I:
1052 I:
1053 I: END
1054 I: MSG 0 1 . 52 170
1055 I: Content-Type: application/beep+xml
1056 I:
1058 I:
1059 I:
1060 I: ]]>
1061 I:
1062 I:
1063 I: END
1064 L: RPY 0 1 . 323 133
1065 L: Content-Type: application/beep+xml
1066 L:
1067 L:
1068 L: ]]>
1069 L:
1070 L: END
1072 ... failed transport security negotiation ...
1074 L: RPY 0 0 . 0 323
1075 L: Content-Type: application/beep+xml
1076 L:
1077 L:
1078 L:
1080 L:
1081 L:
1082 L:
1083 L:
1084 L: END
1085 I: RPY 0 0 . 0 52
1086 I: Content-Type: application/beep+xml
1087 I:
1088 I:
1089 I: END
1091 3.1 The TLS Transport Security Profile
1093 Section 6.2 contains the registration for this profile.
1095 3.1.1 Profile Identification and Initialization
1097 The TLS transport security profile is identified as:
1099 http://xml.resource.org/profiles/TLS
1101 in the BEEP "profile" element during channel creation.
1103 During channel creation, the corresponding "profile" element in the
1104 BEEP "start" element may contain a "ready" element. If channel
1105 creation is successful, then before sending the corresponding reply,
1106 the BEEP peer processes the "ready" element and includes the
1107 resulting response in the reply, e.g.,
1109 C: MSG 0 1 . 52 170
1110 C: Content-Type: application/beep+xml
1111 C:
1112 C:
1113 C:
1114 C: ]]>
1115 C:
1116 C:
1117 C: END
1118 S: RPY 0 1 . 122 133
1119 S: Content-Type: application/beep+xml
1120 S:
1121 S:
1122 S: ]]>
1123 S:
1124 S: END
1126 Note that it is possible for the channel to be created, but for the
1127 encapsulated operation to fail, e.g.,
1129 C: MSG 0 1 . 52 185
1130 C: Content-Type: application/beep+xml
1131 C:
1132 C:
1133 C:
1134 C: ]]>
1135 C:
1136 C:
1137 C: END
1138 S: RPY 0 1 . 122 205
1139 S: Content-Type: application/beep+xml
1140 S:
1141 S:
1142 S: version attribute
1143 S: poorly formed in <ready> element]]>
1144 S:
1145 S: END
1147 In this case, a positive reply is sent (as channel creation
1148 succeeded), but the encapsulated response contains an indication as
1149 to why the operation failed.
1151 3.1.2 Message Syntax
1153 Section 7.2 defines the messages that are used in the TLS transport
1154 security profile.
1156 3.1.3 Message Semantics
1158 3.1.3.1 The Ready Message
1160 The "ready" element has an optional "version" attribute and no
1161 content:
1163 o the "version" element defines the earliest version of TLS
1164 acceptable for use.
1166 When a BEEP peer sends the "ready" element, it must not send any
1167 further traffic on any channel until a corresponding reply is
1168 received; similarly, before processing a "ready" element, the
1169 receiving BEEP peer waits until any pending replies have been
1170 generated and sent.
1172 3.1.3.2 The Proceed Message
1174 The "proceed" element has no attributes and no content. It is sent
1175 as a reply to the "ready" element. When a BEEP peer receives the
1176 "ready" element, it begins the underlying negotiation process for
1177 transport security.
1179 4. User Authentication
1181 When a BEEP session is established, anonymous access, without trace
1182 information, is provided. Accordingly, user authentication in BEEP
1183 is achieved using an initial tuning profile.
1185 This document defines a family of profiles based on SASL mechanisms:
1187 o each mechanism in the IANA SASL registry[15] has an associated
1188 profile.
1190 Other profiles may be defined and deployed on a bilateral basis.
1192 Whenever a successful authentication occurs, on any channel, the
1193 authenticated identity is updated for all existing and future
1194 channels on the BEEP session; further, no additional attempts at
1195 authentication are allowed.
1197 Note that regardless of transport security and user authentication,
1198 authorization is an internal matter for each BEEP peer. As such,
1199 each peer may choose to restrict the operations it allows based on
1200 the authentication credentials provided (i.e., unauthorized
1201 operations might be rejected with error code 530).
1203 4.1 The SASL Family of Profiles
1205 Section 6.3 contains the registration for this profile.
1207 Note that SASL may provide both user authentication and transport
1208 security. Once transport security is successfully negotiated for a
1209 BEEP session, then a SASL security layer must not be negotiated;
1210 similarly, once any SASL negotiation is successful, a transport
1211 security profile must not begin its underlying negotiation process.
1213 Section 4 of the SASL specification[4] requires the following
1214 information be supplied by a protocol definition:
1216 service name: "beep"
1218 initiation sequence: Creating a channel using a BEEP profile
1219 corresponding to a SASL mechanism starts the exchange. An
1220 optional parameter corresponding to the "initial response" sent
1221 by the client is carried within a "blob" element during channel
1222 creation.
1224 exchange sequence: "Challenges" and "responses" are carried in
1225 exchanges of the "blob" element. The "status" attribute of the
1226 "blob" element is used both by a server indicating a successful
1227 completion of the exchange, and a client aborting the exchange,
1228 The server indicates failure of the exchange by sending an
1229 "error" element.
1231 security layer negotiation: When a security layer starts
1232 negotiation, all channels (including channel zero) are closed on
1233 the BEEP session. Accordingly, upon completion of the negotiation
1234 process, regardless of its outcome, a new greeting is issued by
1235 both BEEP peers.
1237 If a security layer is successfully negotiated, it takes effect
1238 immediately following the message that concludes the server's
1239 successful completion reply.
1241 use of the authorization identity: This is made available to all
1242 channels for the duration of the BEEP session.
1244 4.1.1 Profile Identification and Initialization
1246 Each SASL mechanism registered with the IANA is identified as:
1248 http://xml.resource.org/profiles/sasl/MECHANISM
1250 where "MECHANISM" is the token assigned to that mechanism by the
1251 IANA.
1253 Note that during channel creation, a BEEP peer may provide multiple
1254 profiles to the remote peer, e.g.,
1256 C: MSG 0 1 . 52 209
1257 C: Content-Type: application/beep+xml
1258 C:
1259 C:
1260 C:
1262 C:
1263 C:
1264 C: END
1265 S: RPY 0 1 . 264 99
1266 S: Content-Type: application/beep+xml
1267 S:
1268 S:
1269 S: END
1271 During channel creation, the corresponding "profile" element in the
1272 BEEP "start" element may contain a "blob" element. Note that it is
1273 possible for the channel to be created, but for the encapsulated
1274 operation to fail, e.g.,
1276 C: MSG 0 1 . 52 195
1277 C: Content-Type: application/beep+xml
1278 C:
1279 C:
1280 C:
1281 C: AGJsb2NrbWFzdGVy]]>
1282 C:
1283 C:
1284 C: END
1285 S: RPY 0 1 . 264 190
1286 S: Content-Type: application/beep+xml
1287 S:
1288 S:
1289 S: authentication mechanism is
1290 S: too weak]]>
1291 S:
1292 S: END
1294 In this case, a positive reply is sent (as channel creation
1295 succeeded), but the encapsulated response contains an indication as
1296 to why the operation failed.
1298 Otherwise, the server sends a challenge (or signifies success), e.g.,
1300 C: MSG 0 1 . 52 195
1301 C: Content-Type: application/beep+xml
1302 C:
1303 C:
1304 C:
1305 C: AGJsb2NrbWFzdGVy]]>
1306 C:
1307 C:
1308 C: END
1309 S: RPY 0 1 . 264 183
1310 S: Content-Type: application/beep+xml
1311 S:
1312 S:
1313 S: b3RwLXNoYTEgOTk5NyBwaXh5bWlzYXM4NTgwNSBleHQ=
1314 ]]>
1315 S:
1316 S: END
1318 Note that this example implies that the "blob" element in the
1319 server's reply appears on two lines -- this is an artifact of the
1320 presentation; in fact, only one line is used.
1322 If a challenge is received, then the client responds and awaits
1323 another reply, e.g.,
1325 C: MSG 1 0 . 0 97
1326 C: Content-Type: application/beep+xml
1327 C:
1328 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1329 C: END
1330 S: RPY 1 0 . 0 66
1331 S: Content-Type: application/beep+xml
1332 S:
1333 S:
1334 S: END
1336 Of course, the client could abort the authentication process by
1337 sending "" instead.
1339 Alternatively, the server might reject the response with an error:
1340 e.g.,
1342 C: MSG 1 0 . 0 97
1343 C: Content-Type: application/beep+xml
1344 C:
1345 C: d29yZDpmZXJuIGhhbmcgYnJvdyBib25nIGhlcmQgdG9n
1346 C: END
1347 S: ERR 1 1 . 0 60
1348 S: Content-Type: application/beep+xml
1349 S:
1350 S:
1351 S: END
1353 Finally, depending on the SASL mechanism, an initialization element
1354 may be exchanged unidirectionally during channel creation, e.g.,
1356 C: MSG 0 1 . 52 145
1357 C: Content-Type: application/beep+xml
1358 C:
1359 C:
1360 C:
1362 C:
1363 C: END
1364 S: RPY 0 1 . 264 197
1365 S: Content-Type: application/beep+xml
1366 S:
1367 S:
1368 S: PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
1369 jaS5uZXQ+]]>
1370 S:
1371 S: END
1373 Note that this example implies that the "blob" element in the
1374 server's reply appears on two lines -- this is an artifact of the
1375 presentation; in fact, only one line is used.
1377 4.1.2 Message Syntax
1379 Section 7.3 defines the messages that are used for each profile in
1380 the SASL family.
1382 Note that because many SASL mechanisms exchange binary data, the
1383 content of the "blob" element is always a base64-encoded string.
1385 4.1.3 Message Semantics
1387 The "blob" element has an optional "status" attribute, and arbitrary
1388 octets as its content:
1390 o the "status" attribute, if present, takes one of three values:
1392 abort: used by a client to indicate that it is aborting the
1393 authentication process;
1395 complete: used by a server to indicate that the exchange is
1396 complete and successful; or,
1398 continue: used by either a client or server, otherwise.
1400 Finally, note that SASL's EXTERNAL mechanism works with an "external
1401 authentication" service, which is provided by one of:
1403 o a transport security profile, capable of providing authentication
1404 information (e.g., Section 3.1), being active on the connection;
1406 o a network service, capable of providing strong authentication
1407 (e.g., IPSec[12]), underlying the connection; or,
1409 o a locally-defined security service.
1411 For authentication to succeed, two conditions must hold:
1413 o an external authentication service must be active; and,
1415 o if present, the authentication identity must be consistent with
1416 the credentials provided by the external authentication service
1417 (if the authentication identity is empty, then an authorization
1418 identity is automatically derived from the credentials provided
1419 by the external authentication service).
1421 5. Registration Templates
1423 5.1 Profile Registration Template
1425 When a profile is registered, the following information is supplied:
1427 Profile Identification: specify a URI[10] that authoritatively
1428 identifies this profile.
1430 Message Exchanged during Channel Creation: specify the datatypes
1431 that may be exchanged during channel creation.
1433 Messages starting one-to-one exchanges: specify the datatypes that
1434 may be present when an exchange starts.
1436 Messages in positive replies: specify the datatypes that may be
1437 present in a positive reply.
1439 Messages in negative replies: specify the datatypes that may be
1440 present in a negative reply.
1442 Messages in one-to-many exchanges: specify the datatypes that may be
1443 present in a one-to-many exchange.
1445 Message Syntax: specify the syntax of the datatypes exchanged by the
1446 profile.
1448 Message Semantics: specify the semantics of the datatypes exchanged
1449 by the profile.
1451 Contact Information: specify the postal and electronic contact
1452 information for the author of the profile.
1454 5.2 Feature Registration Template
1456 When a feature for the channel management profile is registered, the
1457 following information is supplied:
1459 Feature Identification: specify a string that identifies this
1460 feature. Unless the feature is registered with the IANA, the
1461 feature's identification must start with "x-".
1463 Feature Semantics: specify the semantics of the feature.
1465 Contact Information: specify the postal and electronic contact
1466 information for the author of the feature.
1468 6. Initial Registrations
1470 6.1 Registration: BEEP Channel Management
1472 Profile Identification: not applicable
1474 Messages exchanged during Channel Creation: not applicable
1476 Messages starting one-to-one exchanges: "start" or "close"
1478 Messages in positive replies: "greeting", "profile", or "ok"
1480 Messages in negative replies: "error"
1482 Messages in one-to-many exchanges: none
1484 Message Syntax: c.f., Section 7.1
1486 Message Semantics: c.f., Section 2.3.1
1488 Contact Information: c.f., the "Author's Address" section of this
1489 memo
1491 6.2 Registration: TLS Transport Security Profile
1493 Profile Identification: http://xml.resource.org/profiles/TLS
1495 Messages exchanged during Channel Creation: "ready"
1497 Messages starting one-to-one exchanges: "ready"
1499 Messages in positive replies: "proceed"
1501 Messages in negative replies: "error"
1503 Messages in one-to-many exchanges: none
1505 Message Syntax: c.f., Section 7.2
1507 Message Semantics: c.f., Section 3.1.3
1509 Contact Information: c.f., the "Author's Address" section of this
1510 memo
1512 6.3 Registration: SASL Family of Profiles
1514 Profile Identification:
1515 http://xml.resource.org/profiles/sasl/MECHANISM, where
1516 "MECHANISM" is a token registered with the IANA[16]
1518 Messages exchanged during Channel Creation: "blob"
1520 Messages starting one-to-one exchanges: "blob"
1522 Messages in positive replies: "blob"
1524 Messages in negative replies: "error"
1526 Messages in one-to-many exchanges: none
1528 Message Syntax: c.f., Section 7.3
1530 Message Semantics: c.f., Section 4.1.3
1532 Contact Information: c.f., the "Author's Address" section of this
1533 memo
1535 6.4 Registration: application/beep+xml
1537 MIME media type name: application
1539 MIME subtype name: beep+xml
1541 Required parameters: none
1543 Optional parameters: charset (defaults to "UTF-8"[13])
1545 Encoding considerations: This media type may contain binary content;
1546 accordingly, when used over a transport that does not permit
1547 binary transfer, an appropriate encoding must be applied
1549 Security considerations: none, per se; however, any BEEP profile
1550 which uses this media type must describe its relevant security
1551 considerations
1553 Interoperability considerations: n/a
1555 Published specification: This media type is a proper subset of the
1556 the XML 1.0 specification[2]. Two restrictions are made.
1558 First, no entity references other than the five predefined
1559 general entities references ("&", "<", ">", "'",
1560 and """) and numeric entity references may be present.
1562 Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" declaration (e.g., ) may be
1564 present. (Accordingly, if another character set other than UTF-8
1565 is desired, then the "charset" parameter must be present.)
1567 All other XML 1.0 instructions (e.g., CDATA blocks, processing
1568 instructions, and so on) are allowed.
1570 Applications which use this media type: any BEEP profile wishing to
1571 make use of this XML 1.0 subset
1573 Additional Information: none
1575 Contact for further information: c.f., the "Author's Address"
1576 section of this memo
1578 Intended usage: limited use
1580 Author/Change controller: the IESG
1582 7. DTDs
1584 7.1 BEEP Channel Management DTD
1586
1596
1620
1621
1622
1623
1624
1625
1626
1638
1639
1643
1644
1648
1649
1650
1654
1655
1660
1662
1663
1667 7.2 TLS Transport Security Profile DTD
1669
1679
1687
1688
1691
1693 7.3 SASL Family of Profiles DTD
1695
1705
1713
1714
1720 8. Reply Codes
1722 code meaning
1723 ==== =======
1724 421 service not available
1726 450 requested action not taken
1727 (e.g., lock already in use)
1729 451 requested action aborted
1730 (e.g., local error in processing)
1732 454 temporary authentication failure
1734 500 general syntax error
1735 (e.g., poorly-formed XML)
1737 501 syntax error in parameters
1738 (e.g., non-valid XML)
1740 504 parameter not implemented
1742 530 authentication required
1744 534 authentication mechanism insufficient
1745 (e.g., too weak, sequence exhausted, etc.)
1747 535 authentication failure
1749 537 action not authorized for user
1751 538 authentication mechanism requires encryption
1753 550 requested action not taken
1754 (e.g., no requested profiles are acceptable)
1756 553 parameter invalid
1758 554 transaction failed
1759 (e.g., policy violation)
1761 9. Security Considerations
1763 The BEEP framing mechanism, per se, provides no protection against
1764 attack; however, judicious use of initial tuning profiles provides
1765 varying degrees of assurance:
1767 1. If one of the profiles from the SASL family is used, refer to
1768 [4]'s Section 9 for a discussion of security considerations.
1770 2. If the TLS transport security profile is used (or if a SASL
1771 security layer is negotiated), then:
1773 1. A man-in-the-middle may remove the security-related profiles
1774 from the BEEP greeting or generate a negative reply to the
1775 "ready" element of the TLS transport security profile. A
1776 BEEP peer may be configurable to refuse to proceed without
1777 an acceptable level of privacy.
1779 2. A man-in-the-middle may cause a down-negotiation to the
1780 weakest cipher suite available. A BEEP peer should be
1781 configurable to refuse weak cipher suites.
1783 3. A man-in-the-middle may modify any protocol exchanges prior
1784 to a successful negotiation. Upon completing the
1785 negotiation, a BEEP peer must discard previously cached
1786 information about the BEEP session.
1788 As different TLS ciphersuites provide varying levels of
1789 security, administrators should carefully choose which
1790 ciphersuites are provisioned.
1792 As BEEP is peer-to-peer in nature, before performing any task
1793 associated with a message, each channel should apply the appropriate
1794 access control based on the authenticated identity and privacy level
1795 associated with the BEEP session.
1797 References
1799 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1800 Extensions (MIME) Part One: Format of Internet Message
1801 Bodies", RFC 2045, November 1996.
1803 [2] World Wide Web Consortium, "Extensible Markup Language (XML)
1804 1.0", W3C XML, February 1998,
1805 .
1807 [3] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A.
1808 O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
1809 January 1999.
1811 [4] Myers, J.G., "Simple Authentication and Security Layer
1812 (SASL)", RFC 2222, October 1997.
1814 [5] Rose, M.T., "Mapping the BEEP Framework onto TCP",
1815 draft-ietf-beep-tcpmapping-04 (work in progress), October 2000.
1817 [6] Postel, J., "Transmission Control Protocol", RFC 793, STD 7,
1818 Sep 1981.
1820 [7] Crocker, D. H. and P. Overell, "Augmented BNF for Syntax
1821 Specifications: ABNF", RFC 2234, November 1997.
1823 [8] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
1824 August 1996.
1826 [9] Alvestrand, H., "Tags for the Identification of Languages",
1827 RFC 1766, March 1995.
1829 [10] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
1830 Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1831 1998.
1833 [11] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
1834 October 1998.
1836 [12] Kent, S. and R. Atkinson, "Security Architecture for the
1837 Internet Protocol", RFC 2401, November 1998.
1839 [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
1840 RFC 2279, January 1998.
1842 [14] Linn, J., "Generic Security Service Application Program
1843 Interface, Version 2", RFC 2078, January 1997.
1845 [15]
1847 [16]
1848 Author's Address
1850 Marshall T. Rose
1851 Invisible Worlds, Inc.
1852 1179 North McDowell Boulevard
1853 Petaluma, CA 94954-6559
1854 US
1856 Phone: +1 707 789 3700
1857 EMail: mrose@invisible.net
1858 URI: http://invisible.net/
1860 Appendix A. Acknowledgements
1862 The author gratefully acknowledges the contributions of: David
1863 Clark, Dave Crocker, Steve Deering, Wesley Michael Eddy, Huston
1864 Franklin, Marco Gazzetta, Danny Goodman, Steve Harris, Robert
1865 Herriot, Ken Hirsch, Greg Hudson, Ben Laurie, Carl Malamud, Michael
1866 Mealling, Keith McCloghrie, Paul Mockapetris, RL 'Bob' Morgan, Frank
1867 Morton, Darren New, Chris Newman, Joe Touch, Paul Vixie, Gabe
1868 Wachob, Daniel Woods, and, James Woodyatt. In particular, Dave
1869 Crocker provided helpful suggestions on the nature of segmentation
1870 in the framing mechanism.
1872 Appendix B. IANA Considerations
1874 The IANA registers "beep" as a GSSAPI[14] service name, as specified
1875 in Section 4.1.
1877 The IANA maintains a list of:
1879 o standards-track BEEP profiles, c.f., Section 5.1; and,
1881 o standards-track features for the channel management profile,
1882 c.f., Section 5.2.
1884 For each list, the IESG is responsible for assigning a designated
1885 expert to review the specification prior to the IANA making the
1886 assignment. As a courtesy to developers of non-standards track BEEP
1887 profiles and channel management features, the mailing list
1888 bxxpwg@invisible.net may be used to solicit commentary.
1890 The IANA makes the registrations specified in Section 6.2 and
1891 Section 6.3. It is recommended that the IANA register these profiles
1892 using the IANA as a URI-prefix, and populate those URIs with the
1893 respective profile registrations.
1895 Full Copyright Statement
1897 Copyright (C) The Internet Society (2000). All Rights Reserved.
1899 This document and translations of it may be copied and furnished to
1900 others, and derivative works that comment on or otherwise explain it
1901 or assist in its implementation may be prepared, copied, published
1902 and distributed, in whole or in part, without restriction of any
1903 kind, provided that the above copyright notice and this paragraph
1904 are included on all such copies and derivative works. However, this
1905 document itself may not be modified in any way, such as by removing
1906 the copyright notice or references to the Internet Society or other
1907 Internet organizations, except as needed for the purpose of
1908 developing Internet standards in which case the procedures for
1909 copyrights defined in the Internet Standards process must be
1910 followed, or as required to translate it into languages other than
1911 English.
1913 The limited permissions granted above are perpetual and will not be
1914 revoked by the Internet Society or its successors or assigns.
1916 This document and the information contained herein is provided on an
1917 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1918 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1919 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1920 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1921 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1923 Acknowledgement
1925 Funding for the RFC editor function is currently provided by the
1926 Internet Society.