idnits 2.17.1 draft-ietf-crisp-iris-xpc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1324. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3981, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3981, updated by this document, for RFC5378 checks: 2002-08-15) -- 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 (March 5, 2007) is 6262 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3268 (ref. '7') (Obsoleted by RFC 5246) -- No information found for draft-ietf-crips-iris-common-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1166 (ref. '10') ** Obsolete normative reference: RFC 4013 (ref. '12') (Obsoleted by RFC 7613) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Updates: 3981 (if approved) March 5, 2007 5 Intended status: Standards Track 6 Expires: September 6, 2007 8 XML Pipelining with Chunks for the Information Registry Information 9 Service 10 draft-ietf-crisp-iris-xpc-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a simple TCP transfer protocol for the 44 Internet Registry Information Service (IRIS). Data is transfered 45 between clients and servers using chunks to achieve pipelining. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 51 3. Request Block (RQB) . . . . . . . . . . . . . . . . . . . . . 5 52 4. Response Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Response Block (RSB) . . . . . . . . . . . . . . . . . . . 6 54 4.2. Connection Response Block (CRB) . . . . . . . . . . . . . 6 55 5. Block Header . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 6.1. No Data Types . . . . . . . . . . . . . . . . . . . . . . 11 58 6.2. Version Information Types . . . . . . . . . . . . . . . . 11 59 6.3. Size Information Types . . . . . . . . . . . . . . . . . . 11 60 6.4. Other Information Types . . . . . . . . . . . . . . . . . 12 61 6.5. SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 13 62 6.6. Authentication Succss Information Types . . . . . . . . . 14 63 6.7. Authentication Failure Information Types . . . . . . . . . 14 64 6.8. Application Data Types . . . . . . . . . . . . . . . . . . 14 65 7. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . . 15 66 8. Closing Sessions Due To An Error . . . . . . . . . . . . . . . 16 67 9. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 10. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . . 18 69 11. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 19 70 11.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 19 71 11.2. Application Protocol Label . . . . . . . . . . . . . . . . 19 72 12. Internationalization Considerations . . . . . . . . . . . . . 20 73 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 74 13.1. XPC URI Scheme Registration . . . . . . . . . . . . . . . 21 75 13.2. XPCS URI Scheme Registration . . . . . . . . . . . . . . . 21 76 13.3. S-NAPTR XPC Registration . . . . . . . . . . . . . . . . . 22 77 13.4. S-NAPTR XPCS Registration . . . . . . . . . . . . . . . . 22 78 13.5. Well-known TCP Port Registration for XPC . . . . . . . . . 22 79 13.6. Well-known TCP Port Registration for XPCS . . . . . . . . 23 80 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 14.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 24 82 14.2. SASL Compliance . . . . . . . . . . . . . . . . . . . . . 25 83 15. Normative References . . . . . . . . . . . . . . . . . . . . . 26 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27 85 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 35 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 87 Intellectual Property and Copyright Statements . . . . . . . . . . 37 89 1. Introduction 91 Using S-NAPTR [5], IRIS has the ability to define the use of multiple 92 application transports (or transfer protocols) for different types of 93 registry services, all at the descretion of the server operator. The 94 TCP transfer protocol defined in this document is completely modular 95 and may be used by any registry types. 97 This transfer protocol defines simple framing for sending XML in 98 chunks so that XML fragments may be acted upon (or pipelined) before 99 the reception of the entire XML instance. This document calls this 100 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 102 XPC is for use with simple request and response interactions between 103 clients and servers. Clients send a series of requests to a server 104 in data blocks. The server will respond to each data block 105 individually with a corresponding data block, but through the same 106 connection. Request and response data blocks are sent using the TCP 107 SEND function and received using the TCP RECEIVE function. 109 The lifecycle of an XPC session has the following phases: 111 1. A client establishes a TCP connection with a server. 113 2. The server sends a connection response block (CRB). 115 3. The client sends a request block (RQB). In this request, the 116 client can set a "keep open" flag requesting that the server keep 117 the XPC session open following the response to this request. 119 4. The server responds with a response block (RSB). In this 120 response, the server can indicate to the client whether or not 121 the XPC session will be closed. 123 5. If the XPC session is not to be terminated, then the lifecycle 124 repeats from step 3. 126 6. The TCP connection is closed. 128 2. Document Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC2119 [8]. 134 Octet fields with numberic values are given according to the 135 conventions in RFC 1166 [10]: the left most bit of the whole field is 136 the most significant bit; when a multi-octet quantity is transmitted 137 the most significant octet is transmitted first. Bits signifying 138 flags in an octet are numbered according to the conventions of RFC 139 1166 [10]: bit 0 is the most significant bit and bit 7 is the least 140 significant bit. When a diagram describes a group of octets, the 141 order of tranmission for the octets starts from the left. 143 3. Request Block (RQB) 145 The format for the request block (RQB) is as follows: 147 +--------+-----------+-----------+-------------+ 148 field | header | authority | authority | chunks 1..n | 149 | | length | | | 150 +--------+-----------+-----------+-------------+ 151 octets 1 1 0..255 variable 153 Request Block 155 These fields have the following meanings: 157 o header - as described in Section 5. 159 o authority length - the length of the authority field in this 160 request block 162 o authority - a string of octets describing the authority against 163 which this request is to be executed. See [1] for the definition 164 and description of an authority. The number of octets in this 165 string MUST be no more and no less than the number specified by 166 the authority length. 168 o chunks 1..n - the request data broken into chunks (Section 6). 170 4. Response Blocks 172 There are two types of blocks used by a server to respond to a 173 client. The first type is a response block (RSB) defined in 174 Section 4.1. It is used by a server to respond to request blocks 175 (RQB). The second type is a specialized version of a response block 176 called a connection response block (CRB) defined in Section 4.2. It 177 is sent by a server to a client when a connection is established to 178 initiate protocol negotiation. Conceptually, a CRB is a type of RQB; 179 they share the same format, but a CRB is constrained in conveying 180 only specific information and is only sent at the beginning of the 181 session lifecycle. 183 4.1. Response Block (RSB) 185 The format for the response block (RSB) is as follows: 187 +--------+-------------+ 188 field | header | chunks 1..n | 189 | | | 190 +--------+-------------+ 191 octets 1 variable 193 Response Block 195 These fields have the following meanings: 197 o header - as described in Section 5. 199 o chunks 1..n - the response data broken into chunks (Section 6). 201 Servers SHOULD NOT send an RSB to a client until they have received 202 the entire RQB. Servers that do begin sending an RSB before the 203 reception of the entire RQB must consider that clients will not be 204 expected to start processing the RSB until they have fully sent the 205 RQB, and that the RSB will may fill the clients TCP buffers. 207 4.2. Connection Response Block (CRB) 209 A connection response block (CRB) is a response block sent by a 210 server to a client in response to the client initiating a session. A 211 connection response block has the same format as a response block 212 (RSB) (Section 4.1). The only difference is that it is constrained 213 in one of two ways: 215 1. It contains only one chunk (see Section 6) containing version 216 information (see Section 6.2) and the keep-open (or KO) flag in 217 the block header (see Section 5) has a value of 1 (meaning the 218 connection is not closing). Servers MUST use this type of CRB to 219 indicate service availability. 221 2. It contains only one chunk (see Section 6) containing a system 222 error (see 'system-error' under Section 6.4) and the keep-open 223 (or KO) flag in the block header (see Section 5) has a value of 0 224 (meaning the server will close the connection immediately after 225 sending the CRB). Servers MUST use this type of CRB when they 226 can accept connections but cannot process requests. 228 5. Block Header 230 Each data block starts with a one octet header called the block 231 header. This header has the same format for both request and 232 response data blocks, though some of the bits in the header only have 233 meaning in one type of data block. The bits are ordered according to 234 the convention given in RFC 1166 [10], where bit 0 is the most 235 significant bit and bit 7 is the least significant bit. Each bit in 236 the block header has the following meaning: 238 o bits 0 and 1 - version (V field) - If 0 (both bits are zero), the 239 protocol is the version defined in this document. Otherwise, the 240 rest of the bits in the header and the block may be interpreted as 241 another version. If a server receives a request for a version it 242 does not support, it SHOULD follow the behavior described in 243 Section 8. 245 o bits 2 - keep open (KO flag) - This flag is used to request that a 246 connection stay open by a client and to indicate that a connection 247 will stay open by a server, depending on the type of block. In a 248 request block (RQB): a value of 1 indicates that a client is 249 requesting that the server not close the TCP session, and a value 250 of 0 indicates the client will expect ther server to close the TCP 251 session immediately after sending the corresponding response. In 252 a response block (RSB) or a connection response block (CRB): a 253 value of 1 indicates that the server expects the client to keep 254 the TCP session open for the server to receive another request, 255 and a value of 0 indicates that the server expects the client to 256 close the TCP session immediately following this block. 258 o bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0. If a server 259 receives a request in which any of these bits is set to 1 and the 260 server does not understand the purpose for the value, the server 261 SHOULD follow the behavior described in Section 8. 263 +---------+-----------+----------+ 264 field | Version | Keep Open | reserved | 265 | (V) | (KO) | | 266 +---------+-----------+----------+ 267 bits 0 and 1 2 3 - 7 269 Block Header 271 6. Chunks 273 Request and response blocks break the request and response XML data 274 down into chunks. Request and response blocks MUST always have a 275 minimum of 1 chunk. Each chunk has a one octet descriptor. The 276 first bit of the descriptor determines if chunk is the last chunk in 277 the block. 279 The bits of the chunk descriptor octet are ordered according to 280 convention given in RFC 1166 [10], where bit 0 is the most 281 significant bit and bit 7 is the least significant bit. The bits of 282 the chunk descriptor octet have the following meaning: 284 o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk 285 in the block. 287 o bit 1 - data complete (DC flag) - If 1, the data in this chunk 288 represents the end of the data for the chunk type given. If this 289 bit is never set to 1 in any chunk descriptor for chunks of the 290 same type in a block, clients and servers MUST NOT assume the data 291 will continue in another block. If the block transitions from one 292 type of chunk to another with out signaling completion of the 293 data, clients and servers MUST assume that the remaining data will 294 not be sent in a remaining chunk. 296 o bits 2, 3, and 4 - reserved - These MUST be 0. 298 o bit 5, 6, and 7 - chunk type (CT field) - determines the type of 299 data carried in the chunk. These are the binary values for the 300 chunk types: 302 * 000 - no data or 'nd' type (see Section 6.1) 304 * 001 - version information or 'vi' type (see Section 6.2) 306 * 010 - size information or 'si' type (see Section 6.3) 308 * 011 - other information or 'oi type (see Section 6.4) 310 * 100 - SASL data or 'sd' type (see Section 6.5) 312 * 101 - authentication success information or 'as' type (see 313 Section 6.6) 315 * 110 - authentication failure information or 'af' type (see 316 Section 6.7) 318 * 111 - application data or 'ad' type (see Section 6.8) 320 +------------+---------------+----------+------------+ 321 field | Last Chunk | Data Complete | reserved | Chunk Type | 322 | (LC) | (DC) | | (CT) | 323 +------------+---------------+----------+------------+ 324 bits 0 1 2 - 4 5 - 7 326 Chunk Descriptor 328 A block MAY have multiple types of chunks, but all chunks of the same 329 type MUST be contingous in a block and MUST be ordered in the block 330 in the order in which their data is to be intepretted. Contiguous 331 chunks must by ordered by type within a block in the following way: 333 1. authentication related chunks - either SASL data chunks (type 334 100), authentication success information chunks (type 101) or 335 authentication failure information chunks (type 110), but not 336 more than one type. During the setup of security mechanisms 337 using these chunks, clients MUST NOT send subsequent requests 338 until they have received either an authentication success or 339 failure chunk. 341 2. data chunks - either no data chunks (type 000) or application 342 data chunks (type 111), but not both. 344 3. information chunks - either version information (type 001) or 345 other information (type 011), but not both. 347 A block MUST have at least one type of the above chunks. 349 The format for a chunk is as follows: 351 +-----------+------------+--------+ 352 field | chunk | chunk data | chunk | 353 | descriptor| length | data | 354 +-----------+------------+--------+ 355 octets 1 2 variable 357 chunk 359 These fields have the following meanings: 361 o chunk descriptor - as described above. 363 o chunk data length - the length of the data of the chunk 364 o chunk data - the data of the chunk 366 6.1. No Data Types 368 Servers and clients MUST ignore data in chunk types labeled no data. 369 There is no requirement for these types of chunks to be zero length. 370 A client MAY send "no data" to a server, and the server MUST respond 371 with either a chunk of the same type or other information 372 (Section 6.4). 374 6.2. Version Information Types 376 Chunks of this type contain XML conformant to the schema specified in 377 [9] and MUST have the element as the root element. 379 In the context of IRIS-XPC, the protocol identifiers for these 380 elements are as follows: 382 o - the value "iris.xpc1" to indicate the 383 protocol specified in this document. 385 o - the XML namespace identifier for IRIS [1]. 387 o - the XML namespace identifier for IRIS registries. 389 In the context of IRIS-XPC, the authentication mechanism identifiers 390 are the SASL mechanism names found in the IANA SASL mechanism 391 registry defined by RFC 4422 [11]. 393 This document defines no extension identifiers. 395 Clients MAY send a block with this type of chunk to a server. These 396 chunks SHOULD be zero length and servers MUST ignore any data in 397 them. When a server receives a chunk of this type, it MUST respond 398 with a chunk of this type. This interchange allows a client to query 399 the version information of a server. 401 The definition of octet size for the 'requestSizeOctets' and 402 'responseSizeOctets' attributes of the element are 403 defined in Section 6.3. 405 6.3. Size Information Types 407 Chunks of this type contain XML conformant to the schema specified in 408 IRIS-COMMON [9] and MUST have the element as the root element. 410 Octet counts provided by this information are defined as the sum of 411 the count of all chunk data of a particular chunk type. For 412 instance, if a XML instance is broken up into chunks of 20, 30, and 413 40 octets, the octet count would be 90 (20 + 30 + 40). 415 Clients MUST NOT send chunks of this type, and servers MAY close down 416 a session using the procedure in Section 8 if a chunk of this type is 417 received. 419 6.4. Other Information Types 421 Chunks of this type contain XML conformant to the schema specified in 422 IRIS-COMMON [9] and MUST have the element as the root 423 element. 425 The values for the 'type' attribute of are as follows: 427 'block-error' - indicates there was an error decoding a block. 428 Servers SHOULD send a block error in the following cases: 430 1. When a request block is received containing a chunk of this 431 type. 433 2. When a request block is received containing authentication 434 success (see Section 6.6) or authentication failure (see 435 Section 6.7) information. 437 3. When a request block is received containing size information 438 (see Section 6.3). 440 4. When reserved bits in the request block are 1. 442 5. When a block has not been received in its entirety and the TCP 443 session has been idle for a specific period of time (i.e. a 444 data block has been received but no terminating chunk for the 445 data block has been recieved). Two minutes is RECOMMENDED for 446 this timeout value. Note, there is a difference between an 447 idle condition due to the incomplete reception of a data block 448 and an idle condition between request/response transactions 449 associated with keeping the session open. For the latter, see 450 Section 7. 452 'data-error' - indicates there was an error parsing data in chunks 453 containing application or SASL data (e.g. XML is not valid in 454 application data). 456 'system-error' - indicates that the receiver cannot process the 457 request due to a condition not related to this protocol. Servers 458 SHOULD send a system-error when they are capable of responding to 459 requests but not capable of processing requests. 461 'authority-error' - indicates that the intended authority 462 specified in the corresponding request is not served by the 463 receiver. Servers SHOULD send an authority error when they 464 receive a request directed to an authority other than those they 465 serve. 467 'idle-timeout' - indicates that an XPC session has been idle for 468 too long. Usage of this value is defined in Section 7. Note, 469 there is a difference between an idle condition due to the 470 incomplete reception of a data block and an idle condition between 471 request/response transactions associated with keeping the session 472 open. For the former, see 'block-error' above. 474 Clients MUST NOT send chunks of this type, and servers MAY close down 475 a session using the procedure in Section 8 if a chunk of this type is 476 received. 478 6.5. SASL Types 480 The SASL chunk type allows clients and servers to exchange SASL data. 482 The format for the data of this type of chunk is as follows: 484 +-----------+-----------+-----------+-----------+ 485 field | mechanism | mechanism | mechanism | mechanism | 486 | name | name | data | data | 487 | length | | length | | 488 +-----------+-----------+-----------+-----------+ 489 octets 1 variable 2 variable 491 SASL Authentication 493 These fields have the following meaning: 495 o mechanism name length - the length of the SASL mechanism name 497 o mechanism - the name of the SASL mechanism as registered in the 498 IANA SASL mechanism registry defined by [11]. 500 o mechanism data length - the length of the SASL data 502 o mechanism data - the data used for SASL 504 These fields MUST NOT span multiple chunks. Therefore it should be 505 noted that SASL data length exceeding the length of the chunk minus 506 the length of SASL profile name minus one is an error. 508 Depending on the nature of the SASL mechansim being used, SASL data 509 is sent from clients to servers and from servers to clients and may 510 require multiple request/response transactions to complete. However, 511 once a SASL exchange is complete and a server can determine 512 authentication status, the server MUST send either authentication 513 success information (see Section 6.6) or authentication failure 514 information (see Section 6.7). 516 When used as an initial challenge response for SASL mechanisms that 517 support such a feature, the mechanism data length may be set to a 518 decimal value of 65,535 an absent initial response. A value of 0 519 indicates an empty initial response. 521 6.6. Authentication Succss Information Types 523 Chunks of this type contain XML conformant to the schema specified in 524 IRIS-COMMON [9] and MUST have the element as 525 the root element. 527 This type of chunk is only sent from a server to a client. If a 528 client sends it to a server, this will result in a block error (see 529 'block-error' in Section 6.4). The usage of this chunk type is 530 defined in Section 6.5. A server MAY close down a session due to 531 reception of this type of chunk using the procedure in Section 8. 533 SASL mechanisms may use the child element to pass back 534 arbitrary binary data as base 64 binary. The absence of this element 535 indicates the absence of such data, where as the presence of the 536 element with no content indicates an empty data set. 538 6.7. Authentication Failure Information Types 540 Chunks of this type contain XML conformant to the schema specified in 541 IRIS-COMMON [9] and MUST have the element as 542 the root element. 544 This type of chunk is only sent from a server to a client. If a 545 client sends it to a server, this will result in a block error (see 546 'block-error' in Section 6.4). The usage of this chunk type is 547 defined in Section 6.5. A server MAY close down a session due to 548 reception of this type of chunk using the procedure in Section 8. 550 6.8. Application Data Types 552 These chunks contain application data. For IRIS, these are IRIS [1] 553 XML instances. 555 7. Idle Sessions 557 An XPC session may become idle between request/response transactions. 558 This can occur when a server honors a client's request to keep the 559 TCP connection running (see the keep-open or KO flag in the block 560 header (Section 5)). Servers are not expected to allow XPC sessions 561 remain idle between requests indefinitely. 563 Clients MUST use the keep-alive feature of TCP to keep the connection 564 active during idle periods. 566 If a server has not received a request block after sending a response 567 block (either RSB or CRB) and the TCP connection fails to keep-alive, 568 it SHOULD do the following: 570 1. Send an unsolicited response block containing an idle timeout 571 error (see 'idle-timeout' in Section 6.4) with the keep-open (or 572 KO) flag in the block header (Section 5) set to a value of 0. 574 2. Close the TCP connection. 576 8. Closing Sessions Due To An Error 578 If a server is to close a session due to an error, it SHOULD do the 579 following: 581 1. Send a response block containing either a block-error or data- 582 error (see Section 6.4) or version information (see Section 6.2) 583 with the keep-open (or KO) flag in the block header (Section 5) 584 set to a value of 0. 586 2. Close the TCP connection. 588 9. Use over TLS 590 XPC may be tunneled over TLS [4] by establishing a TLS session 591 immediately after a TCP session is opened and before any blocks are 592 to be sent. This type of session is known as XPCS. 594 When using TLS, a convention must be established to allow a client to 595 authenticate the validity of a server. XPCS uses the same convention 596 as described by IRIS-BEEP [2]. 598 TLS enables anthentication and confidentiality. 600 Implementers should note that while XPC and XPCS have separate URI 601 scheme names and S-NAPTR application protocol labels, both are 602 identified with the same value in version 603 information chunks (see Section 6.2). 605 10. Update to RFC 3981 607 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 608 the default transport for IRIS. This document revises RFC 3981 and 609 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 610 known port registration is specified in Section 13.5. 612 11. IRIS Transport Mapping Definitions 614 This section lists the definitions required by IRIS [1] for transport 615 mappings. 617 11.1. URI Scheme 619 See Section 13.1 and Section 13.2. 621 11.2. Application Protocol Label 623 See Section 13.3 and Section 13.4. 625 12. Internationalization Considerations 627 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 628 encodings. Use of the XML defined by [9] MUST NOT use any other 629 character encodings other than UTF-8 or UTF-16. 631 13. IANA Considerations 633 13.1. XPC URI Scheme Registration 635 URL scheme name: iris.xpc 637 URL scheme syntax: defined in [1]. 639 Character encoding considerations: as defined in RFC2396 [6]. 641 Intended usage: identifies IRIS XML using chunks over TCP 643 Applications using this scheme: defined in IRIS [1]. 645 Interoperability considerations: n/a 647 Security Considerations: defined in Section 14. 649 Relevant Publications: IRIS [1]. 651 Contact Information: Andrew Newton 653 Author/Change controller: the IESG 655 13.2. XPCS URI Scheme Registration 657 URL scheme name: iris.xpcs 659 URL scheme syntax: defined in [1]. 661 Character encoding considerations: as defined in RFC2396 [6]. 663 Intended usage: identifies IRIS XML using chunks over TLS 665 Applications using this scheme: defined in IRIS [1]. 667 Interoperability considerations: n/a 669 Security Considerations: defined in Section 14. 671 Relevant Publications: IRIS [1]. 673 Contact Information: Andrew Newton 675 Author/Change controller: the IESG 677 13.3. S-NAPTR XPC Registration 679 Application Protocol Label (see [5]): iris.xpc 681 Intended usage: identifies an IRIS server using XPC 683 Interoperability considerations: n/a 685 Security Considerations: defined in Section 14. 687 Relevant Publications: IRIS [1]. 689 Contact Information: Andrew Newton 691 Author/Change controller: the IESG 693 13.4. S-NAPTR XPCS Registration 695 Application Protocol Label (see [5]): iris.xpcs 697 Intended usage: identifies an IRIS server using secure XPCS 699 Interoperability considerations: n/a 701 Security Considerations: defined in Section 14. 703 Relevant Publications: IRIS [1]. 705 Contact Information: Andrew Newton 707 Author/Change controller: the IESG 709 13.5. Well-known TCP Port Registration for XPC 711 Protocol Number: TCP 713 TCP Port Number: TBD by IANA 715 Message Formats, Types, Opcodes, and Sequences: defined in 716 Section 4.2, Section 3, and Section 4.1. 718 Functions: defined in IRIS [1]. 720 Use of Broadcast/Multicast: none 722 Proposed Name: IRIS over XPC 724 Short name: iris.xpc 725 Contact Information: Andrew Newton 727 13.6. Well-known TCP Port Registration for XPCS 729 Protocol Number: TCP 731 TCP Port Number: TBD by IANA 733 Message Formats, Types, Opcodes, and Sequences: defined in Section 9, 734 Section 4.2, Section 3, and Section 4.1. 736 Functions: defined in IRIS [1]. 738 Use of Broadcast/Multicast: none 740 Proposed Name: IRIS over XPCS 742 Short name: iris.xpcs 744 Contact Information: Andrew Newton 746 14. Security Considerations 748 Implementers should be fully aware of the security considerations 749 given by IRIS [1] and TLS [4]. With respect to server authentication 750 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 752 14.1. Security Mechanisms 754 Clients SHOULD be prepared to use the following security mechanisms 755 in the following manner: 757 o SASL/DIGEST-MD5 - for user authentication without the need of 758 session encryption. 760 o SASL/OTP - for user authentication without the need of session 761 encryption. 763 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 764 encryption. 766 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 767 side certificates - for encryption and user authentication. 769 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 770 encryption. See [7]. 772 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 773 certificates - for encryption and user authentication. See [7]. 775 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 776 encryption. See [7]. 778 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 779 certificates - for encryption and user authentication. See [7]. 781 Anonymous client access SHOULD be considered in one of two methods: 783 1. When no authentication has been used. 785 2. Using the SASL anonymous profile: SASL/ANONYMOUS 787 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 788 mechanism without first encrypting the TCP session (e.g. such as with 789 TLS). Clients MUST implement SASL/PLAIN and TLS using 790 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher. 792 14.2. SASL Compliance 794 The following list details the compliance of IRIS-XPC for use with 795 SASL, as specified by RFC 4422 [11], Section 4. 797 1. The SASL service name to be used by IRIS-XPC is "iris-xpc". 799 2. Section 6.2 describes the negotiation facility used to determine 800 the available security mechanisms. This facility may be used 801 both before the initiation of SASL exchanges and after the 802 installation of security mechanisms. 804 3. 806 a) Section 6.5 describes the mechanism to initiate authentication 807 exchanges. 809 b) Section 6.5 describes the mechanism to transfer server 810 challenges and client responses. 812 c) Section 6.6 and Section 6.7 describe the mechanisms to 813 indicate the outcome of an authentication exchange. 814 Section 6.6 describes how additional data may be carried with 815 this message. 817 4. Non-empty authorization identity strings usign within IRIS-XPC 818 MUST be normalized according to RFC 4013 [12]. The semantics of 819 the non-empty authorization identity strings is server dependent, 820 and clients MUST use the values for these strings as given by 821 configuration or the user. 823 5. Clients or servers wishing to abort an ongoing authentication 824 exchange MUST close the connection. 826 6. After new security layers are negotiated, they take effect on the 827 first octet following the authentication success (as) 828 (Section 6.6) chunk sent by the server and on the first octet 829 sent after receipt of the authentication success (as) chunk sent 830 by the client. 832 7. IRIS-XPC can be used with both TLS and SASL. When used in 833 combination, TLS MUST always be applied before any SASL 834 mechanism. 836 8. IRIS-XPC does not support multiple SASL authentications. 837 However, if TLS is being used in combination with SASL, TLS 838 authentication MUST occur before any SASL authentication. 840 15. Normative References 842 [1] Newton, A. and M. Sanz, "Internet Registry Information 843 Service", RFC 3981, January 2004. 845 [2] Newton, A. and M. Sanz, "Using the Internet Registry 846 Information Service over the Blocks Extensible Exchange 847 Protocol", RFC 3983, January 2004. 849 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 850 ISBN 0-201-61633-5, 2000, . 852 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 853 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 854 January 1999. 856 [5] Daigle, L. and A. Newton, "Domain-Based Application Service 857 Location Using SRV RRs and the Dynamic Delegation Discovery 858 Service (DDDS)", RFC 3958, January 2005. 860 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 861 Resource Identifiers (URI): Generic Syntax", RFC 2396, 862 August 1998. 864 [7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 865 Transport Layer Security (TLS)", RFC 3268, June 2002. 867 [8] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", RFC 2119, BCP 14, March 1997. 870 [9] Newton, A., "A Common Schema for Internet Registry Information 871 Service Transfer Protocols", 872 draft-ietf-crips-iris-common-transport-00 (work in progress), 873 April 2005. 875 [10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 876 RFC 1166, July 1990. 878 [11] Melnikov, A. and K. Zeilenga, "Simple Authentication and 879 Security Layer (SASL)", RFC 4422, June 2006. 881 [12] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and 882 Passwords", RFC 4013, February 2005. 884 Appendix A. Examples 886 This section gives examples of IRIS-XPC sessions. Lines beginning 887 with "C:" denote data sent by the client to the server, and lines 888 beginning with "S:" denote data sent by the server to the client. 889 Following the "C:" or "S:", the line either contains octet values in 890 hexadecimal notation with comments or XML fragments. No line 891 contains both octet values with comments and XML fragments. Comments 892 are contained within parenthesis. 894 It should also be noted that flag values of "yes" and "no" reflect 895 binary values 1 and 0. 897 The following example demonstrates an IRIS client issuing two 898 requests in one XPC session. In the first request, the client is 899 requesting status information for "example.com". This request and 900 its response are transfered with one chunk. In the second request, 901 the client is requesting status information for "milo.example.com", 902 "felix.example.com", and "hobbes.example.com". This request and its 903 response are transfered with three chunks. 905 S: (connection response block) 906 S: 0x20 (block header: V=0,KO=yes) 907 S: (chunk 1) 908 S: 0xC1 (LC=yes,DC=yes,CT=vi) 909 S: 0x01 0xBF (chunk length=447) 910 S: (Version Information) 911 S: 912 S: 913 S: 915 S: 917 S: 918 S: 919 S: 920 S: 921 S: 923 C: (request block) 924 C: 0x20 (block header: V=0,KO=yes) 925 C: 0x0B (authority length=11) 926 C: (authority="example.com") 927 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 928 C: (chunk 1) 929 C: 0xC7 (LC=yes,DC=yes,CT=ad) 930 C: 0x01 0x53 (chunk length=339) 931 C: (IRIS XML request) 932 C: 934 C: 935 C: 939 C: 940 C: 942 S: (response block) 943 S: 0x20 (block header: V=0,KO=yes) 944 S: (chunk 1) 945 S: 0xC7 (LC=yes,DC=yes,CT=ad) 946 S: 0x01 0xE0 (chunk length=480) 947 S: (IRIS XML response) 948 S: 949 S: 950 S: 951 S: 955 S: example.com 956 S: 957 S: 958 S: 959 S: 960 S: 961 S: 962 S: 964 C: (request block) 965 C: 0x00 (block header: V=0,KO=no) 966 C: 0x0B (authority length=11) 967 C: (authority="example.com") 968 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 969 C: (chunk 1) 970 C: 0x07 (LC=no,DC=no,CT=ad) 971 C: 0x01 0x4E (chunk length=339) 972 C: (IRIS XML request) 973 C: 976 C: 977 C: 981 C: 982 C: (chunk 2) 983 C: 0x07 (LC=no,DC=no,CT=ad) 984 C: 0x00 0xA9 (chunk length=169) 985 C: (IRIS XML request) 986 C: 987 C: 991 C: 992 C: (chunk 3) 993 C: 0xC7 (LC=yes,DC=yes,CT=ad) 994 C: 0x00 0xB5 (chunk length=181) 995 C: (IRIS XML request) 996 C: 997 C: 1001 C: 1002 C: 1004 S: (response block) 1005 S: 0x00 (block header: V=0,KO=no) 1006 S: (chunk 1) 1007 S: 0x07 (LC=no,DC=no,CT=ad) 1008 S: 0x01 0xDA (chunk length=474) 1009 S: (IRIS XML response) 1010 S: 1011 S: 1012 S: 1013 S: 1017 S: milo.example.com 1018 S: 1019 S: 1020 S: 1021 S: 1022 S: 1023 S: 1024 S: (chunk 2) 1025 S: 0x07 (LC=no,DC=no,CT=ad) 1026 S: 0x01 0xA2 (chunk length=418) 1027 S: (IRIS XML response) 1028 S: 1029 S: 1030 S: 1034 S: felix.example.com 1035 S: 1036 S: 1037 S: 1038 S: 1039 S: 1040 S: 1041 S: (chunk 3) 1042 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1043 S: 0x01 0xB5 (chunk length=437) 1044 S: (IRIS XML response) 1045 S: 1046 S: 1047 S: 1052 S: hobbes.example.com 1053 S: 1054 S: 1055 S: 1056 S: 1057 S: 1058 S: 1059 S: 1061 Figure 7: Example 1 1063 In the following example, an IRIS client requests domain status 1064 information for "milo.example.com", "felix.example.com", and 1065 "hobbes.example.com" in one request. The request is sent with one 1066 chunk, however the answer is returned in three chunks. 1068 S: (connection response block) 1069 S: 0x20 (block header: V=0,KO=yes) 1070 S: (chunk 1) 1071 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1072 S: 0x01 0xBF (chunk length=447) 1073 S: (Version Information) 1074 S: 1075 S: 1076 S: 1078 S: 1080 S: 1081 S: 1082 S: 1083 S: 1084 S: 1086 C: (request block) 1087 C: 0x00 (block header: V=0,KO=no) 1088 C: 0x0B (authority length=11) 1089 C: (authority="example.com") 1090 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1091 C: (chunk 1) 1092 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1093 C: 0x02 0xAB (chunk length=683) 1094 C: (IRIS XML request) 1095 C: 1098 C: 1099 C: 1103 C: 1104 C: 1105 C: 1109 C: 1110 C: 1111 C: 1115 C: 1116 C: 1118 S: (response block) 1119 S: 0x00 (block header: V=0,KO=no) 1120 S: (chunk 1) 1121 S: 0x07 (LC=no,DC=no,CT=ad) 1122 S: 0x01 0xDA (chunk length=474) 1123 S: (IRIS XML response) 1124 S: 1125 S: 1126 S: 1127 S: 1131 S: milo.example.com 1132 S: 1133 S: 1134 S: 1135 S: 1136 S: 1137 S: 1138 S: (chunk 2) 1139 S: 0x07 (LC=no,DC=no,CT=ad) 1140 S: 0x01 0xA2 (chunk length=418) 1141 S: (IRIS XML response) 1142 S: 1143 S: 1144 S: 1148 S: felix.example.com 1149 S: 1150 S: 1151 S: 1152 S: 1153 S: 1154 S: 1155 S: (chunk 3) 1156 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1157 S: 0x01 0xB5 (chunk length=437) 1158 S: (IRIS XML response) 1159 S: 1160 S: 1161 S: 1166 S: hobbes.example.com 1167 S: 1168 S: 1169 S: 1170 S: 1171 S: 1172 S: 1173 S: 1175 Figure 8: Example 2 1177 In the following example, an IRIS client sends a request containg 1178 SASL/PLAIN authentication data and a domain status check for 1179 "example.com". The server responds with authentication succss 1180 information and the domain status of "example.com". Note that the 1181 client requests that the connection stay open for further requests, 1182 but that the server does not honor this request. 1184 S: (connection response block) 1185 S: 0x20 (block header: V=0,KO=yes) 1186 S: (chunk 1) 1187 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1188 S: 0x01 0xBF (chunk length=447) 1189 S: (Version Information) 1190 S: 1191 S: 1192 S: 1194 S: 1196 S: 1197 S: 1198 S: 1199 S: 1200 S: 1202 C: (request block) 1203 C: 0x00 (block header: V=0,KO=no) 1204 C: 0x0B (authority length=11) 1205 C: (authority="example.com") 1206 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1207 C: (chunk 1) 1208 C: 0x44 (LC=no,DC=yes,CT=sd) 1209 C: 0x00 0x11 (chunk length=11) 1210 C: (SASL data) 1211 C: 0x05 (mechanism length=5) 1212 C: (mechanism name="PLAIN") 1213 C: 0x50 0x4C 0x41 0x49 0x43 1214 C: 0x00 0x0A (sasl PLAIN data length=10) 1215 C: (sasl PLAIN data: authcid="bob") 1216 C: (sasl PLAIN data: authzid=NULL) 1217 C: (sasl PLAIN data: password="kEw1") 1218 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1219 C: (chunk 2) 1220 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1221 C: 0x01 0x53 (chunk length=339) 1222 C: (IRIS XML request) 1223 C: 1225 C: 1226 C: 1230 C: 1231 C: 1233 S: (response block) 1234 S: 0x00 (block header: V=0,KO=no) 1235 S: (chunk 1) 1236 S: 0x45 (LC=no,DC=yes,CT=as) 1237 S: 0x00 0xD0 (chunk length=208) 1238 S: (authentication success response) 1239 S: 1240 S: 1242 S: 1243 S: user 'bob' authenticates via password 1244 S: 1245 S: 1246 S: (chunk 2) 1247 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1248 S: 0x01 0xE0 (chunk length=480) 1249 S: (IRIS XML response) 1250 S: 1251 S: 1252 S: 1253 S: 1257 S: example.com 1258 S: 1259 S: 1260 S: 1261 S: 1262 S: 1263 S: 1264 S: 1266 Figure 9: Example 3 1268 Appendix B. Contributors 1270 Substantive contributions to this document have been provided by the 1271 members of the IETF's CRISP Working Group, especially Robert Martin- 1272 Legene, Milena Caires, and David Blacka. 1274 Author's Address 1276 Andrew L. Newton 1277 VeriSign, Inc. 1278 21345 Ridgetop Circle 1279 Sterling, VA 20166 1280 USA 1282 Phone: +1 703 948 3382 1283 Email: andy@hxr.us 1284 URI: http://www.verisignlabs.com/ 1286 Full Copyright Statement 1288 Copyright (C) The IETF Trust (2007). 1290 This document is subject to the rights, licenses and restrictions 1291 contained in BCP 78, and except as set forth therein, the authors 1292 retain all their rights. 1294 This document and the information contained herein are provided on an 1295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1297 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1298 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1299 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1302 Intellectual Property 1304 The IETF takes no position regarding the validity or scope of any 1305 Intellectual Property Rights or other rights that might be claimed to 1306 pertain to the implementation or use of the technology described in 1307 this document or the extent to which any license under such rights 1308 might or might not be available; nor does it represent that it has 1309 made any independent effort to identify any such rights. Information 1310 on the procedures with respect to rights in RFC documents can be 1311 found in BCP 78 and BCP 79. 1313 Copies of IPR disclosures made to the IETF Secretariat and any 1314 assurances of licenses to be made available, or the result of an 1315 attempt made to obtain a general license or permission for the use of 1316 such proprietary rights by implementers or users of this 1317 specification can be obtained from the IETF on-line IPR repository at 1318 http://www.ietf.org/ipr. 1320 The IETF invites any interested party to bring to its attention any 1321 copyrights, patents or patent applications, or other proprietary 1322 rights that may cover technology that may be required to implement 1323 this standard. Please address the information to the IETF at 1324 ietf-ipr@ietf.org. 1326 Acknowledgment 1328 Funding for the RFC Editor function is provided by the IETF 1329 Administrative Support Activity (IASA).