idnits 2.17.1 draft-ietf-crisp-iris-xpc-01.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 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1138. ** 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 (June 7, 2005) is 6897 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 2222 (ref. '4') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3268 (ref. '8') (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. '10' Summary: 7 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) June 7, 2005 5 Expires: December 9, 2005 7 XML Pipelining with Chunks for the Information Registry Information 8 Service 9 draft-ietf-crisp-iris-xpc-01 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 December 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a simple TCP transfer protocol for the 43 Internet Registry Information Service (IRIS). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 49 3. Request Block (RQB) . . . . . . . . . . . . . . . . . . . . 5 50 4. Response Blocks . . . . . . . . . . . . . . . . . . . . . . 6 51 4.1 Response Block (RSB) . . . . . . . . . . . . . . . . . . . 6 52 4.2 Connection Response Block (CRB) . . . . . . . . . . . . . 6 53 5. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 8 54 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 6.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 10 56 6.2 Version Information Types . . . . . . . . . . . . . . . . 10 57 6.3 Size Information Types . . . . . . . . . . . . . . . . . . 11 58 6.4 Other Information Types . . . . . . . . . . . . . . . . . 11 59 6.5 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 12 60 6.6 Authentication Succss Information Types . . . . . . . . . 13 61 6.7 Authentication Failure Information Types . . . . . . . . . 13 62 6.8 Application Data Types . . . . . . . . . . . . . . . . . . 14 63 7. Idle Sessions . . . . . . . . . . . . . . . . . . . . . . . 15 64 8. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 16 65 9. Update to RFC 3981 . . . . . . . . . . . . . . . . . . . . . 17 66 10. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 18 67 10.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . 18 68 10.2 Application Protocol Label . . . . . . . . . . . . . . . 18 69 11. Internationalization Considerations . . . . . . . . . . . . 19 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 71 12.1 XPC URI Scheme Registration . . . . . . . . . . . . . . 20 72 12.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . 20 73 12.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . 21 74 12.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . 21 75 12.5 Well-known TCP Port Registration . . . . . . . . . . . . 21 76 13. Security Considerations . . . . . . . . . . . . . . . . . . 22 77 14. Normative References . . . . . . . . . . . . . . . . . . . . 22 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 79 A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 B. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 81 Intellectual Property and Copyright Statements . . . . . . . 33 83 1. Introduction 85 Using S-NAPTR [6], IRIS has the ability to define the use of multiple 86 application transports (or transfer protocols) for different types of 87 registry services, all at the descretion of the server operator. The 88 TCP transfer protocol defined in this document is completely modular 89 and may be used by any registry types. 91 This transfer protocol defines simple framing for sending XML in 92 chunks so that XML fragments may be acted upon (or pipelined) before 93 the reception of the entire XML instance. This document calls this 94 XML pipelining with chunks (XPC) and its use with IRIS as IRIS-XPC. 96 XPC is for use with simple request and response interactions between 97 clients and servers. Clients send a series of requests to a server 98 in data blocks. The server will respond to each data block 99 individually with a corresponding data block, but through the same 100 connection. Request and response data blocks are sent using the TCP 101 SEND function and received using the TCP RECEIVE function. 103 The lifecycle of an XPC session has the following phases: 105 1. A client establishes a TCP connection with a server. 107 2. The server sends a connection response block (CRB). 109 3. The client sends a request block (RQB). In this request, the 110 client can set a "keep open" flag requesting that the server keep 111 the XPC session open following the response to this request. 113 4. The server responds with a response block (RSB). In this 114 response, the server can indicate to the client whether or not 115 the XPC session will be closed. 117 5. If the XPC session is not to be terminated, then the lifecycle 118 repeats from step 3. 120 6. The TCP connection is closed. 122 2. Document Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC2119 [9]. 128 3. Request Block (RQB) 130 The format for the request block (RQB) is as follows: 132 +--------+-----------+-----------+-------------+ 133 field | header | authority | authority | chunks 1..n | 134 | | length | | | 135 +--------+-----------+-----------+-------------+ 136 octets 1 1 0..255 variable 138 These fields have the following meanings: 140 o header - as described in Section 5. 142 o authority length - the length of the authority field in this 143 request block. 145 o authority - a string of octets describing the authority against 146 which this request is to be executed. See [1] for the definition 147 and description of an authority. The number of octets in this 148 string MUST be no more and no less than the number specified by 149 the authority length. 151 o chunks 1..n - the request data broken into chunks (Section 6). 153 4. Response Blocks 155 There are two types of blocks used by a server to respond to a 156 client. The first type is a response block (RSB) defined in 157 Section 4.1. It is used by a server to respond to request blocks 158 (RQB). The second type is a specialized version of a response block 159 called a connection response block (CRB) defined in Section 4.2. It 160 is sent by a server to a client when a connection is established to 161 initiate protocol negotiation. Conceptually, a CRB is a type of RQB; 162 they share the same format, but a CRB is constrained in conveying 163 only specific information and is only sent at the beginning of the 164 session lifecycle. 166 4.1 Response Block (RSB) 168 The format for the response block (RSB) is as follows: 170 +--------+-------------+ 171 field | header | chunks 1..n | 172 | | | 173 +--------+-------------+ 174 octets 1 variable 176 These fields have the following meanings: 178 o header - as described in Section 5. 180 o chunks 1..n - the response data broken into chunks (Section 6). 182 4.2 Connection Response Block (CRB) 184 A connection response block (CRB) is a response block sent by a 185 server to a client in response to the client initiating a session. A 186 connection response block has the same format as a response block 187 (RSB) (Section 4.1). The only difference is that it is constrained 188 in one of two ways: 190 1. It contains only one chunk (see Section 6) containing version 191 information (see Section 6.2) and the keep-open (or KO) flag in 192 the block header (see Section 5) has a value of 1 (meaning the 193 connection is not closing). Servers MUST use this type of CRB to 194 indicate service availability. 196 2. It contains only one chunk (see Section 6) containing a system 197 error (see 'system-error' under Section 6.4) and the keep-open 198 (or KO) flag in the block header (see Section 5) has a value of 0 199 (meaning the server will close the connection immediately after 200 sending the CRB). Servers MUST use this type of CRB when they 201 can accept connections but cannot process requests. 203 5. Block Header 205 Each data block starts with a one octet header called the block 206 header. This header has the same format for both request and 207 response data blocks, though some of the bits in the header only have 208 meaning in one type of data block. Each bit in the block header has 209 the following meaning: 211 o bits 7 and 6 - version (V field) - If 0 (both bits are zero), the 212 protocol is the version defined in this document. Otherwise, the 213 rest of the bits in the header and the block may be interpreted as 214 another version. 216 o bits 5 - keep open (KO flag) - This flag is used to request that a 217 connection stay open by a client and to indicate that a connection 218 will stay open by a server, depending on the type of block. In a 219 request block (RQB): a value of 1 indicates that a client is 220 requesting that the server not close the TCP session, and a value 221 of 0 indicates the client will expect ther server to close the TCP 222 session immediately after sending the corresponding response. In 223 a response block (RSB) or a connection response block (CRB): a 224 value of 1 indicates that the server will keep the TCP session 225 open to receive another request, and a value of 0 indicates that 226 the server will close the TCP session immediately following this 227 block. 229 o bit 4, 3, 2, 1, and 0 - reserved - These MUST be 0. 231 6. Chunks 233 Request and response blocks break the request and response XML data 234 down into chunks. Request and response blocks MUST always have a 235 minimum of 1 chunk. Each chunk has a one octet descriptor. The 236 seventh bit of the descriptor determines if chunk is the last chunk 237 in the block. 239 The bits of the chunk descriptor octet have the following meaning: 241 o bit 7 - last chunk (LC flag) - If 1, this chunk is the last chunk 242 in the block. 244 o bit 6 - data complete (DC flag) - If 1, the data in this chunk 245 represents the end of the data for the chunk type given. If this 246 bit is never set to 1 in any chunk descriptor for chunks of the 247 same type in a block, clients and servers MUST NOT assume the data 248 will continue in another block. If the block transitions from one 249 type of chunk to another with out signaling completion of the 250 data, clients and servers MUST assume that the remaining data will 251 not be sent in a remaining chunk. 253 o bits 5, 4, and 3 - reserved - These MUST be 0. 255 o bit 2, 1, and 0 - chunk type (CT field) - determines the type of 256 data carried in the chunk. These are the binary values for the 257 chunk types: 259 * 000 - no data or 'nd' type (see Section 6.1) 261 * 001 - version information or 'vi' type (see Section 6.2) 263 * 010 - size information or 'si' type (see Section 6.3) 265 * 011 - other information or 'oi type (see Section 6.4) 267 * 100 - SASL data or 'sd' type (see Section 6.5) 269 * 101 - authentication success information or 'as' type (see 270 Section 6.6) 272 * 110 - authentication failure information or 'af' type (see 273 Section 6.7) 275 * 111 - application data or 'ad' type (see Section 6.8) 277 A block MAY have multiple types of chunks, but all chunks of the same 278 type MUST be contingous in a block and MUST be ordered in the block 279 in the order in which their data is to be intepretted. Contiguous 280 chunks must by ordered by type within a block in the following way: 282 1. authentication related chunks - either SASL data chunks (type 283 100), authentication success information chunks (type 101) or 284 authentication failure information chunks (type 110), but not 285 more than one type 287 2. data chunks - either no data chunks (type 000) or application 288 data chunks (type 111), but not both. 290 3. information chunks - either version information (type 001) or 291 other information (type 011), but not both. 293 A block MUST have at least one type of the above chunks. 295 The format for a chunk is as follows: 297 +-----------+------------+--------+ 298 field | chunk | chunk data | chunk | 299 | descriptor| length | data | 300 +-----------+------------+--------+ 301 octets 1 2 variable 303 These fields have the following meanings: 305 o chunk descriptor - as described above. 307 o chunk data length - the length of the data of the chunk 309 o chunk data - the data of the chunk 311 6.1 No Data Types 313 Servers and clients MUST ignore data in chunk types labeled no data. 314 There is no requirement for these types of chunks to be zero length. 315 A client MAY send "no data" to a server, and the server MUST respond 316 with either a chunk of the same type or other information 317 (Section 6.4). 319 6.2 Version Information Types 321 Chunks of this type contain XML conformant to the schema specified in 322 [10] and MUST have the element as the root element. 324 In the context of IRIS-XPC, the protocol identifiers for these 325 elements are as follows: 327 o - the value "iris.xpc1" to indicate the 328 protocol specified in this document. 330 o - the XML namespace identifier for IRIS [1]. 332 o - the XML namespace identifier for IRIS registries. 334 In the context of IRIS-XPC, the authentication mechanism identifiers 335 are the SASL mechanism names found in the IANA SASL mechanism 336 registry defined by RFC 2222 [4]. 338 This document defines no extension identifiers. 340 Clients MAY send a block with this type of chunk to a server. These 341 chunks SHOULD be zero length and servers MUST ignore any data in 342 them. When a server receives a chunk of this type, it MUST respond 343 with a chunk of this type. This interchange allows a client to query 344 the version information of a server. 346 The definition of octet size for the 'requestSizeOctets' and 347 'responseSizeOctets' attributes of the element are 348 defined in Section 6.3. 350 6.3 Size Information Types 352 Chunks of this type contain XML conformant to the schema specified in 353 IRIS-COMMON [10] and MUST have the element as the root 354 element. 356 Octet counts provided by this information are defined as the sum of 357 the count of all chunk data of a particular chunk type. For 358 instance, if a XML instance is broken up into chunks of 20, 30, and 359 40 octets, the octet count would be 90 (20 + 30 + 40). 361 6.4 Other Information Types 363 Chunks of this type contain XML conformant to the schema specified in 364 IRIS-COMMON [10] and MUST have the element as the root 365 element. 367 The values for the 'type' attribute of are as follows: 369 'block-error' - indicates there was an error decoding a block. 370 Servers SHOULD send a block error in the following cases: 372 1. When a request block is received containing a chunk of this 373 type. 375 2. When a request block is received containing authentication 376 success (see Section 6.6) or authentication failure (see 377 Section 6.7) information. 379 3. When a request block is received containing size information 380 (see Section 6.3). 382 4. When reserved bits in the request block are 1. 384 5. When a block has not been received in its entirety and the TCP 385 session has been idle for a specific period of time (i.e. a 386 data block has been received but no terminating chunk for the 387 data block has been recieved). Two minutes is RECOMMENDED for 388 this timeout value. Note, there is a difference between an 389 idle condition due to the incomplete reception of a data block 390 and an idle condition between request/response transactions 391 associated with keeping the session open. For the latter, see 392 Section 7. 394 'data-error' - indicates there was an error parsing data in chunks 395 containing application or SASL data (e.g. XML is not valid in 396 application data). 398 'system-error' - indicates that the receiver cannot process the 399 request due to a condition not related to this protocol. Servers 400 SHOULD send a system-error when they are capable of responding to 401 requests but not capable of processing requests. 403 'authority-error' - indicates that the intended authority 404 specified in the corresponding request is not served by the 405 receiver. Servers SHOULD send an authority error when they 406 receive a request directed to an authority other than those they 407 serve. 409 'idle-timeout' - indicates that an XPC session has been idle for 410 too long. Usage of this value is defined in Section 7. Note, 411 there is a difference between an idle condition due to the 412 incomplete reception of a data block and an idle condition between 413 request/response transactions associated with keeping the session 414 open. For the former, see 'block-error' above. 416 6.5 SASL Types 418 The SASL chunk type allows clients and servers to exchange SASL data. 420 The format for the data of this type of chunk is as follows: 422 +-----------+-----------+-----------+-----------+ 423 field | mechanism | mechanism | mechanism | mechanism | 424 | name | name | data | data | 425 | length | | length | | 426 +-----------+-----------+-----------+-----------+ 427 octets 1 variable 2 variable 429 These fields have the following meaning: 431 o mechanism name length - the length of the SASL mechanism name 433 o mechanism - the name of the SASL mechanism as registered in the 434 IANA SASL mechanism registry defined by [4]. 436 o mechanism data length - the length of the SASL data 438 o mechanism data - the data used for SASL 440 These fields MUST NOT span multiple chunks. Therefore it should be 441 noted that SASL data length exceeding the length of the chunk minus 442 the length of SASL profile name minus one is an error. 444 Depending on the nature of the SASL mechansim being used, SASL data 445 is sent from clients to servers and from servers to clients and may 446 require multiple request/response transactions to complete. However, 447 once a SASL exchange is complete and a server can determine 448 authentication status, the server MUST send either authentication 449 success information (see Section 6.6) or authentication failure 450 information (see Section 6.7). 452 6.6 Authentication Succss Information Types 454 Chunks of this type contain XML conformant to the schema specified in 455 IRIS-COMMON [10] and MUST have the element as 456 the root element. 458 This type of chunk is only sent from a server to a client. If a 459 client sends it to a server, this will result in a block error (see 460 'block-error' in Section 6.4). The usage of this chunk type is 461 defined in Section 6.5. 463 6.7 Authentication Failure Information Types 465 Chunks of this type contain XML conformant to the schema specified in 466 IRIS-COMMON [10] and MUST have the element as 467 the root element. 469 This type of chunk is only sent from a server to a client. If a 470 client sends it to a server, this will result in a block error (see 471 'block-error' in Section 6.4). The usage of this chunk type is 472 defined in Section 6.5. 474 6.8 Application Data Types 476 These chunks contain application data. For IRIS, these are IRIS [1] 477 XML instances. 479 7. Idle Sessions 481 An XPC session may become idle between request/response transactions. 482 This can occur when a server honors a client's request to keep the 483 TCP connection running (see the keep-open or KO flag in the block 484 header (Section 5)). Servers are not expected to allow XPC sessions 485 remain idle between requests indefinitely. 487 Clients MUST send no less than 1 request every 2 minutes. This can 488 be any type of request specified by this document. If a client has 489 no need to send a specific type of request but must send a request to 490 fulfill this obligation, sending a request block containing one chunk 491 of "no data" (see Section 6.1) with a length of zero is RECOMMENDED. 493 If a server has not received a request block 5 minutes after sending 494 a response block (either RSB or CRB), it SHOULD do the following: 496 1. Send an unsolicited response block containing an idle timeout 497 error (see 'idle-timeout' in Section 6.4) with the keep-open (or 498 KO) flag in the block header (Section 5) set to a value of 0. 500 2. Close the TCP connection. 502 8. Use over TLS 504 XPC may be tunneled over TLS [5] by establishing a TLS session 505 immediately after a TCP session is opened and before any blocks are 506 to be sent. This type of session is known as XPCS. 508 When using TLS, a convention must be established to allow a client to 509 authenticate the validity of a server. XPCS uses the same convention 510 as described by IRIS-BEEP [2]. 512 9. Update to RFC 3981 514 Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is 515 the default transport for IRIS. This document revises RFC 3981 and 516 specifies IRIS-XPC as the default transport for IRIS. The TCP well- 517 known port registration is specified in Section 12.5. 519 10. IRIS Transport Mapping Definitions 521 This section lists the definitions required by IRIS [1] for transport 522 mappings. 524 10.1 URI Scheme 526 See Section 12.1 and Section 12.2. 528 10.2 Application Protocol Label 530 See Section 12.3 and Section 12.4. 532 11. Internationalization Considerations 534 XML processors are obliged to recognize both UTF-8 and UTF-16 [3] 535 encodings. Use of the XML defined by [10] MUST NOT use any other 536 character encodings other than UTF-8 or UTF-16. 538 12. IANA Considerations 540 12.1 XPC URI Scheme Registration 542 URL scheme name: iris.xpc 544 URL scheme syntax: defined in [1]. 546 Character encoding considerations: as defined in RFC2396 [7]. 548 Intended usage: identifies IRIS XML using chunks over TCP 550 Applications using this scheme: defined in IRIS [1]. 552 Interoperability considerations: n/a 554 Security Considerations: defined in Section 13. 556 Relevant Publications: IRIS [1]. 558 Contact Information: Andrew Newton 560 Author/Change controller: the IESG 562 12.2 XPCS URI Scheme Registration 564 URL scheme name: iris.xpcs 566 URL scheme syntax: defined in [1]. 568 Character encoding considerations: as defined in RFC2396 [7]. 570 Intended usage: identifies IRIS XML using chunks over TLS 572 Applications using this scheme: defined in IRIS [1]. 574 Interoperability considerations: n/a 576 Security Considerations: defined in Section 13. 578 Relevant Publications: IRIS [1]. 580 Contact Information: Andrew Newton 582 Author/Change controller: the IESG 584 12.3 S-NAPTR XPC Registration 586 Application Protocol Label (see [6]): iris.xpc 588 Intended usage: identifies an IRIS server using XPC 590 Interoperability considerations: n/a 592 Security Considerations: defined in Section 13. 594 Relevant Publications: IRIS [1]. 596 Contact Information: Andrew Newton 598 Author/Change controller: the IESG 600 12.4 S-NAPTR XPCS Registration 602 Application Protocol Label (see [6]): iris.xpcs 604 Intended usage: identifies an IRIS server using secure XPCS 606 Interoperability considerations: n/a 608 Security Considerations: defined in Section 13. 610 Relevant Publications: IRIS [1]. 612 Contact Information: Andrew Newton 614 Author/Change controller: the IESG 616 12.5 Well-known TCP Port Registration 618 Protocol Number: TCP 620 Message Formats, Types, Opcodes, and Sequences: defined in 621 Section 4.2, Section 3, and Section 4.1. 623 Functions: defined in IRIS [1]. 625 Use of Broadcast/Multicast: none 627 Proposed Name: IRIS over XPC 629 Short name: iris.xpc 631 Contact Information: Andrew Newton 633 13. Security Considerations 635 Implementers should be fully aware of the security considerations 636 given by IRIS [1] and TLS [5]. With respect to server authentication 637 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 639 Clients SHOULD be prepared to use the following security mechanisms 640 in the following manner: 642 o SASL/DIGEST-MD5 - for user authentication without the need of 643 session encryption. 645 o SASL/OTP - for user authentication without the need of session 646 encryption. 648 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 649 encryption. 651 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client- 652 side certificates - for encryption and user authentication. 654 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 655 encryption. See [8]. 657 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 658 certificates - for encryption and user authentication. See [8]. 660 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 661 encryption. See [8]. 663 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 664 certificates - for encryption and user authentication. See [8]. 666 Anonymous client access SHOULD be considered in one of two methods: 668 1. When no authentication has been used. 670 2. Using the SASL anonymous profile: SASL/ANONYMOUS 672 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 673 mechanism without first encrypting the TCP session (e.g. such as with 674 TLS). 676 14. Normative References 678 [1] Newton, A. and M. Sanz, "Internet Registry Information 679 Service", RFC 3891, January 2004. 681 [2] Newton, A. and M. Sanz, "Using the Internet Registry 682 Information Service over the Blocks Extensible Exchange 683 Protocol", RFC 3893, January 2004. 685 [3] The Unicode Consortium, "The Unicode Standard, Version 3", 686 ISBN 0-201-61633-5, 2000, . 688 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 689 RFC 2222, October 1997. 691 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and 692 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 693 January 1999. 695 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 696 Location Using SRV RRs and the Dynamic Delegation Discovery 697 Service (DDDS)", RFC 3958, January 2005. 699 [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 700 Resource Identifiers (URI): Generic Syntax", RFC 2396, 701 August 1998. 703 [8] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 704 Transport Layer Security (TLS)", RFC 3268, June 2002. 706 [9] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", RFC 2119, BCP 14, March 1997. 709 [10] Newton, A., "A Common Schema for Internet Registry Information 710 Service Transfer Protocols", 711 draft-ietf-crips-iris-common-transport-00 (work in progress), 712 April 2005. 714 Author's Address 716 Andrew L. Newton 717 VeriSign, Inc. 718 21345 Ridgetop Circle 719 Sterling, VA 20166 720 USA 722 Phone: +1 703 948 3382 723 Email: anewton@verisignlabs.com; andy@hxr.us 724 URI: http://www.verisignlabs.com/ 726 Appendix A. Examples 728 This section gives examples of IRIS-XPC sessions. Lines beginning 729 with "C:" denote data sent by the client to the server, and lines 730 beginning with "S:" denote data sent by the server to the client. 731 Following the "C:" or "S:", the line either contains octet values in 732 hexadecimal notation with comments or XML fragments. No line 733 contains both octet values with comments and XML fragments. Comments 734 are contained within parenthesis. 736 It should also be noted that flag values of "yes" and "no" reflect 737 binary values 1 and 0. 739 The following example demonstrates an IRIS client issuing two 740 requests in one XPC session. In the first request, the client is 741 requesting status information for "example.com". This request and 742 its response are transfered with one chunk. In the second request, 743 the client is requesting status information for "milo.example.com", 744 "felix.example.com", and "hobbes.example.com". This request and its 745 response are transfered with three chunks. 747 S: (connection response block) 748 S: 0x20 (block header: V=0,KO=yes) 749 S: (chunk 1) 750 S: 0xC1 (LC=yes,DC=yes,CT=vi) 751 S: 0x01 0xBE (chunk length=446) 752 S: (Version Information) 753 S: 754 S: 755 S: 757 S: 759 S: 760 S: 761 S: 762 S: 763 S: 765 C: (request block) 766 C: 0x20 (block header: V=0,KO=yes) 767 C: 0x0B (authority length=11) 768 C: (authority="example.com") 769 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 770 C: (chunk 1) 771 C: 0xC7 (LC=yes,DC=yes,CT=ad) 772 C: 0x01 0x53 (chunk length=339) 773 C: (IRIS XML request) 774 C: 776 C: 777 C: 781 C: 782 C: 784 S: (response block) 785 S: 0x20 (block header: V=0,KO=yes) 786 S: (chunk 1) 787 S: 0xC7 (LC=yes,DC=yes,CT=ad) 788 S: 0x01 0xE0 (chunk length=480) 789 S: (IRIS XML response) 790 S: 791 S: 792 S: 793 S: 797 S: example.com 798 S: 799 S: 800 S: 801 S: 802 S: 803 S: 804 S: 806 C: (request block) 807 C: 0x00 (block header: V=0,KO=no) 808 C: 0x0B (authority length=11) 809 C: (authority="example.com") 810 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 811 C: (chunk 1) 812 C: 0x07 (LC=no,DC=no,CT=ad) 813 C: 0x01 0x4E (chunk length=339) 814 C: (IRIS XML request) 815 C: 818 C: 819 C: 823 C: 824 C: (chunk 2) 825 C: 0x07 (LC=no,DC=no,CT=ad) 826 C: 0x00 0xA9 (chunk length=169) 827 C: (IRIS XML request) 828 C: 829 C: 833 C: 834 C: (chunk 3) 835 C: 0xC7 (LC=yes,DC=yes,CT=ad) 836 C: 0x00 0xB5 (chunk length=181) 837 C: (IRIS XML request) 838 C: 839 C: 843 C: 844 C: 846 S: (response block) 847 S: 0x00 (block header: V=0,KO=no) 848 S: (chunk 1) 849 S: 0x07 (LC=no,DC=no,CT=ad) 850 S: 0x01 0xDA (chunk length=474) 851 S: (IRIS XML response) 852 S: 853 S: 854 S: 855 S: 859 S: milo.example.com 860 S: 861 S: 862 S: 863 S: 864 S: 865 S: 866 S: (chunk 2) 867 S: 0x07 (LC=no,DC=no,CT=ad) 868 S: 0x01 0xA2 (chunk length=418) 869 S: (IRIS XML response) 870 S: 871 S: 872 S: 876 S: felix.example.com 877 S: 878 S: 879 S: 880 S: 881 S: 882 S: 883 S: (chunk 3) 884 S: 0xC7 (LC=yes,DC=yes,CT=ad) 885 S: 0x01 0xB5 (chunk length=437) 886 S: (IRIS XML response) 887 S: 888 S: 889 S: 894 S: hobbes.example.com 895 S: 896 S: 897 S: 898 S: 899 S: 900 S: 901 S: 903 Figure 5: Example 1 905 In the following example, an IRIS client requests domain status 906 information for "milo.example.com", "felix.example.com", and 907 "hobbes.example.com" in one request. The request is sent with one 908 chunk, however the answer is returned in three chunks. 910 S: (connection response block) 911 S: 0x20 (block header: V=0,KO=yes) 912 S: (chunk 1) 913 S: 0xC1 (LC=yes,DC=yes,CT=vi) 914 S: 0x01 0xBE (chunk length=446) 915 S: (Version Information) 916 S: 917 S: 918 S: 920 S: 922 S: 923 S: 924 S: 925 S: 926 S: 928 C: (request block) 929 C: 0x00 (block header: V=0,KO=no) 930 C: 0x0B (authority length=11) 931 C: (authority="example.com") 932 C: 0x65 0x78 0x61 0x6D 0x70 0x6C 0x65 0x23 0x63 0x6F 0x6D 933 C: (chunk 1) 934 C: 0xC7 (LC=yes,DC=yes,CT=ad) 935 C: 0x02 0xAB (chunk length=683) 936 C: (IRIS XML request) 937 C: 940 C: 941 C: 945 C: 946 C: 947 C: 951 C: 952 C: 953 C: 957 C: 958 C: 960 S: (response block) 961 S: 0x00 (block header: V=0,KO=no) 962 S: (chunk 1) 963 S: 0x07 (LC=no,DC=no,CT=ad) 964 S: 0x01 0xDA (chunk length=474) 965 S: (IRIS XML response) 966 S: 967 S: 968 S: 969 S: 973 S: milo.example.com 974 S: 975 S: 976 S: 977 S: 978 S: 979 S: 980 S: (chunk 2) 981 S: 0x07 (LC=no,DC=no,CT=ad) 982 S: 0x01 0xA2 (chunk length=418) 983 S: (IRIS XML response) 984 S: 985 S: 986 S: 990 S: felix.example.com 991 S: 992 S: 993 S: 994 S: 995 S: 996 S: 997 S: (chunk 3) 998 S: 0xC7 (LC=yes,DC=yes,CT=ad) 999 S: 0x01 0xB5 (chunk length=437) 1000 S: (IRIS XML response) 1001 S: 1002 S: 1003 S: 1008 S: hobbes.example.com 1009 S: 1010 S: 1011 S: 1012 S: 1013 S: 1014 S: 1015 S: 1017 Figure 6: Example 2 1019 In the following example, an IRIS client sends a request containg 1020 SASL/PLAIN authentication data and a domain status check for 1021 "example.com". The server responds with authentication succss 1022 information and the domain status of "example.com". Note that the 1023 client requests that the connection stay open for further requests, 1024 but that the server does not honor this request. 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 0xBE (chunk length=446) 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: 0x44 (LC=no,DC=yes,CT=sd) 1051 C: 0x00 0x11 (chunk length=11) 1052 C: (SASL data) 1053 C: 0x05 (mechanism length=5) 1054 C: (mechanism name="PLAIN") 1055 C: 0x50 0x4C 0x41 0x49 0x43 1056 C: 0x0A (sasl PLAIN data length=10) 1057 C: (sasl PLAIN data: authcid="bob") 1058 C: (sasl PLAIN data: authzid=NULL) 1059 C: (sasl PLAIN data: password="kEw1") 1060 C: 0x62 0x6F 0x62 0x20 0x00 0x20 0x6B 0x45 0x77 0x31 1061 C: (chunk 2) 1062 C: 0xC7 (LC=yes,DC=yes,CT=ad) 1063 C: 0x01 0x53 (chunk length=339) 1064 C: (IRIS XML request) 1065 C: 1067 C: 1068 C: 1072 C: 1073 C: 1075 S: (response block) 1076 S: 0x00 (block header: V=0,KO=no) 1077 S: (chunk 1) 1078 S: 0x45 (LC=no,DC=yes,CT=as) 1079 S: 0x00 0xD0 (chunk length=208) 1080 S: (authentication success response) 1081 S: 1082 S: 1084 S: 1085 S: user 'bob' authenticates via password 1086 S: 1087 S: 1088 S: (chunk 2) 1089 S: 0xC7 (LC=yes,DC=yes,CT=ad) 1090 S: 0x01 0xE0 (chunk length=480) 1091 S: (IRIS XML response) 1092 S: 1093 S: 1094 S: 1095 S: 1099 S: example.com 1100 S: 1101 S: 1102 S: 1103 S: 1104 S: 1105 S: 1106 S: 1108 Figure 7: Example 3 1110 Appendix B. Contributors 1112 Substantive contributions to this document have been provided by the 1113 members of the IETF's CRISP Working Group, especially Robert Martin- 1114 Legene and David Blacka. 1116 Intellectual Property Statement 1118 The IETF takes no position regarding the validity or scope of any 1119 Intellectual Property Rights or other rights that might be claimed to 1120 pertain to the implementation or use of the technology described in 1121 this document or the extent to which any license under such rights 1122 might or might not be available; nor does it represent that it has 1123 made any independent effort to identify any such rights. Information 1124 on the procedures with respect to rights in RFC documents can be 1125 found in BCP 78 and BCP 79. 1127 Copies of IPR disclosures made to the IETF Secretariat and any 1128 assurances of licenses to be made available, or the result of an 1129 attempt made to obtain a general license or permission for the use of 1130 such proprietary rights by implementers or users of this 1131 specification can be obtained from the IETF on-line IPR repository at 1132 http://www.ietf.org/ipr. 1134 The IETF invites any interested party to bring to its attention any 1135 copyrights, patents or patent applications, or other proprietary 1136 rights that may cover technology that may be required to implement 1137 this standard. Please address the information to the IETF at 1138 ietf-ipr@ietf.org. 1140 Disclaimer of Validity 1142 This document and the information contained herein are provided on an 1143 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1144 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1145 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1146 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1147 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1148 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1150 Copyright Statement 1152 Copyright (C) The Internet Society (2005). This document is subject 1153 to the rights, licenses and restrictions contained in BCP 78, and 1154 except as set forth therein, the authors retain all their rights. 1156 Acknowledgment 1158 Funding for the RFC Editor function is currently provided by the 1159 Internet Society.