idnits 2.17.1 draft-newton-crisp-iris-xpc-00.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 544), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 474 has weird spacing: '...for the the I...' -- 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 (February 7, 2005) is 6980 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) == Unused Reference: '8' is defined on line 491, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-crisp-iris-lwz-00 ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2396 (ref. '5') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3268 (ref. '6') (Obsoleted by RFC 5246) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Newton 2 Internet-Draft VeriSign, Inc. 3 Expires: August 8, 2005 February 7, 2005 5 XML Pipelining with Chunks for IRIS 6 draft-newton-crisp-iris-xpc-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 8, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes a simple TCP transport binding for the 40 Internet Registry Information Service (IRIS). 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 46 3. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 5 47 4. Request Block . . . . . . . . . . . . . . . . . . . . . . . 6 48 5. Response Block . . . . . . . . . . . . . . . . . . . . . . . 7 49 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 50 6.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 9 51 6.2 Version Error Types . . . . . . . . . . . . . . . . . . . 9 52 6.3 Other Error Types . . . . . . . . . . . . . . . . . . . . 10 53 6.4 Basic Authentication Types . . . . . . . . . . . . . . . . 10 54 6.5 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 10 55 6.6 Application Data Types . . . . . . . . . . . . . . . . . . 11 56 7. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 12 57 8. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 13 58 8.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 59 8.2 Application Protocol Label . . . . . . . . . . . . . . . . 13 60 9. Registrations . . . . . . . . . . . . . . . . . . . . . . . 14 61 9.1 XPC URI Scheme Registration . . . . . . . . . . . . . . . 14 62 9.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . . 14 63 9.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . . 15 64 9.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . . 15 65 10. Internationalization Considerations . . . . . . . . . . . . 16 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 67 11.1 S-NAPTR Registration . . . . . . . . . . . . . . . . . . 17 68 12. Security Considerations . . . . . . . . . . . . . . . . . . 18 69 13. Normative References . . . . . . . . . . . . . . . . . . . . 18 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 71 Intellectual Property and Copyright Statements . . . . . . . 20 73 1. Introduction 75 Using S-NAPTR, IRIS has the ability to define the use of multiple 76 transports for different types of registry services, all at the 77 descretion of the server operator. The TCP transport binding defined 78 in this document is completely modular and may be used by any 79 registry types. 81 This transport binding defines simple framing for sending XML in 82 chunks so that XML fragments may be acted upon (or pipelined) before 83 the reception of the entire XML instance. This document calls this 84 XML pipelining with chunks or XPC. 86 XPC is for use with simple request and response interactions between 87 clients and servers. Clients send requests to servers in data blocks 88 and servers respond to clients with a corresponding data block. 89 Request and response data blocks are sent using the TCP SEND function 90 and received using the TCP RECEIVE function. 92 2. Document Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC2119 [7]. 98 3. Block Header 100 Each data block starts with a one octet header called the block 101 header. This header has the same format for both request and 102 response data blocks, though some of the bits in the header only have 103 meaning in one type of data block. Each bit in the block header has 104 the following meaning: 105 o bit 7 - version - If 0, the protocol is the version defined in 106 this document. If 1, the rest of the bits in the header and the 107 block may be interpreted as another version. 108 o bit 6 - reserved - This MUST be 0. 109 o bits 5 - keep open - If 1, the client is requesting the client not 110 to close the TCP session. If 0, the client should expect the 111 server to close the TCP session immediately after sending the 112 corresponding response. This bit only has context in request 113 blocks. 114 o bit 4 - connection closing - If 0, the server will close the TCP 115 session immediately following this block. This bit only has 116 meaning in a response block. 117 o bit 3, 2, 1, and 0 - reserved - These MUST be 0. 119 4. Request Block 121 The format for the request block is as follows: 123 +--------+-----------+-----------+-------------+ 124 field | header | authority | authority | chunks 1..n | 125 | | length | | | 126 +--------+-----------+-----------+-------------+ 127 octets 1 1 0..255 variable 129 These fields have the following meanings: 130 o header - as described in Section 3. 131 o authority length - the length of the authority field in this 132 payload descriptor. 133 o authority - a string of no more and no less octets describing the 134 authority against wich this request is to be executed. See [1] 135 for the definition and description of an authority. 136 o chunks 1..n - the XML request data broken into chunks (Section 6). 138 5. Response Block 140 The format for the response block is as follows: 142 +--------+-------------+ 143 field | header | chunks 1..n | 144 | | | 145 +--------+-------------+ 146 octets 1 variable 148 These fields have the following meanings: 149 o header - as described in Section 3. 150 o chunks 1..n - the XML response data broken into chunks (Section 151 6). 153 6. Chunks 155 Request and response blocks break the request and response XML data 156 down into chunks. Request and response blocks MUST always have a 157 minimum of 1 chunk. Each chunk has a one octet descriptor, and the 158 first bit of the desciptor determines if a chunk is the last chunk. 160 The bits of the chunk descriptor octet have the following meaning: 161 o bit 7 - last chunk - If 0, this chuck is the last chunk in the 162 block. 163 o bit 6 - completion - If 0, the data in this chunk represents the 164 end of the data for the chunk type given. If this bit is never 165 set to 0 in any chunk descriptor of a block, clients and servers 166 MUST NOT assume the data will continue in another block. If the 167 block transitions from one type of chunk to another with out 168 signaling completion of the data, clients and servers MUST assume 169 that the remaining data will not be sent in a remaining chunk. 170 o bits 5, 4, and 3 - reserved - These MUST be 0. 171 o bit 2, 1, and 0 - chunk type - determines the type of data carried 172 in the chunk. These are the binary values for the chunk types: 173 * 000 - no data 174 * 001 - version error 175 * 010 - reserved 176 * 011 - other error 177 * 100 - basic authentication 178 * 101 - SASL data 179 * 110 - reserved 180 * 111 - application data 182 A block MAY have multiple types of chunks, but all chunks of the same 183 type MUST be contingous in a block and MUST be ordered in the block 184 in the order in which their data is to be intepretted. Contiguous 185 chunks must by ordered by type within a block in the following way: 186 1. authentication chunks - either basic authentication chunks (type 187 100) or SASL data chunks (type 101), but not both. 188 2. data chunks - either no data chunks (type 000) or application 189 data chunks (type 111), but not both. 190 3. error chunks - either version error (type 001) or other error 191 (type 011), but not both. 192 A block MUST have at least one type of the above chunks. 194 The format for a chunk is as follows: 196 +-----------+------------+--------+ 197 field | chunk | chunk data | chunk | 198 | descriptor| length | data | 199 +-----------+------------+--------+ 200 octets 1 2 variable 202 These fields have the following meanings: 203 o chunk descriptor - as described above. 204 o chunk data length - the length of the data of the chunk 205 o chunk data - the data of the chunk 207 6.1 No Data Types 209 Servers and clients MUST ignore data in chunk types labeled no data. 210 There is no requirement for these types of chunks to be zero length. 211 A client MAY send "no data" to a server, and the server MUST respond 212 with either a version error or other error. 214 6.2 Version Error Types 216 Chunks of this type contain an XML instance conformant to the schema 217 identified by the namespace urn:ietf:params:xml:ns:iris-transport 218 specified in IRIS-LWZ [3]. These XML instances must have the 219 element as their root element. 221 The element has child elements that describe the 222 relationship between transport bindings, protocol versions, and data 223 models. Each of these child elements has a 'protocolId' attribute 224 identifying the protocol they represent. In the context of IRIS, the 225 protocol identifiers for these elements are as follows: 226 o - the value "iris.xpc1" to indicate the 227 protocol specified in this document. 228 o - the XML namespace identifier for IRIS. 229 o - the XML namespace identifier for IRIS registries. 231 The following is an example of an XML instance describing the version 232 error. 234 235 236 237 238 239 240 241 243 6.3 Other Error Types 245 Chunks of this type contain an XML instance conformant to the schema 246 identified by the namespace urn:ietf:params:xml:ns:iris-transport 247 specified in IRIS-LWZ [3]. These XML instances must have the 248 element as their root element. 250 The following is an example of an XML instance describing this type 251 of error. 253 255 unavailable, come back later 256 258 6.4 Basic Authentication Types 260 The basic authentication chunk type allows a client to authenticate 261 user credentials to a server. This type of authentication is simple 262 user name and plain password authentication. Because the password is 263 passed in the clear, this type of authentication MUST never be used 264 over an unencrypted TCP session. 266 The format for the data of this type of chunk is as follows: 268 +-----------+-----------+----------+----------+ 269 field | user name | user name | password | password | 270 | length | | length | | 271 +-----------+-----------+----------+----------+ 272 octets 1 variable 1 variable 274 These fields have the following meaning: 275 o user name length - the length of the user name 276 o user name - the name of the user being authenticated 277 o password length - the length of the password 278 o password - the password of the user being authenticated 279 These fields MUST NOT span multiple chunks. 281 6.5 SASL Types 283 The SASL chunk type allows clients and servers to exchange SASL data. 285 The format for the data of this type of chunk is as follows: 287 +--------------+--------------+--------------+--------------+ 288 field | profile name | profile name | profile data | profile data | 289 | length | | length | | 290 +--------------+--------------+--------------+--------------+ 291 octets 1 variable 2 variable 293 These fields have the following meaning: 294 o profile name length - the length of the SASL profile name 295 o profile - the name of the SASL profile 296 o profile data length - the length of the SASL data 297 o profile data - the data used for SASL 298 These fields MUST NOT span multiple chunks. Therefore it should be 299 noted that SASL data length exceeding the length of the chunk minus 300 the length of SASL profile name minus one is an error. 302 6.6 Application Data Types 304 These chunks contain application data. For IRIS, these are IRIS [1] 305 XML instances. 307 7. Use over TLS 309 XPC may be tunneled over TLS [4] by establishing a TLS session 310 immediately after a TCP session is opened and before any blocks are 311 to be sent. This type of session is known as XPCS. 313 When using TLS, a convention must be established to allow a client to 314 authenticate the validity of a server. XPCS uses the same convention 315 as described by IRIS-BEEP [2]. 317 8. IRIS Transport Mapping Definitions 319 This section lists the definitions required by IRIS [1] for transport 320 mappings. 322 8.1 URI Scheme 324 The URI scheme name specific to XPC MUST be "iris.xpc". The URI 325 scheme name specific to XPCS MUST be "iris.xpcs". 327 8.2 Application Protocol Label 329 The application protocol label for XPC MUST be "iris.xpc". The 330 application protocol label for XPCS MUST be "iris.xpcs". 332 9. Registrations 334 9.1 XPC URI Scheme Registration 336 URL scheme name: iris.xpc 338 URL scheme syntax: defined in Section 8.1 and [1]. 340 Character encoding considerations: as defined in RFC2396 [5]. 342 Intended usage: identifies IRIS XML using chunks over TCP 344 Applications using this scheme: defined in IRIS [1]. 346 Interoperability considerations: n/a 348 Security Considerations: defined in Section 12. 350 Relevant Publications: IRIS [1]. 352 Contact Information: Andrew Newton 354 Author/Change controller: the IESG 356 9.2 XPCS URI Scheme Registration 358 URL scheme name: iris.xpcs 360 URL scheme syntax: defined in Section 8.1 and [1]. 362 Character encoding considerations: as defined in RFC2396 [5]. 364 Intended usage: identifies IRIS XML using chunks over TLS 366 Applications using this scheme: defined in IRIS [1]. 368 Interoperability considerations: n/a 370 Security Considerations: defined in Section 12. 372 Relevant Publications: IRIS [1]. 374 Contact Information: Andrew Newton 376 Author/Change controller: the IESG 378 9.3 S-NAPTR XPC Registration 380 Application Protocol Label: iris.xpc 382 Intended usage: identifies an IRIS server using XPC 384 Interoperability considerations: n/a 386 Security Considerations: defined in Section 12. 388 Relevant Publications: IRIS [1]. 390 Contact Information: Andrew Newton 392 Author/Change controller: the IESG 394 9.4 S-NAPTR XPCS Registration 396 Application Protocol Label: iris.xpc 398 Intended usage: identifies an IRIS server using secure XPCS 400 Interoperability considerations: n/a 402 Security Considerations: defined in Section 12. 404 Relevant Publications: IRIS [1]. 406 Contact Information: Andrew Newton 408 Author/Change controller: the IESG 410 10. Internationalization Considerations 412 Implementers should be aware of considerations for 413 internationalization in IRIS [1]. 415 Planned revisions to SASL/PLAIN normalize the name of the user for 416 authentication purposes. Basic authentication is provided in XPC for 417 backwards compatibility with systems that cannot perform this 418 normalization. Where possible, SASL/PLAIN SHOULD be used. 420 11. IANA Considerations 422 11.1 S-NAPTR Registration 424 Registrations with the IANA are described in Section 9. 426 12. Security Considerations 428 Implementers should be fully aware of the security considerations 429 given by IRIS [1] and TLS [4]. With respect to server authentication 430 with the use of TLS, see Section 6 of IRIS-BEEP [2]. 432 Clients SHOULD be prepared to use the following SASL profiles in the 433 following manner: 434 o SASL/DIGEST-MD5 - for user authentication without the need of 435 session encryption. 436 o SASL/OTP - for user authentication without the need of session 437 encryption. 438 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for 439 encryption. 440 o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with 441 client-side certificates - for encryption and user authentication. 442 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for 443 encryption. See [6]. 444 o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side 445 certificates - for encryption and user authentication. See [6]. 446 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for 447 encryption. See [6]. 448 o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side 449 certificates - for encryption and user authentication. See [6]. 451 Anonymous client access SHOULD be considered in one of two methods: 452 1. When no authentication has been used. 453 2. Using the SASL anonymous profile: SASL/ANONYMOUS 455 As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN 456 profile without first encrypting the TCP session (e.g. such as with 457 TLS). 459 The XPC basic authentication mechanism is a simple version of the 460 SASL/PLAIN profile. It is intended for use with legacy systems where 461 some of the normalization methods of SASL/PLAIN may be problematic. 462 Clients MUST NOT use basic authentication with first encrypting the 463 TCP session (e.g. such as with TLS). 465 13 Normative References 467 [1] Newton, A. and M. Sanz, "Internet Registry Information Service", 468 RFC 3891, January 2004. 470 [2] Newton, A. and M. Sanz, "Using the Internet Registry Information 471 Service over the Blocks Extensible Exchange Protocol", RFC 3893, 472 January 2004. 474 [3] Newton, A., "A Lightweight UDP Transport for the the Internet 475 Registry Information Service", draft-ietf-crisp-iris-lwz-00.txt 476 (work in progress), January 2004. 478 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 479 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 480 1999. 482 [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 483 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 485 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 486 Transport Layer Security (TLS)", RFC 3268, June 2002. 488 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 489 Levels", RFC 2119, BCP 14, March 1997. 491 [8] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, 492 February 2004. 494 Author's Address 496 Andrew L. Newton 497 VeriSign, Inc. 498 21345 Ridgetop Circle 499 Sterling, VA 20166 500 USA 502 Phone: +1 703 948 3382 503 EMail: anewton@verisignlabs.com; andy@hxr.us 504 URI: http://www.verisignlabs.com/ 506 Intellectual Property Statement 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed to 510 pertain to the implementation or use of the technology described in 511 this document or the extent to which any license under such rights 512 might or might not be available; nor does it represent that it has 513 made any independent effort to identify any such rights. Information 514 on the procedures with respect to rights in RFC documents can be 515 found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use of 520 such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository at 522 http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at 528 ietf-ipr@ietf.org. 530 Disclaimer of Validity 532 This document and the information contained herein are provided on an 533 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 534 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 535 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 536 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 537 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 538 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 540 Copyright Statement 542 Copyright (C) The Internet Society (2005). This document is subject 543 to the rights, licenses and restrictions contained in BCP 78, and 544 except as set forth therein, the authors retain all their rights. 546 Acknowledgment 548 Funding for the RFC Editor function is currently provided by the 549 Internet Society.