Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: August 8, 2005 February 7, 2005 XML Pipelining with Chunks for IRIS draft-newton-crisp-iris-xpc-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes a simple TCP transport binding for the Internet Registry Information Service (IRIS). Newton Expires August 8, 2005 [Page 1] Internet-Draft iris-xpc February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Terminology . . . . . . . . . . . . . . . . . . . . 4 3. Block Header . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Request Block . . . . . . . . . . . . . . . . . . . . . . . 6 5. Response Block . . . . . . . . . . . . . . . . . . . . . . . 7 6. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 No Data Types . . . . . . . . . . . . . . . . . . . . . . 9 6.2 Version Error Types . . . . . . . . . . . . . . . . . . . 9 6.3 Other Error Types . . . . . . . . . . . . . . . . . . . . 10 6.4 Basic Authentication Types . . . . . . . . . . . . . . . . 10 6.5 SASL Types . . . . . . . . . . . . . . . . . . . . . . . . 10 6.6 Application Data Types . . . . . . . . . . . . . . . . . . 11 7. Use over TLS . . . . . . . . . . . . . . . . . . . . . . . . 12 8. IRIS Transport Mapping Definitions . . . . . . . . . . . . . 13 8.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2 Application Protocol Label . . . . . . . . . . . . . . . . 13 9. Registrations . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 XPC URI Scheme Registration . . . . . . . . . . . . . . . 14 9.2 XPCS URI Scheme Registration . . . . . . . . . . . . . . . 14 9.3 S-NAPTR XPC Registration . . . . . . . . . . . . . . . . . 15 9.4 S-NAPTR XPCS Registration . . . . . . . . . . . . . . . . 15 10. Internationalization Considerations . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 11.1 S-NAPTR Registration . . . . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . 18 13. Normative References . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . 20 Newton Expires August 8, 2005 [Page 2] Internet-Draft iris-xpc February 2005 1. Introduction Using S-NAPTR, IRIS has the ability to define the use of multiple transports for different types of registry services, all at the descretion of the server operator. The TCP transport binding defined in this document is completely modular and may be used by any registry types. This transport binding defines simple framing for sending XML in chunks so that XML fragments may be acted upon (or pipelined) before the reception of the entire XML instance. This document calls this XML pipelining with chunks or XPC. XPC is for use with simple request and response interactions between clients and servers. Clients send requests to servers in data blocks and servers respond to clients with a corresponding data block. Request and response data blocks are sent using the TCP SEND function and received using the TCP RECEIVE function. Newton Expires August 8, 2005 [Page 3] Internet-Draft iris-xpc February 2005 2. Document Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [7]. Newton Expires August 8, 2005 [Page 4] Internet-Draft iris-xpc February 2005 3. Block Header Each data block starts with a one octet header called the block header. This header has the same format for both request and response data blocks, though some of the bits in the header only have meaning in one type of data block. Each bit in the block header has the following meaning: o bit 7 - version - If 0, the protocol is the version defined in this document. If 1, the rest of the bits in the header and the block may be interpreted as another version. o bit 6 - reserved - This MUST be 0. o bits 5 - keep open - If 1, the client is requesting the client not to close the TCP session. If 0, the client should expect the server to close the TCP session immediately after sending the corresponding response. This bit only has context in request blocks. o bit 4 - connection closing - If 0, the server will close the TCP session immediately following this block. This bit only has meaning in a response block. o bit 3, 2, 1, and 0 - reserved - These MUST be 0. Newton Expires August 8, 2005 [Page 5] Internet-Draft iris-xpc February 2005 4. Request Block The format for the request block is as follows: +--------+-----------+-----------+-------------+ field | header | authority | authority | chunks 1..n | | | length | | | +--------+-----------+-----------+-------------+ octets 1 1 0..255 variable These fields have the following meanings: o header - as described in Section 3. o authority length - the length of the authority field in this payload descriptor. o authority - a string of no more and no less octets describing the authority against wich this request is to be executed. See [1] for the definition and description of an authority. o chunks 1..n - the XML request data broken into chunks (Section 6). Newton Expires August 8, 2005 [Page 6] Internet-Draft iris-xpc February 2005 5. Response Block The format for the response block is as follows: +--------+-------------+ field | header | chunks 1..n | | | | +--------+-------------+ octets 1 variable These fields have the following meanings: o header - as described in Section 3. o chunks 1..n - the XML response data broken into chunks (Section 6). Newton Expires August 8, 2005 [Page 7] Internet-Draft iris-xpc February 2005 6. Chunks Request and response blocks break the request and response XML data down into chunks. Request and response blocks MUST always have a minimum of 1 chunk. Each chunk has a one octet descriptor, and the first bit of the desciptor determines if a chunk is the last chunk. The bits of the chunk descriptor octet have the following meaning: o bit 7 - last chunk - If 0, this chuck is the last chunk in the block. o bit 6 - completion - If 0, the data in this chunk represents the end of the data for the chunk type given. If this bit is never set to 0 in any chunk descriptor of a block, clients and servers MUST NOT assume the data will continue in another block. If the block transitions from one type of chunk to another with out signaling completion of the data, clients and servers MUST assume that the remaining data will not be sent in a remaining chunk. o bits 5, 4, and 3 - reserved - These MUST be 0. o bit 2, 1, and 0 - chunk type - determines the type of data carried in the chunk. These are the binary values for the chunk types: * 000 - no data * 001 - version error * 010 - reserved * 011 - other error * 100 - basic authentication * 101 - SASL data * 110 - reserved * 111 - application data A block MAY have multiple types of chunks, but all chunks of the same type MUST be contingous in a block and MUST be ordered in the block in the order in which their data is to be intepretted. Contiguous chunks must by ordered by type within a block in the following way: 1. authentication chunks - either basic authentication chunks (type 100) or SASL data chunks (type 101), but not both. 2. data chunks - either no data chunks (type 000) or application data chunks (type 111), but not both. 3. error chunks - either version error (type 001) or other error (type 011), but not both. A block MUST have at least one type of the above chunks. The format for a chunk is as follows: Newton Expires August 8, 2005 [Page 8] Internet-Draft iris-xpc February 2005 +-----------+------------+--------+ field | chunk | chunk data | chunk | | descriptor| length | data | +-----------+------------+--------+ octets 1 2 variable These fields have the following meanings: o chunk descriptor - as described above. o chunk data length - the length of the data of the chunk o chunk data - the data of the chunk 6.1 No Data Types Servers and clients MUST ignore data in chunk types labeled no data. There is no requirement for these types of chunks to be zero length. A client MAY send "no data" to a server, and the server MUST respond with either a version error or other error. 6.2 Version Error Types Chunks of this type contain an XML instance conformant to the schema identified by the namespace urn:ietf:params:xml:ns:iris-transport specified in IRIS-LWZ [3]. These XML instances must have the element as their root element. The element has child elements that describe the relationship between transport bindings, protocol versions, and data models. Each of these child elements has a 'protocolId' attribute identifying the protocol they represent. In the context of IRIS, the protocol identifiers for these elements are as follows: o - the value "iris.xpc1" to indicate the protocol specified in this document. o - the XML namespace identifier for IRIS. o - the XML namespace identifier for IRIS registries. The following is an example of an XML instance describing the version error. Newton Expires August 8, 2005 [Page 9] Internet-Draft iris-xpc February 2005 6.3 Other Error Types Chunks of this type contain an XML instance conformant to the schema identified by the namespace urn:ietf:params:xml:ns:iris-transport specified in IRIS-LWZ [3]. These XML instances must have the element as their root element. The following is an example of an XML instance describing this type of error. unavailable, come back later 6.4 Basic Authentication Types The basic authentication chunk type allows a client to authenticate user credentials to a server. This type of authentication is simple user name and plain password authentication. Because the password is passed in the clear, this type of authentication MUST never be used over an unencrypted TCP session. The format for the data of this type of chunk is as follows: +-----------+-----------+----------+----------+ field | user name | user name | password | password | | length | | length | | +-----------+-----------+----------+----------+ octets 1 variable 1 variable These fields have the following meaning: o user name length - the length of the user name o user name - the name of the user being authenticated o password length - the length of the password o password - the password of the user being authenticated These fields MUST NOT span multiple chunks. 6.5 SASL Types The SASL chunk type allows clients and servers to exchange SASL data. The format for the data of this type of chunk is as follows: Newton Expires August 8, 2005 [Page 10] Internet-Draft iris-xpc February 2005 +--------------+--------------+--------------+--------------+ field | profile name | profile name | profile data | profile data | | length | | length | | +--------------+--------------+--------------+--------------+ octets 1 variable 2 variable These fields have the following meaning: o profile name length - the length of the SASL profile name o profile - the name of the SASL profile o profile data length - the length of the SASL data o profile data - the data used for SASL These fields MUST NOT span multiple chunks. Therefore it should be noted that SASL data length exceeding the length of the chunk minus the length of SASL profile name minus one is an error. 6.6 Application Data Types These chunks contain application data. For IRIS, these are IRIS [1] XML instances. Newton Expires August 8, 2005 [Page 11] Internet-Draft iris-xpc February 2005 7. Use over TLS XPC may be tunneled over TLS [4] by establishing a TLS session immediately after a TCP session is opened and before any blocks are to be sent. This type of session is known as XPCS. When using TLS, a convention must be established to allow a client to authenticate the validity of a server. XPCS uses the same convention as described by IRIS-BEEP [2]. Newton Expires August 8, 2005 [Page 12] Internet-Draft iris-xpc February 2005 8. IRIS Transport Mapping Definitions This section lists the definitions required by IRIS [1] for transport mappings. 8.1 URI Scheme The URI scheme name specific to XPC MUST be "iris.xpc". The URI scheme name specific to XPCS MUST be "iris.xpcs". 8.2 Application Protocol Label The application protocol label for XPC MUST be "iris.xpc". The application protocol label for XPCS MUST be "iris.xpcs". Newton Expires August 8, 2005 [Page 13] Internet-Draft iris-xpc February 2005 9. Registrations 9.1 XPC URI Scheme Registration URL scheme name: iris.xpc URL scheme syntax: defined in Section 8.1 and [1]. Character encoding considerations: as defined in RFC2396 [5]. Intended usage: identifies IRIS XML using chunks over TCP Applications using this scheme: defined in IRIS [1]. Interoperability considerations: n/a Security Considerations: defined in Section 12. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton Author/Change controller: the IESG 9.2 XPCS URI Scheme Registration URL scheme name: iris.xpcs URL scheme syntax: defined in Section 8.1 and [1]. Character encoding considerations: as defined in RFC2396 [5]. Intended usage: identifies IRIS XML using chunks over TLS Applications using this scheme: defined in IRIS [1]. Interoperability considerations: n/a Security Considerations: defined in Section 12. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton Author/Change controller: the IESG Newton Expires August 8, 2005 [Page 14] Internet-Draft iris-xpc February 2005 9.3 S-NAPTR XPC Registration Application Protocol Label: iris.xpc Intended usage: identifies an IRIS server using XPC Interoperability considerations: n/a Security Considerations: defined in Section 12. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton Author/Change controller: the IESG 9.4 S-NAPTR XPCS Registration Application Protocol Label: iris.xpc Intended usage: identifies an IRIS server using secure XPCS Interoperability considerations: n/a Security Considerations: defined in Section 12. Relevant Publications: IRIS [1]. Contact Information: Andrew Newton Author/Change controller: the IESG Newton Expires August 8, 2005 [Page 15] Internet-Draft iris-xpc February 2005 10. Internationalization Considerations Implementers should be aware of considerations for internationalization in IRIS [1]. Planned revisions to SASL/PLAIN normalize the name of the user for authentication purposes. Basic authentication is provided in XPC for backwards compatibility with systems that cannot perform this normalization. Where possible, SASL/PLAIN SHOULD be used. Newton Expires August 8, 2005 [Page 16] Internet-Draft iris-xpc February 2005 11. IANA Considerations 11.1 S-NAPTR Registration Registrations with the IANA are described in Section 9. Newton Expires August 8, 2005 [Page 17] Internet-Draft iris-xpc February 2005 12. Security Considerations Implementers should be fully aware of the security considerations given by IRIS [1] and TLS [4]. With respect to server authentication with the use of TLS, see Section 6 of IRIS-BEEP [2]. Clients SHOULD be prepared to use the following SASL profiles in the following manner: o SASL/DIGEST-MD5 - for user authentication without the need of session encryption. o SASL/OTP - for user authentication without the need of session encryption. o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher - for encryption. o TLS using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher with client-side certificates - for encryption and user authentication. o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher - for encryption. See [6]. o TLS using the TLS_RSA_WITH_AES_128_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [6]. o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher - for encryption. See [6]. o TLS using the TLS_RSA_WITH_AES_256_CBC_SHA cipher with client-side certificates - for encryption and user authentication. See [6]. Anonymous client access SHOULD be considered in one of two methods: 1. When no authentication has been used. 2. Using the SASL anonymous profile: SASL/ANONYMOUS As specified by SASL/PLAIN, clients MUST NOT use the SASL/PLAIN profile without first encrypting the TCP session (e.g. such as with TLS). The XPC basic authentication mechanism is a simple version of the SASL/PLAIN profile. It is intended for use with legacy systems where some of the normalization methods of SASL/PLAIN may be problematic. Clients MUST NOT use basic authentication with first encrypting the TCP session (e.g. such as with TLS). 13 Normative References [1] Newton, A. and M. Sanz, "Internet Registry Information Service", RFC 3891, January 2004. [2] Newton, A. and M. Sanz, "Using the Internet Registry Information Service over the Blocks Extensible Exchange Protocol", RFC 3893, January 2004. Newton Expires August 8, 2005 [Page 18] Internet-Draft iris-xpc February 2005 [3] Newton, A., "A Lightweight UDP Transport for the the Internet Registry Information Service", draft-ietf-crisp-iris-lwz-00.txt (work in progress), January 2004. [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [8] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, February 2004. Author's Address Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/ Newton Expires August 8, 2005 [Page 19] Internet-Draft iris-xpc February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Newton Expires August 8, 2005 [Page 20]