Request for Comments: 3652 S. Reilly
Category: Informational L. Lannom
J. Petrone
CNRI
November 2003
Handle System Protocol (ver 2.1) Specification
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
IESG Note
Several groups within the IETF and IRTF have discussed the Handle
System and its relationship to existing systems of identifiers. The
IESG wishes to point out that these discussions have not resulted in
IETF consensus on the described Handle System, nor on how it might
fit into the IETF architecture for identifiers. Though there has
been discussion of handles as a form of URI, specifically as a URN,
these documents describe an alternate view of how namespaces and
identifiers might work on the Internet and include characterizations
of existing systems which may not match the IETF consensus view.
Abstract
The Handle System is a general-purpose global name service that
allows secured name resolution and administration over the public
Internet. This document describes the protocol used for client
software to access the Handle System for both handle resolution and
administration. The protocol specifies the procedure for a client
software to locate the responsible handle server of any given handle.
It also defines the messages exchanged between the client and server
for any handle operation.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
2.2.4. Message Credential . . . . . . . . . . . . . . . 18
2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
3.1.1. Global Handle Registry and its Service
Information. . . . . . . . . . . . . . . . . . . 21
3.1.2. Locating the Handle System Service Component . . 22
3.1.3. Selecting the Responsible Server . . . . . . . . 23
3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
3.2.2. Successful Query Response. . . . . . . . . . . . 25
3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
3.3. Error Response from Server . . . . . . . . . . . . . . . 26
3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
3.5.1. Challenge from Server to Client. . . . . . . . . 29
3.5.2. Challenge-Response from Client to Server . . . . 30
3.5.3. Challenge-Response Verification-Request. . . . . 33
3.5.4. Challenge-Response Verification-Response . . . . 33
3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
3.7.1. List Handle(s) under a Naming Authority. . . . . 40
3.7.2. List Sub-Naming Authorities under a Naming
Authority. . . . . . . . . . . . . . . . . . . . 41
3.8. Session and Session Management . . . . . . . . . . . . . 42
3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
3.8.2. Session Setup Response . . . . . . . . . . . . . 46
3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
3.8.4. Session Termination. . . . . . . . . . . . . . . 48
4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. Informative References . . . . . . . . . . . . . . . . . . . . 50
8. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 52
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
1. Overview
The Handle System provides a general-purpose, secured global name
service for the Internet. It was originally conceived and described
in a paper by Robert Kahn and Robert Wilensky [18] in 1995. The
Handle System defines a client server protocol in which client
software submits requests via a network to handle servers. Each
request describes the operation to be performed on the server. The
server will process the request and return a message indicating the
result of the operation. This document specifies the protocol for
client software to access a handle server for handle resolution and
administration. It does not include the description of the protocol
used to manage handle servers. A discussion of the management
protocol is out of the scope of this document and will be made
available in a separate document. The document assumes that readers
are familiar with the basic concepts of the Handle System as
introduced in the "Handle System Overview" [1], as well as the data
model and service definition given in the "Handle System Namespace
and Service Definition" [2].
The Handle System consists of a set of service components as defined
in [2]. From the client’s point of view, the Handle System is a
distributed database for handles. Different handles under the Handle
System may be maintained by different handle servers at different
network locations. The Handle protocol specifies the procedure for a
client to locate the responsible handle server of any given handle.
It also defines the messages exchanged between the client and server
for any handle operation.
Some key aspects of the Handle protocol include:
o The Handle protocol supports both handle resolution and
administration. The protocol follows the data and service
model defined in [2].
o A client may authenticate any server response based on the
server’s digital signature.
o A server may authenticate its client as handle administrator
via the Handle authentication protocol. The Handle
authentication protocol is a challenge-response protocol that
supports both public-key and secret-key based authentication.
o A session may be established between the client and server so
that authentication information and network resources (e.g.,
TCP connection) may be shared among multiple operations. A
session key can be established to achieve data integrity and
confidentiality.
o The protocol can be extended to support new operations.
Controls can be used to extend the existing operations. The
protocol is defined to allow future backward compatibility.
o Distributed service architecture. Support service referral
among different service components.
o Handles and their data types are based on the ISO-10646
(Unicode 2.0) character set. UTF-8 [3] is the mandated
encoding under the Handle protocol.
The Handle protocol (version 2.1) specified in this document has
changed significantly from its earlier versions. These changes are
necessary due to changes made in the Handle System data model and the
service model. Servers that implement this protocol may continue to
support earlier versions of the protocol by checking the protocol
version specified in the Message Envelope (see section 2.2.1).
2. Protocol Elements
2.1. Conventions
The following conventions are followed by the Handle protocol to
ensure interoperability among different implementations.
2.1.1. Data Transmission Order
The order of transmission of data packets follows the network byte
order (also called the Big-Endian [11]). That is, when a data-gram
consists of a group of octets, the order of transmission of those
octets follows their natural order from left to right and from top to
bottom, as they are read in English. For example, in the following
diagram, the octets are transmitted in the order they are numbered.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.-------------------------------.
| 1 | 2 |
|-------------------------------|
| 3 | 4 |
|-------------------------------|
| 5 | 6 |
’-------------------------------’
If an octet represents a numeric quantity, the left most bit is the
most significant bit. For example, the following diagram represents
the value 170 (decimal).
0 1 2 3 4 5 6 7
.---------------.
|1 0 1 0 1 0 1 0|
’---------------’
Similarly, whenever a multi-octet field represents a numeric
quantity, the left most bit is the most significant bit and the most
significant octet of the whole field is transmitted first.
2.1.2. Transport Layer
The Handle protocol is designed so that messages may be transmitted
either as separate data-grams over UDP or as a continuous byte stream
via a TCP connection. The recommended port number for both UDP and
TCP is 2641.
UDP Usage
Messages carried by UDP are restricted to 512 bytes (not including
the IP or UDP header). Longer messages must be fragmented into
UDP packets where each packet carries a proper sequence number in
the Message Envelope (see Section 2.2.1).
The optimum retransmission policy will vary depending on the
network or server performance, but the following are recommended:
o The client should try other servers or service interfaces
before repeating a request to the same server address.
o The retransmission interval should be based on prior
statistics if possible. Overly aggressive retransmission
should be avoided to prevent network congestion. The
recommended retransmission interval is 2-5 seconds.
o When transmitting large amounts of data, TCP-friendly
congestion control, such as an interface to the Congestion
Manager [12], should be implemented whenever possible to
avoid unfair consumption of the bandwidth against TCP-based
applications. Details of the congestion control will be
discussed in a separate document.
TCP Usage
Messages under the Handle protocol can be mapped directly into a
TCP byte-stream. However, the size of each message is limited by
the range of a 4-byte unsigned integer. Longer messages may be
fragmented into multiple messages before the transmission and
reassembled at the receiving end.
Several connection management policies are recommended:
o The server should support multiple connections and should
not block other activities waiting for TCP data.
o By default, the server should close the connection after
completing the request. However, if the request asks to
keep the connection open, the server should assume that the
client will initiate connection closing.
2.1.3. Character Case
Handles are character strings based on the ISO-10646 character set
and must be encoded in UTF-8. By default, handle characters are
treated as case-sensitive under the Handle protocol. A handle
service, however, may be implemented in such a way that ASCII
characters are processed case-insensitively. For example, the Global
Handle Registry (GHR) provides a handle service where ASCII
characters are processed in a case-insensitive manner. This suggests
that ASCII characters in any naming authority are case-insensitive.
When handles are created under a case-insensitive handle server,
their original case should be preserved. To avoid any confusion, the
server should avoid creating any handle whose character string
matches that of an existing handle, ignoring the case difference.
For example, if the handle "X/Y" was already created, the server
should refuse any request to create the handle "x/y" or any of its
case variations.
2.1.4. Standard String Type: UTF8-String
Handles are transmitted as UTF8-Strings under the Handle protocol.
Throughout this document, UTF8-String stands for the data type that
consists of a 4-byte unsigned integer followed by a character string
in UTF-8 encoding. The leading integer specifies the number of
octets of the character string.
2.2. Common Elements
Each message exchanged under the system protocol consists of four
sections (see Fig. 2.2). Some of these sections (e.g., the Message
Body) may be empty depending on the protocol operation.
The Message Envelope must always be present. It has a fixed size of
20 octets. The Message Envelope does not carry any application layer
information and is primarily used to help deliver the message.
Content in the Message Envelope is not protected by the digital
signature in the Message Credential.
The Message Header must always be present as well. It has a fixed
size of 24 octets and holds the common data fields of all messages
exchanged between client and server. These include the operation
code, the response code, and the control options for each protocol
operation. Content in the Message Header is protected by the digital
signature in the Message Credential.
The Message Body contains data specific to each protocol operation.
Its format varies according to the operation code and the response
code in the Message Header. The Message Body may be empty. Content
in the Message Body is protected by the digital signature in the
Message Credential.
The Message Credential provides a mechanism for transport security
for any message exchanged between the client and server. A non-empty
Message Credential may contain the digital signature from the
originator of the message or the one-way Message Authentication Code
(MAC) based on a pre-established session key. The Message Credential
may be used to authenticate the message between the client and
server. It can also be used to check data integrity after its
transmission.
.----------------------.
| | ; Message wrapper for proper message
| Message Envelope | ; delivery. Not protected by the
| | ; digital signature in the Message
| | ; Credential.
|----------------------|
| | ; Common data fields for all handle
| Message Header | ; operations.
| |
|----------------------|
| | ; Specific data fields for each
| Message Body | ; request/response.
| |
|----------------------|
| | ; Contains digital signature or
| Message Credential | ; message authentication code (MAC)
| | ; upon Message Header and Message
’----------------------’ ; Body.
Fig 2.2: Message format under the Handle protocol
2.2.1. Message Envelope
Each message begins with a Message Envelope under the Handle
protocol. If a message has to be truncated before its transmission,
each truncated portion must also begin with a Message Envelope.
The Message Envelope allows the reassembly of the message at the
receiving end. It has a fixed size of 20 octets and consists of
seven fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| MajorVersion | MinorVersion | MessageFlag |
|---------------------------------------------------------------|
| SessionId |
|---------------------------------------------------------------|
| RequestId |
|---------------------------------------------------------------|
| SequenceNumber |
|---------------------------------------------------------------|
| MessageLength |
’---------------------------------------------------------------’
2.2.1.1. <MajorVersion> and <MinorVersion>
The <MajorVersion> and <MinorVersion> are used to identify the
version of the Handle protocol. Each of them is defined as a one-
byte unsigned integer. This specification defines the protocol
version whose <MajorVersion> is 2 and <MinorVersion> is 1.
<MajorVersion> and <MinorVersion> are designed to allow future
backward compatibility. A difference in <MajorVersion> indicates
major variation in the protocol format and the party with the lower
<MajorVersion> will have to upgrade its software to ensure precise
communication. An increment in <MinorVersion> is made when
additional capabilities are added to the protocol without any major
change to the message format.
2.2.1.2. <MessageFlag>
The <MessageFlag> consists of two octets defined as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|CP |EC |TC | Reserved |
’---------------------------------------------------------------’
Bit 0 is the CP (ComPressed) flag that indicates whether the message
(excluding the Message Envelope) is compressed. If the CP bit is set
(to 1), the message is compressed. Otherwise, the message is not
compressed. The Handle protocol uses the same compression method as
used by the FTP protocol[8].
Bit 1 is the EC (EnCrypted) flag that indicates whether the message
(excluding the Message Envelope) is encrypted. The EC bit should
only be set under an established session where a session key is in
place. If the EC bit is set (to 1), the message is encrypted using
the session key. Otherwise the message is not encrypted.
Bit 2 is the TC (TrunCated) flag that indicates whether this is a
truncated message. Message truncation happens most often when