idnits 2.17.1 draft-ietf-crisp-iris-xpc-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1266. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 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 RFC 3978 Section 5.4 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 (January 9, 2007) is 6309 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: 8 errors (**), 0 flaws (~~), 2 warnings (==), 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) January 9, 2007 5 Expires: July 13, 2007 7 XML Pipelining with Chunks for the Information Registry Information 8 Service 9 draft-ietf-crisp-iris-xpc-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 13, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 This document describes a simple TCP transfer protocol for the 43 Internet Registry Information Service (IRIS). Data is transfered 44 between clients and servers using chunks to achieve pipelining. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 50 3. Request Block (RQB) . . . . . . . . . . . . . . . . . . . . . 5 51 4. Response Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 52 4.1. Response Block (RSB) . . . . . . . . . . . . . . . . . . . 6 53 4.2. Connection Response Block (CRB) . . . . . . . . . . . . . 6 54 5. Block Header . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.1. No Data Types . . . . . . . . . . . . . . . . . . . . . . 10 57 6.2. Version Information Types . . . . . . . . . . . . . . . . 11 58 6.3. Size Information Types . . . . . . . . . . . . . . . . . . 11 59 6.4. Other Information Types . . . . . . . . . . . . . . . . . 12 60 6.5. SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 13 61 6.6. Authentication Succss Information Types . . . . . . . . . 14 62 6.7. Authentication Failure Information Types . . . . . . . . . 14 63 6.8. Application Data Types . . . . . . . . . . . . . . . . . . 14 64 7. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . . 15 65 8. Closing Sessions Due To An Error . . . . . . . . . . . . . . . 16 66 9. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 10. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . . 18 68 11. IRIS Transport Mapping Definitions . . . . . . . . . . . . . . 19 69 11.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 19 70 11.2. Application Protocol Label . . . . . . . . . . . . . . . . 19 71 12. Internationalization Considerations . . . . . . . . . . . . . 20 72 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 13.1. XPC URI Scheme Registration . . . . . . . . . . . . . . . 21 74 13.2. XPCS URI Scheme Registration . . . . . . . . . . . . . . . 21 75 13.3. S-NAPTR XPC Registration . . . . . . . . . . . . . . . . . 22 76 13.4. S-NAPTR XPCS Registration . . . . . . . . . . . . . . . . 22 77 13.5. Well-known TCP Port Registration for XPC . . . . . . . . . 22 78 13.6. Well-known TCP Port Registration for XPCS . . . . . . . . 23 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 14.1. Security Mechanisms . . . . . . . . . . . . . . . . . . . 24 81 14.2. SASL Compliance . . . . . . . . . . . . . . . . . . . . . 24 82 15. Normative References . . . . . . . . . . . . . . . . . . . . . 25 83 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27 84 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 35 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 86 Intellectual Property and Copyright Statements . . . . . . . . . . 37 88 1. Introduction 90 Using S-NAPTR [5], IRIS has the ability to define the use of multiple 91 application transports (or transfer protocols) for different types of 92 registry services, all at the descretion of the server operator. The 93 TCP transfer protocol defined in this document is completely modular 94 and may be used by any registry types. 96 This transfer protocol defines simple framing for sending XML in 97 chunks so that XML fragments may be acted upon (or pipelined) before 98 the reception of the entire XML instance. This document calls this 99 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 101 XPC is for use with simple request and response interactions between 102 clients and servers. Clients send a series of requests to a server 103 in data blocks. The server will respond to each data block 104 individually with a corresponding data block, but through the same 105 connection. Request and response data blocks are sent using the TCP 106 SEND function and received using the TCP RECEIVE function. 108 The lifecycle of an XPC session has the following phases: 110 1. A client establishes a TCP connection with a server. 112 2. The server sends a connection response block (CRB). 114 3. The client sends a request block (RQB). In this request, the 115 client can set a "keep open" flag requesting that the server keep 116 the XPC session open following the response to this request. 118 4. The server responds with a response block (RSB). In this 119 response, the server can indicate to the client whether or not 120 the XPC session will be closed. 122 5. If the XPC session is not to be terminated, then the lifecycle 123 repeats from step 3. 125 6. The TCP connection is closed. 127 2. Document Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC2119 [8]. 133 Octet fields with numberic values are given according to the 134 conventions in RFC 1166 [10]: the left most bit of the whole field is 135 the most significant bit; when a multi-octet quantity is transmitted 136 the most significant octet is transmitted first. Bits signifying 137 flags in an octet are numbered according to the conventions of RFC 138 1166 [10]: bit 0 is the most significant bit and bit 7 is the least 139 significant bit. When a diagram describes a group of octets, the 140 order of tranmission for the octets starts from the left. 142 3. Request Block (RQB) 144 The format for the request block (RQB) is as follows: 146 +--------+-----------+-----------+-------------+ 147 field | header | authority | authority | chunks 1..n | 148 | | length | | | 149 +--------+-----------+-----------+-------------+ 150 octets 1 1 0..255 variable 152 These fields have the following meanings: 154 o header - as described in Section 5. 156 o authority length - the length of the authority field in this 157 request block 159 o authority - a string of octets describing the authority against 160 which this request is to be executed. See [1] for the definition 161 and description of an authority. The number of octets in this 162 string MUST be no more and no less than the number specified by 163 the authority length. 165 o chunks 1..n - the request data broken into chunks (Section 6). 167 4. Response Blocks 169 There are two types of blocks used by a server to respond to a 170 client. The first type is a response block (RSB) defined in 171 Section 4.1. It is used by a server to respond to request blocks 172 (RQB). The second type is a specialized version of a response block 173 called a connection response block (CRB) defined in Section 4.2. It 174 is sent by a server to a client when a connection is established to 175 initiate protocol negotiation. Conceptually, a CRB is a type of RQB; 176 they share the same format, but a CRB is constrained in conveying 177 only specific information and is only sent at the beginning of the 178 session lifecycle. 180 4.1. Response Block (RSB) 182 The format for the response block (RSB) is as follows: 184 +--------+-------------+ 185 field | header | chunks 1..n | 186 | | | 187 +--------+-------------+ 188 octets 1 variable 190 These fields have the following meanings: 192 o header - as described in Section 5. 194 o chunks 1..n - the response data broken into chunks (Section 6). 196 Servers SHOULD NOT send an RSB to a client until they have received 197 the entire RQB. Servers that do begin sending an RSB before the 198 reception of the entire RQB must consider that clients will not be 199 expected to start processing the RSB until they have fully sent the 200 RQB, and that the RSB will may fill the clients TCP buffers. 202 4.2. Connection Response Block (CRB) 204 A connection response block (CRB) is a response block sent by a 205 server to a client in response to the client initiating a session. A 206 connection response block has the same format as a response block 207 (RSB) (Section 4.1). The only difference is that it is constrained 208 in one of two ways: 210 1. It contains only one chunk (see Section 6) containing version 211 information (see Section 6.2) and the keep-open (or KO) flag in 212 the block header (see Section 5) has a value of 1 (meaning the 213 connection is not closing). Servers MUST use this type of CRB to 214 indicate service availability. 216 2. It contains only one chunk (see Section 6) containing a system 217 error (see 'system-error' under Section 6.4) and the keep-open 218 (or KO) flag in the block header (see Section 5) has a value of 0 219 (meaning the server will close the connection immediately after 220 sending the CRB). Servers MUST use this type of CRB when they 221 can accept connections but cannot process requests. 223 5. Block Header 225 Each data block starts with a one octet header called the block 226 header. This header has the same format for both request and 227 response data blocks, though some of the bits in the header only have 228 meaning in one type of data block. The bits are ordered according to 229 the convention given in RFC 1166 [10], where bit 0 is the most 230 significant bit and bit 7 is the least significant bit. Each bit in 231 the block header has the following meaning: 233 o bits 0 and 1 - version (V field) - If 0 (both bits are zero), the 234 protocol is the version defined in this document. Otherwise, the 235 rest of the bits in the header and the block may be interpreted as 236 another version. 238 o bits 2 - keep open (KO flag) - This flag is used to request that a 239 connection stay open by a client and to indicate that a connection 240 will stay open by a server, depending on the type of block. In a 241 request block (RQB): a value of 1 indicates that a client is 242 requesting that the server not close the TCP session, and a value 243 of 0 indicates the client will expect ther server to close the TCP 244 session immediately after sending the corresponding response. In 245 a response block (RSB) or a connection response block (CRB): a 246 value of 1 indicates that the server will keep the TCP session 247 open to receive another request, and a value of 0 indicates that 248 the server will close the TCP session immediately following this 249 block. 251 o bit 3, 4, 5, 6, and 7 - reserved - These MUST be 0. 253 +---------+-----------+----------+ 254 field | Version | Keep Open | reserved | 255 | (V) | (KO) | | 256 +---------+-----------+----------+ 257 bits 0 and 1 2 3 - 7 259 6. Chunks 261 Request and response blocks break the request and response XML data 262 down into chunks. Request and response blocks MUST always have a 263 minimum of 1 chunk. Each chunk has a one octet descriptor. The 264 first bit of the descriptor determines if chunk is the last chunk in 265 the block. 267 The bits of the chunk descriptor octet are ordered according to 268 convention given in RFC 1166 [10], where bit 0 is the most 269 significant bit and bit 7 is the least significant bit. The bits of 270 the chunk descriptor octet have the following meaning: 272 o bit 0 - last chunk (LC flag) - If 1, this chunk is the last chunk 273 in the block. 275 o bit 1 - data complete (DC flag) - If 1, the data in this chunk 276 represents the end of the data for the chunk type given. If this 277 bit is never set to 1 in any chunk descriptor for chunks of the 278 same type in a block, clients and servers MUST NOT assume the data 279 will continue in another block. If the block transitions from one 280 type of chunk to another with out signaling completion of the 281 data, clients and servers MUST assume that the remaining data will 282 not be sent in a remaining chunk. 284 o bits 2, 3, and 4 - reserved - These MUST be 0. 286 o bit 5, 6, and 7 - chunk type (CT field) - determines the type of 287 data carried in the chunk. These are the binary values for the 288 chunk types: 290 * 000 - no data or 'nd' type (see Section 6.1) 292 * 001 - version information or 'vi' type (see Section 6.2) 294 * 010 - size information or 'si' type (see Section 6.3) 296 * 011 - other information or 'oi type (see Section 6.4) 298 * 100 - SASL data or 'sd' type (see Section 6.5) 300 * 101 - authentication success information or 'as' type (see 301 Section 6.6) 303 * 110 - authentication failure information or 'af' type (see 304 Section 6.7) 306 * 111 - application data or 'ad' type (see Section 6.8) 308 +------------+---------------+----------+------------+ 309 field | Last Chunk | Data Complete | reserved | Chunk Type | 310 | (LC) | (DC) | | (CT) | 311 +------------+---------------+----------+------------+ 312 bits 0 1 2 - 4 5 - 7 314 A block MAY have multiple types of chunks, but all chunks of the same 315 type MUST be contingous in a block and MUST be ordered in the block 316 in the order in which their data is to be intepretted. Contiguous 317 chunks must by ordered by type within a block in the following way: 319 1. authentication related chunks - either SASL data chunks (type 320 100), authentication success information chunks (type 101) or 321 authentication failure information chunks (type 110), but not 322 more than one type 324 2. data chunks - either no data chunks (type 000) or application 325 data chunks (type 111), but not both. 327 3. information chunks - either version information (type 001) or 328 other information (type 011), but not both. 330 A block MUST have at least one type of the above chunks. 332 The format for a chunk is as follows: 334 +-----------+------------+--------+ 335 field | chunk | chunk data | chunk | 336 | descriptor| length | data | 337 +-----------+------------+--------+ 338 octets 1 2 variable 340 These fields have the following meanings: 342 o chunk descriptor - as described above. 344 o chunk data length - the length of the data of the chunk 346 o chunk data - the data of the chunk 348 6.1. No Data Types 350 Servers and clients MUST ignore data in chunk types labeled no data. 351 There is no requirement for these types of chunks to be zero length. 352 A client MAY send "no data" to a server, and the server MUST respond 353 with either a chunk of the same type or other information 354 (Section 6.4). 356 6.2. Version Information Types 358 Chunks of this type contain XML conformant to the schema specified in 359 [9] and MUST have the element as the root element. 361 In the context of IRIS-XPC, the protocol identifiers for these 362 elements are as follows: 364 o - the value "iris.xpc1" to indicate the 365 protocol specified in this document. 367 o - the XML namespace identifier for IRIS [1]. 369 o - the XML namespace identifier for IRIS registries. 371 In the context of IRIS-XPC, the authentication mechanism identifiers 372 are the SASL mechanism names found in the IANA SASL mechanism 373 registry defined by RFC 4422 [11]. 375 This document defines no extension identifiers. 377 Clients MAY send a block with this type of chunk to a server. These 378 chunks SHOULD be zero length and servers MUST ignore any data in 379 them. When a server receives a chunk of this type, it MUST respond 380 with a chunk of this type. This interchange allows a client to query 381 the version information of a server. 383 The definition of octet size for the 'requestSizeOctets' and 384 'responseSizeOctets' attributes of the element are 385 defined in Section 6.3. 387 6.3. Size Information Types 389 Chunks of this type contain XML conformant to the schema specified in 390 IRIS-COMMON [9] and MUST have the element as the root element. 392 Octet counts provided by this information are defined as the sum of 393 the count of all chunk data of a particular chunk type. For 394 instance, if a XML instance is broken up into chunks of 20, 30, and 395 40 octets, the octet count would be 90 (20 + 30 + 40). 397 Clients MUST NOT send chunks of this type, and servers MAY close down 398 a session using the procedure in Section 8 if a chunk of this type is 399 received. 401 6.4. Other Information Types 403 Chunks of this type contain XML conformant to the schema specified in 404 IRIS-COMMON [9] and MUST have the element as the root 405 element. 407 The values for the 'type' attribute of are as follows: 409 'block-error' - indicates there was an error decoding a block. 410 Servers SHOULD send a block error in the following cases: 412 1. When a request block is received containing a chunk of this 413 type. 415 2. When a request block is received containing authentication 416 success (see Section 6.6) or authentication failure (see 417 Section 6.7) information. 419 3. When a request block is received containing size information 420 (see Section 6.3). 422 4. When reserved bits in the request block are 1. 424 5. When a block has not been received in its entirety and the TCP 425 session has been idle for a specific period of time (i.e. a 426 data block has been received but no terminating chunk for the 427 data block has been recieved). Two minutes is RECOMMENDED for 428 this timeout value. Note, there is a difference between an 429 idle condition due to the incomplete reception of a data block 430 and an idle condition between request/response transactions 431 associated with keeping the session open. For the latter, see 432 Section 7. 434 'data-error' - indicates there was an error parsing data in chunks 435 containing application or SASL data (e.g. XML is not valid in 436 application data). 438 'system-error' - indicates that the receiver cannot process the 439 request due to a condition not related to this protocol. Servers 440 SHOULD send a system-error when they are capable of responding to 441 requests but not capable of processing requests. 443 'authority-error' - indicates that the intended authority 444 specified in the corresponding request is not served by the 445 receiver. Servers SHOULD send an authority error when they 446 receive a request directed to an authority other than those they 447 serve. 449 'idle-timeout' - indicates that an XPC session has been idle for 450 too long. Usage of this value is defined in Section 7. Note, 451 there is a difference between an idle condition due to the 452 incomplete reception of a data block and an idle condition between 453 request/response transactions associated with keeping the session 454 open. For the former, see 'block-error' above. 456 Clients MUST NOT send chunks of this type, and servers MAY close down 457 a session using the procedure in Section 8 if a chunk of this type is 458 received. 460 6.5. SASL Types 462 The SASL chunk type allows clients and servers to exchange SASL data. 464 The format for the data of this type of chunk is as follows: 466 +-----------+-----------+-----------+-----------+ 467 field | mechanism | mechanism | mechanism | mechanism | 468 | name | name | data | data | 469 | length | | length | | 470 +-----------+-----------+-----------+-----------+ 471 octets 1 variable 2 variable 473 These fields have the following meaning: 475 o mechanism name length - the length of the SASL mechanism name 477 o mechanism - the name of the SASL mechanism as registered in the 478 IANA SASL mechanism registry defined by [11]. 480 o mechanism data length - the length of the SASL data 482 o mechanism data - the data used for SASL 484 These fields MUST NOT span multiple chunks. Therefore it should be 485 noted that SASL data length exceeding the length of the chunk minus 486 the length of SASL profile name minus one is an error. 488 Depending on the nature of the SASL mechansim being used, SASL data 489 is sent from clients to servers and from servers to clients and may 490 require multiple request/response transactions to complete. However, 491 once a SASL exchange is complete and a server can determine 492 authentication status, the server MUST send either authentication 493 success information (see Section 6.6) or authentication failure 494 information (see Section 6.7). 496 6.6. Authentication Succss Information Types 498 Chunks of this type contain XML conformant to the schema specified in 499 IRIS-COMMON [9] and MUST have the element as 500 the root element. 502 This type of chunk is only sent from a server to a client. If a 503 client sends it to a server, this will result in a block error (see 504 'block-error' in Section 6.4). The usage of this chunk type is 505 defined in Section 6.5. A server MAY close down a session due to 506 reception of this type of chunk using the procedure in Section 8. 508 6.7. Authentication Failure Information Types 510 Chunks of this type contain XML conformant to the schema specified in 511 IRIS-COMMON [9] and MUST have the element as 512 the root element. 514 This type of chunk is only sent from a server to a client. If a 515 client sends it to a server, this will result in a block error (see 516 'block-error' in Section 6.4). The usage of this chunk type is 517 defined in Section 6.5. A server MAY close down a session due to 518 reception of this type of chunk using the procedure in Section 8. 520 6.8. Application Data Types 522 These chunks contain application data. For IRIS, these are IRIS [1] 523 XML instances. 525 7. Idle Sessions 527 An XPC session may become idle between request/response transactions. 528 This can occur when a server honors a client's request to keep the 529 TCP connection running (see the keep-open or KO flag in the block 530 header (Section 5)). Servers are not expected to allow XPC sessions 531 remain idle between requests indefinitely. 533 Clients MUST send no less than 1 request every 2 minutes. This can 534 be any type of request specified by this document. If a client has 535 no need to send a specific type of request but must send a request to 536 fulfill this obligation, sending a request block containing one chunk 537 of "no data" (see Section 6.1) with a length of zero is RECOMMENDED. 539 If a server has not received a request block 5 minutes after sending 540 a response block (either RSB or CRB), it SHOULD do the following: 542 1. Send an unsolicited response block containing an idle timeout 543 error (see 'idle-timeout' in Section 6.4) with the keep-open (or 544 KO) flag in the block header (Section 5) set to a value of 0. 546 2. Close the TCP connection. 548 8. Closing Sessions Due To An Error 550 If a server is to close a session due to an error, it SHOULD do the 551 following: 553 1. Send a response block containing either a block-error or data- 554 error (see Section 6.4) with the keep-open (or KO) flag in the 555 block header (Section 5) set to a value of 0. 557 2. Close the TCP connection. 559 9. Use over TLS 561 XPC may be tunneled over TLS [4] by establishing a TLS session 562 immediately after a TCP session is opened and before any blocks are 563 to be sent. This type of session is known as XPCS. 565 When using TLS, a convention must be established to allow a client to 566 authenticate the validity of a server. XPCS uses the same convention 567 as described by IRIS-BEEP [2]. 569 TLS enables anthentication and confidentiality. 571 10. Update to RFC 3981 573 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 574 the default transport for IRIS. This document revises RFC 3981 and 575 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 576 known port registration is specified in Section 13.5. 578 11. IRIS Transport Mapping Definitions 580 This section lists the definitions required by IRIS [1] for transport 581 mappings. 583 11.1. URI Scheme 585 See Section 13.1 and Section 13.2. 587 11.2. Application Protocol Label 589 See Section 13.3 and Section 13.4. 591 12. Internationalization Considerations 593 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 594 encodings. Use of the XML defined by [9] MUST NOT use any other 595 character encodings other than UTF-8 or UTF-16. 597 13. IANA Considerations 599 13.1. XPC URI Scheme Registration 601 URL scheme name: iris.xpc 603 URL scheme syntax: defined in [1]. 605 Character encoding considerations: as defined in RFC2396 [6]. 607 Intended usage: identifies IRIS XML using chunks over TCP 609 Applications using this scheme: defined in IRIS [1]. 611 Interoperability considerations: n/a 613 Security Considerations: defined in Section 14. 615 Relevant Publications: IRIS [1]. 617 Contact Information: Andrew Newton 619 Author/Change controller: the IESG 621 13.2. XPCS URI Scheme Registration 623 URL scheme name: iris.xpcs 625 URL scheme syntax: defined in [1]. 627 Character encoding considerations: as defined in RFC2396 [6]. 629 Intended usage: identifies IRIS XML using chunks over TLS 631 Applications using this scheme: defined in IRIS [1]. 633 Interoperability considerations: n/a 635 Security Considerations: defined in Section 14. 637 Relevant Publications: IRIS [1]. 639 Contact Information: Andrew Newton 641 Author/Change controller: the IESG 643 13.3. S-NAPTR XPC Registration 645 Application Protocol Label (see [5]): iris.xpc 647 Intended usage: identifies an IRIS server using XPC 649 Interoperability considerations: n/a 651 Security Considerations: defined in Section 14. 653 Relevant Publications: IRIS [1]. 655 Contact Information: Andrew Newton 657 Author/Change controller: the IESG 659 13.4. S-NAPTR XPCS Registration 661 Application Protocol Label (see [5]): iris.xpcs 663 Intended usage: identifies an IRIS server using secure XPCS 665 Interoperability considerations: n/a 667 Security Considerations: defined in Section 14. 669 Relevant Publications: IRIS [1]. 671 Contact Information: Andrew Newton 673 Author/Change controller: the IESG 675 13.5. Well-known TCP Port Registration for XPC 677 Protocol Number: TCP 679 TCP Port Number: TBD by IANA 681 Message Formats, Types, Opcodes, and Sequences: defined in 682 Section 4.2, Section 3, and Section 4.1. 684 Functions: defined in IRIS [1]. 686 Use of Broadcast/Multicast: none 688 Proposed Name: IRIS over XPC 690 Short name: iris.xpc 691 Contact Information: Andrew Newton 693 13.6. Well-known TCP Port Registration for XPCS 695 Protocol Number: TCP 697 TCP Port Number: TBD by IANA 699 Message Formats, Types, Opcodes, and Sequences: defined in Section 9, 700 Section 4.2, Section 3, and Section 4.1. 702 Functions: defined in IRIS [1]. 704 Use of Broadcast/Multicast: none 706 Proposed Name: IRIS over XPCS 708 Short name: iris.xpcs 710 Contact Information: Andrew Newton 712 14. Security Considerations 714 Implementers should be fully aware of the security considerations 715 given by IRIS [1] and TLS [4]. With respect to server authentication 716 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 718 14.1. Security Mechanisms 720 Clients SHOULD be prepared to use the following security mechanisms 721 in the following manner: 723 o SASL/DIGEST-MD5 - for user authentication without the need of 724 session encryption. 726 o SASL/OTP - for user authentication without the need of session 727 encryption. 729 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 730 encryption. 732 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 733 side certificates - for encryption and user authentication. 735 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 736 encryption. See [7]. 738 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 739 certificates - for encryption and user authentication. See [7]. 741 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 742 encryption. See [7]. 744 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 745 certificates - for encryption and user authentication. See [7]. 747 Anonymous client access SHOULD be considered in one of two methods: 749 1. When no authentication has been used. 751 2. Using the SASL anonymous profile: SASL/ANONYMOUS 753 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 754 mechanism without first encrypting the TCP session (e.g. such as with 755 TLS). 757 14.2. SASL Compliance 759 The following list details the compliance of IRIS-XPC for use with 760 SASL, as specified by RFC 4422 [11], Section 4. 762 1. The SASL service name to be used by IRIS-XPC is "iris-xpc". 764 2. Section 6.2 describes the negotiation facility used to determine 765 the available security mechanisms. 767 3. 769 a) Section 6.5 describes the mechanism to initiate authentication 770 exchanges. 772 b) Section 6.5 describes the mechanism to transfer server 773 challenges and client responses. 775 c) Section 6.6 and Section 6.7 describe the mechanisms to 776 indicate the outcome of an authentication exchange. 778 4. Non-empty authorization identity strings usign within IRIS-XPC 779 MUST be normalized according to RFC 4013 [12]. 781 5. Clients or servers wishing to abort an ongoing authentication 782 exchange MUST close the connection. 784 6. After new security layers are negotiated, they take effect on the 785 first octet following the authentication success (as) 786 (Section 6.6) chunk sent by the server and on the first octet 787 sent after receipt of the authentication success (as) chunk sent 788 by the client. 790 7. IRIS-XPC can be used with both TLS and SASL. When used in 791 combination, TLS MUST always be applied before any SASL 792 mechanism. 794 8. IRIS-XPC does not support multiple SASL authentications. 795 However, if TLS is being used in combination with SASL, TLS 796 authentication MUST occur before any SASL authentication. 798 15. Normative References 800 [1] Newton, A. and M. Sanz, "Internet Registry Information 801 Service", RFC 3981, January 2004. 803 [2] Newton, A. and M. Sanz, "Using the Internet Registry 804 Information Service over the Blocks Extensible Exchange 805 Protocol", RFC 3983, January 2004. 807 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 808 ISBN 0-201-61633-5, 2000, . 810 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 811 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 812 January 1999. 814 [5] Daigle, L. and A. Newton, "Domain-Based Application Service 815 Location Using SRV RRs and the Dynamic Delegation Discovery 816 Service (DDDS)", RFC 3958, January 2005. 818 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 819 Resource Identifiers (URI): Generic Syntax", RFC 2396, 820 August 1998. 822 [7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 823 Transport Layer Security (TLS)", RFC 3268, June 2002. 825 [8] Bradner, S., "Key words for use in RFCs to Indicate 826 Requirement Levels", RFC 2119, BCP 14, March 1997. 828 [9] Newton, A., "A Common Schema for Internet Registry Information 829 Service Transfer Protocols", 830 draft-ietf-crips-iris-common-transport-00 (work in progress), 831 April 2005. 833 [10] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", 834 RFC 1166, July 1990. 836 [11] Melnikov, A. and K. Zeilenga, "Simple Authentication and 837 Security Layer (SASL)", RFC 4422, June 2006. 839 [12] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and 840 Passwords", RFC 4013, February 2005. 842 Appendix A. Examples 844 This section gives examples of IRIS-XPC sessions. Lines beginning 845 with "C:" denote data sent by the client to the server, and lines 846 beginning with "S:" denote data sent by the server to the client. 847 Following the "C:" or "S:", the line either contains octet values in 848 hexadecimal notation with comments or XML fragments. No line 849 contains both octet values with comments and XML fragments. Comments 850 are contained within parenthesis. 852 It should also be noted that flag values of "yes" and "no" reflect 853 binary values 1 and 0. 855 The following example demonstrates an IRIS client issuing two 856 requests in one XPC session. In the first request, the client is 857 requesting status information for "example.com". This request and 858 its response are transfered with one chunk. In the second request, 859 the client is requesting status information for "milo.example.com", 860 "felix.example.com", and "hobbes.example.com". This request and its 861 response are transfered with three chunks. 863 S: (connection response block) 864 S: 0x20 (block header: V=0,KO=yes) 865 S: (chunk 1) 866 S: 0xC1 (LC=yes,DC=yes,CT=vi) 867 S: 0x01 0xBF (chunk length=447) 868 S: (Version Information) 869 S: 870 S: 871 S: 873 S: 875 S: 876 S: 877 S: 878 S: 879 S: 881 C: (request block) 882 C: 0x20 (block header: V=0,KO=yes) 883 C: 0x0B (authority length=11) 884 C: (authority="example.com") 885 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 886 C: (chunk 1) 887 C: 0xC7 (LC=yes,DC=yes,CT=ad) 888 C: 0x01 0x53 (chunk length=339) 889 C: (IRIS XML request) 890 C: 892 C: 893 C: 897 C: 898 C: 900 S: (response block) 901 S: 0x20 (block header: V=0,KO=yes) 902 S: (chunk 1) 903 S: 0xC7 (LC=yes,DC=yes,CT=ad) 904 S: 0x01 0xE0 (chunk length=480) 905 S: (IRIS XML response) 906 S: 907 S: 908 S: 909 S: 913 S: example.com 914 S: 915 S: 916 S: 917 S: 918 S: 919 S: 920 S: 922 C: (request block) 923 C: 0x00 (block header: V=0,KO=no) 924 C: 0x0B (authority length=11) 925 C: (authority="example.com") 926 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 927 C: (chunk 1) 928 C: 0x07 (LC=no,DC=no,CT=ad) 929 C: 0x01 0x4E (chunk length=339) 930 C: (IRIS XML request) 931 C: 934 C: 935 C: 939 C: 940 C: (chunk 2) 941 C: 0x07 (LC=no,DC=no,CT=ad) 942 C: 0x00 0xA9 (chunk length=169) 943 C: (IRIS XML request) 944 C: 945 C: 949 C: 950 C: (chunk 3) 951 C: 0xC7 (LC=yes,DC=yes,CT=ad) 952 C: 0x00 0xB5 (chunk length=181) 953 C: (IRIS XML request) 954 C: 955 C: 959 C: 960 C: 962 S: (response block) 963 S: 0x00 (block header: V=0,KO=no) 964 S: (chunk 1) 965 S: 0x07 (LC=no,DC=no,CT=ad) 966 S: 0x01 0xDA (chunk length=474) 967 S: (IRIS XML response) 968 S: 969 S: 970 S: 971 S: 975 S: milo.example.com 976 S: 977 S: 978 S: 979 S: 980 S: 981 S: 982 S: (chunk 2) 983 S: 0x07 (LC=no,DC=no,CT=ad) 984 S: 0x01 0xA2 (chunk length=418) 985 S: (IRIS XML response) 986 S: 987 S: 988 S: 992 S: felix.example.com 993 S: 994 S: 995 S: 996 S: 997 S: 998 S: 999 S: (chunk 3) 1000 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1001 S: 0x01 0xB5 (chunk length=437) 1002 S: (IRIS XML response) 1003 S: 1004 S: 1005 S: 1010 S: hobbes.example.com 1011 S: 1012 S: 1013 S: 1014 S: 1015 S: 1016 S: 1017 S: 1019 Figure 7: Example 1 1021 In the following example, an IRIS client requests domain status 1022 information for "milo.example.com", "felix.example.com", and 1023 "hobbes.example.com" in one request. The request is sent with one 1024 chunk, however the answer is returned in three chunks. 1026 S: (connection response block) 1027 S: 0x20 (block header: V=0,KO=yes) 1028 S: (chunk 1) 1029 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1030 S: 0x01 0xBF (chunk length=447) 1031 S: (Version Information) 1032 S: 1033 S: 1034 S: 1036 S: 1038 S: 1039 S: 1040 S: 1041 S: 1042 S: 1044 C: (request block) 1045 C: 0x00 (block header: V=0,KO=no) 1046 C: 0x0B (authority length=11) 1047 C: (authority="example.com") 1048 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1049 C: (chunk 1) 1050 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1051 C: 0x02 0xAB (chunk length=683) 1052 C: (IRIS XML request) 1053 C: 1056 C: 1057 C: 1061 C: 1062 C: 1063 C: 1067 C: 1068 C: 1069 C: 1073 C: 1074 C: 1076 S: (response block) 1077 S: 0x00 (block header: V=0,KO=no) 1078 S: (chunk 1) 1079 S: 0x07 (LC=no,DC=no,CT=ad) 1080 S: 0x01 0xDA (chunk length=474) 1081 S: (IRIS XML response) 1082 S: 1083 S: 1084 S: 1085 S: 1089 S: milo.example.com 1090 S: 1091 S: 1092 S: 1093 S: 1094 S: 1095 S: 1096 S: (chunk 2) 1097 S: 0x07 (LC=no,DC=no,CT=ad) 1098 S: 0x01 0xA2 (chunk length=418) 1099 S: (IRIS XML response) 1100 S: 1101 S: 1102 S: 1106 S: felix.example.com 1107 S: 1108 S: 1109 S: 1110 S: 1111 S: 1112 S: 1113 S: (chunk 3) 1114 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1115 S: 0x01 0xB5 (chunk length=437) 1116 S: (IRIS XML response) 1117 S: 1118 S: 1119 S: 1124 S: hobbes.example.com 1125 S: 1126 S: 1127 S: 1128 S: 1129 S: 1130 S: 1131 S: 1133 Figure 8: Example 2 1135 In the following example, an IRIS client sends a request containg 1136 SASL/PLAIN authentication data and a domain status check for 1137 "example.com". The server responds with authentication succss 1138 information and the domain status of "example.com". Note that the 1139 client requests that the connection stay open for further requests, 1140 but that the server does not honor this request. 1142 S: (connection response block) 1143 S: 0x20 (block header: V=0,KO=yes) 1144 S: (chunk 1) 1145 S: 0xC1 (LC=yes,DC=yes,CT=vi) 1146 S: 0x01 0xBF (chunk length=447) 1147 S: (Version Information) 1148 S: 1149 S: 1150 S: 1152 S: 1154 S: 1155 S: 1156 S: 1157 S: 1158 S: 1160 C: (request block) 1161 C: 0x00 (block header: V=0,KO=no) 1162 C: 0x0B (authority length=11) 1163 C: (authority="example.com") 1164 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 1165 C: (chunk 1) 1166 C: 0x44 (LC=no,DC=yes,CT=sd) 1167 C: 0x00 0x11 (chunk length=11) 1168 C: (SASL data) 1169 C: 0x05 (mechanism length=5) 1170 C: (mechanism name="PLAIN") 1171 C: 0x50 0x4C 0x41 0x49 0x43 1172 C: 0x00 0x0A (sasl PLAIN data length=10) 1173 C: (sasl PLAIN data: authcid="bob") 1174 C: (sasl PLAIN data: authzid=NULL) 1175 C: (sasl PLAIN data: password="kEw1") 1176 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1177 C: (chunk 2) 1178 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1179 C: 0x01 0x53 (chunk length=339) 1180 C: (IRIS XML request) 1181 C: 1183 C: 1184 C: 1188 C: 1189 C: 1191 S: (response block) 1192 S: 0x00 (block header: V=0,KO=no) 1193 S: (chunk 1) 1194 S: 0x45 (LC=no,DC=yes,CT=as) 1195 S: 0x00 0xD0 (chunk length=208) 1196 S: (authentication success response) 1197 S: 1198 S: 1200 S: 1201 S: user 'bob' authenticates via password 1202 S: 1203 S: 1204 S: (chunk 2) 1205 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1206 S: 0x01 0xE0 (chunk length=480) 1207 S: (IRIS XML response) 1208 S: 1209 S: 1210 S: 1211 S: 1215 S: example.com 1216 S: 1217 S: 1218 S: 1219 S: 1220 S: 1221 S: 1222 S: 1224 Figure 9: Example 3 1226 Appendix B. Contributors 1228 Substantive contributions to this document have been provided by the 1229 members of the IETF's CRISP Working Group, especially Robert Martin- 1230 Legene, Milena Caires, and David Blacka. 1232 Author's Address 1234 Andrew L. Newton 1235 VeriSign, Inc. 1236 21345 Ridgetop Circle 1237 Sterling, VA 20166 1238 USA 1240 Phone: +1 703 948 3382 1241 Email: andy@hxr.us 1242 URI: http://www.verisignlabs.com/ 1244 Intellectual Property Statement 1246 The IETF takes no position regarding the validity or scope of any 1247 Intellectual Property Rights or other rights that might be claimed to 1248 pertain to the implementation or use of the technology described in 1249 this document or the extent to which any license under such rights 1250 might or might not be available; nor does it represent that it has 1251 made any independent effort to identify any such rights. Information 1252 on the procedures with respect to rights in RFC documents can be 1253 found in BCP 78 and BCP 79. 1255 Copies of IPR disclosures made to the IETF Secretariat and any 1256 assurances of licenses to be made available, or the result of an 1257 attempt made to obtain a general license or permission for the use of 1258 such proprietary rights by implementers or users of this 1259 specification can be obtained from the IETF on-line IPR repository at 1260 http://www.ietf.org/ipr. 1262 The IETF invites any interested party to bring to its attention any 1263 copyrights, patents or patent applications, or other proprietary 1264 rights that may cover technology that may be required to implement 1265 this standard. Please address the information to the IETF at 1266 ietf-ipr@ietf.org. 1268 Disclaimer of Validity 1270 This document and the information contained herein are provided on an 1271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1273 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1274 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1275 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1278 Copyright Statement 1280 Copyright (C) The Internet Society (2007). This document is subject 1281 to the rights, licenses and restrictions contained in BCP 78, and 1282 except as set forth therein, the authors retain all their rights. 1284 Acknowledgment 1286 Funding for the RFC Editor function is currently provided by the 1287 Internet Society.