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