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.