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
<versions> element as their root element.
The <versions> 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 <transportBinding> - the value "iris.xpc1" to indicate the
protocol specified in this document.
o <application> - the XML namespace identifier for IRIS.
o <dataModel> - the XML namespace identifier for IRIS registries.
The following is an example of an XML instance describing the version
error.
<versions xmlns="urn:ietf:params:xml:ns:iris-transport">
<transportBinding protocolId="iris.xpc1">
<application protocolId="urn:ietf:params:xml:ns:iris1">
<dataModel protocolId="urn:ietf:params:xml:ns:dchk1"/>
<dataModel protocolId="urn:ietf:params:xml:ns:dreg1"/>
</application>
</transportBinding>
</versions>
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 <error>
element as their root element.
The following is an example of an XML instance describing this type
of error.
<error xmlns="urn:ietf:params:xml:ns:iris-transport"
type="system">
<description language="en">unavailable, come back later</description>
</error>
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 <andy@hxr.us>
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 <andy@hxr.us>
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 <andy@hxr.us>
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 <andy@hxr.us>
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]