WDIFF

draft-sun-handle-system-08.txt --> draft-sun-handle-system-09.txt

Network Working Group

Internet Draft Sam X. Sun
Internet Draft: Handle System Overview
Document: draft-sun-handle-system-09.txt CNRI
Expires: January 2003 Larry Lannom
draft-sun-handle-system-08.txt
CNRI
February
July 2002

Handle System Overview

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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 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.
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.

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 RFC 2119 [KEYWORDS].

Abstract

The Handle System is a general-purpose global name service that
allows secured name resolution and administration over the public
Internet. The Handle System manages handles, which are unique names
for digital objects and other Internet resources. This document
provides an overview of the Handle System in terms of its namespace
and service architecture, as well as its relationship to other
Internet services such as DNS, LDAP/X.500, and URN.

Table of Contents

1. Introduction..................................................2
2. Handle Namespace..............................................5
3. Handle System Architecture....................................6
4. Handle System Service and its Security.......................10
5. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", Handle System and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [11]. other Internet Services................11

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 1]

Internet-Draft Handle System Overview July 2002

5.1 Domain Name Service (DNS)...................................11
5.2 Directory Services (X.500/LDAP).............................12
5.3 Uniform Resource Names (URN)................................12
6. Security Considerations......................................13
6.1 General security practice...................................13
6.2 Privacy protection..........................................14
6.3 Caching and proxy...........................................14
6.4 Mirroring...................................................15
6.5 Denial of service (DoS).....................................15
7. History of the Handle System.................................15
8. Acknowledgement..............................................16
Author's Addresses..............................................16
References and Bibliography.....................................17

1. Introduction

This document provides an overview of the Handle System, a
distributed information system designed to provide an efficient,
extensible, and secured global name service for use on networks
such as the Internet. The Handle System includes an open protocol,
a namespace, and a reference implementation of the protocol. The
protocol enables a distributed computer system to store names, or
handles, of digital resources and resolve those handles into the
information necessary to locate, access, and otherwise make use of
the resources. These associated values can be changed as needed to
reflect the current state of the identified resource without
changing the handle, thus allowing the name of the item to persist
over changes of location and other current state information. Each
handle may have its own administrator(s) and administration can be
done in a distributed environment. The name-to-value bindings may
also be secured, allowing handles to be used in trust management
applications.

Sun & Lannom [Page 1]

Internet Draft Handle System Overview January 2002

The Handle System provides a confederated name service that allows
any existing local namespace to join the global handle namespace by
obtaining a unique handle system naming authority. Local names and
their value-binding(s) remain intact after joining the Handle
System. Any handle request to the local namespace may be processed
by a service interface speaking the handle system protocol which
would map the handle request into the local name. Combined with the
unique naming authority, any local name is guaranteed unique under
the global handle namespace. There are several services that are
in use today to provide name service for Internet resources, of
which the Domain Name System (DNS) [2,3] is the most widely used.
DNS is designed "to provide a mechanism for naming resources in
such a way that the names are mappable into IP addresses and are
usable in different hosts, networks, protocol families, internets,

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 2]

Internet-Draft Handle System Overview July 2002

and administrative organizations" [3]. The growth of the Internet
has increased demands for various extensions to DNS, and even its
use as a general purpose resource naming system, but its importance
in basic network routing has led to great caution in implementing
such extensions and a general conclusion that DNS is not the place
to look for general purpose resource naming. An additional factor
which argues against using DNS as a general purpose naming system
is the DNS administrative model. DNS names are typically managed by
the network administrator(s) at the DNS zone level, with no
provision for a per name administrative structure, and no
facilities for anyone other than network administrators to create
or manage names. This is appropriate for domain name administration
but less so for general purpose resource name administration. The
Handle System has been designed from the start to serve as a naming
system for very large numbers of entities and to allow
administration at the name level. The handle system data model
allows access control to be defined at the level of each handle
data. Each handle can further define its own administrator(s) to
manage the handle data via the handle system authentication
protocol.

Traditional URLs (Uniform Resource Locators) [4] allow certain
Internet resources to be named as a combination of a DNS name and
local name. The local name may be a local file path, or a reference
to some local service, e.g. a cgi-bin script. This combination of
DNS name and local name provides a flexible administrative model
for naming and managing individual Internet resources. There are,
however, several key limitations. Most URL schemes (e.g., http) are
defined for resolution service only. Any URL administration has to
be done either at the local host, or via some other network service
such as NFS. Using a URL as a name typically ties the Internet
resource to its current network location, and to its local file
path when the file path is part of the URL. When the resource moves
from one location to another, for whatever reason, the URL breaks.

Sun & Lannom [Page 2]

Internet Draft Handle System Overview January 2002
The Handle System is designed to overcome these limitations (i.e.
per DNS name administration rather than per digital item,
resolution-only name service which must be done at local host or
distributed file system, location dependence) and to add
significant increased functionality. Specifically, the Handle
System is designed with the following objectives:

Uniqueness: Every handle is globally unique within the Handle
System.

Persistence: A handle is not derived in any way from the entity
which it names, but is assigned to it independently. While an
existing name, or even a mnemonic, may be included in a handle for
convenience, the only operational connection between a handle and
the entity it names is maintained within the Handle System. This of

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 3]

Internet-Draft Handle System Overview July 2002

course does not guarantee persistence, which is a function of
administrative care, but it does allow the same name to persist
over changes of location, ownership, and other state conditions.
For example, when a named resource moves from one location to
another, the handle may be kept valid by updating its value in the
Handle System to reflect the new location.

Multiple Instances: A single handle can refer to multiple instances
of a resource, at different and possibly changing locations in a
network. Applications can take advantage of this to increase
performance and reliability. For example, a network service may
define multiple entry points for its service with a single handle
and so distribute the service load.

Extensible Namespace: Existing local namespaces may join the handle
namespace by acquiring a unique handle naming authority. This
allows local namespaces to be introduced into a global context
while avoiding conflict with existing namespaces. Use of naming
authorities also allows delegation of service, both resolution and
administration, to a local handle service.

International Support: The handle namespace is based on Unicode 3.0
[1], which includes most of the characters currently used around
the world, facilitating the use of the system in any native
environment. The handle protocol mandates UTF-8 [5] as the encoding
used for handles.

Distributed Service Model: The Handle System defines a hierarchical
service model such that any local handle namespace may be serviced
either by a corresponding local handle service or by the global
service or by both. The global service, known as the Global Handle
Registry, can be used to dispatch any handle service request to the
responsible local handle service. The distributed service model
allows replication of any given service into multiple service sites
and each service site may further distribute its service into a
cluster of individual servers.

Sun & Lannom [Page 3]

Internet Draft Handle System Overview January 2002 (Note that local here refers only to
namespace and administrative concerns. A local handle service could
in fact have many service sites distributed across the Internet.)

Secured Name Service: The handle system allows secured name
resolution and administration over public Internet. The handle
system protocol defines standard mechanisms for both client and
server authentication, as well as service authorization. It also
provides options to allow guaranteed service integrity and data
confidentiality.

Distributed Administration Service: Each handle may define its own
administrator(s) or administrative group(s). Ownership of each
handle is defined in terms of its administrator or administrator

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 4]

Internet-Draft Handle System Overview July 2002

groups. This, combined with the handle system authentication
protocol, allows any handle to be managed securely over the public
network by its administrator at any network location.

Efficient Resolution Service: The handle protocol is designed to
allow highly efficient name resolution performance. To avoid
resolution being affected by computationally costly administration
service, separate service interfaces (i.e., server processes and
their associated communication ports) for handle name resolution
and administration may be defined by any handle service.

This document provides an overview of the handle namespace and
service architecture. It also compares the Handle System with other
existing Internet services, protocols, and specifications (e.g.,
DNS [2, 3], URLs [4], X.500/LDAP [6,7,8], and URN [9,10]). Details
of the handle system data and service model, as well as its
communication protocol, are specified in separate documents. They
can be found under the handle system website at
http://www.handle.net.

2. Handle Namespace

Every handle consists of two parts: its naming authority, otherwise
known as its prefix, and a unique local name under the naming
authority, otherwise known as its suffix. The naming authority and
local name are separated by the ASCII character "/". A handle may
thus be defined as:

For example, "10.1045/january99-bearman" is a handle for an article
published in D-Lib magazine [13]. It is defined under the Handle
Naming Authority "10.1045", and its Handle Local Name is
"january99-bearman". The handle namespace can be considered as
superset of many local namespaces, with each local namespace having
its own unique handle naming authority. The naming authority
identifies the administrative unit of creation, although not
necessarily continuing administration, of

Sun & Lannom [Page 4]

Internet Draft Handle System Overview January 2002 the associated handles.
Each naming authority is guaranteed to be globally unique within
the Handle System. Any existing local namespace can join the global
handle namespace by obtaining a unique naming authority, with the
resulting handles being a combination of naming authority and local
name as shown above.

Handles may consist of any printable characters from the Universal
Character Set, two-octet form (UCS-2) of ISO/IEC 10646, which is
the exact character set defined by Unicode v2.0. The UCS-2
character set encompasses most characters used in every major

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 5]

Internet-Draft Handle System Overview July 2002

language written today. To allow compatibility with most of the
existing systems and prevent ambiguity among different encoding,
handle protocol mandates UTF-8 to be the only encoding used for
handles. The UTF-8 encoding preserves any ASCII encoded names,
which allows maximum compatibility to existing systems without
causing naming conflict. Some encoding issues over the global
namespace and the choice of UTF-8 encoding are discussed in [14].

By default, handles are case sensitive. However, any handle
service, including the global service, may define its namespace
such that all ASCII characters within any handle are case
insensitive.

Handle naming authorities are defined in a hierarchical fashion,
i.e., a tree structure. Each node and leaf of the tree is given a
label that corresponds to a naming authority segment. The parent
node presents the parent naming authority of its child nodes.
Unlike DNS, handle naming authorities are constructed left to
right, concatenating the labels from the root of the tree to the
node that represents the naming authority. Each label is separated
by the octet used for ASCII character "." (0x2E). For example, a
naming authority for the National Digital Library Program ("ndlp")
at the Library of Congress ("loc") is defined as "loc.ndlp".

Each naming authority may have many child naming authorities
registered underneath. Any child naming authority can only be
registered by its parent after its parent naming authority is
registered. However, there is no intrinsic administrative
relationship between the namespaces represented by the parent and
child naming authorities. The parent namespace and its child
namespaces may be served by different handle services, and they may
or may not share any administration privileges among each other.

Every handle is defined under a naming authority. The naming
authority and the local name are separated by the octet used for
ASCII character "/" (0x2F). The collection of local names under a
naming authority is the local namespace for that naming authority.
Any local name must be unique under its local namespace. The
uniqueness of a naming authority and a local name under that
authority ensures that any handle is globally unique within the
context of the Handle System.

Sun & Lannom [Page 5]

Internet Draft Handle System Overview January 2002

3. Handle System Architecture

The Handle System defines a hierarchical service model. The top
level consists of a single global service, known as the Global
Handle Registry. The lower level consists of all other handle
services, which are generically known as local handle services. The

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 6]

Internet-Draft Handle System Overview July 2002

Global Handle Registry provides a handle service (for resolution)
and can be used to manage any handle namespace. It is unique among
handle services only in that it provides the service used to manage
the namespace of handle naming authorities, all of which are
managed as handles. The state information of these naming authority
handles is the service information that clients can use to access
and utilize associated local services.

The local handle service layer consists of all local handle
services managing all handles under their naming authorities,
providing resolution and administration service for these local
names. Local services are intended to be hosted by organizations
with administrative responsibility for the handles within the
service or acting on behalf of the responsible organizations.

A second important aspect of Handle System architecture is its
distributed nature. The Handle System as a whole consists of a
number of individual handle services, each of which consists of one
or more handle service sites, where each site replicates the
complete individual handle service, at least for the purposes of
handle resolution. Each handle service site in turn consists of one
or more handle servers. There are no design limits on the total
number of handle services which constitute the Handle System, there
are no design limits on the number of sites which make up each
service, and there are no limits on the number of servers which
make up each site. Replication by site, within a service, does not
require that each site contain the same number of servers; that is,
while each site will have the same replicated set of handles, each
site may allocate that set of handles across a different number of
servers. This distributed approach is intended to aid scalability
to accommodate any large-scale of operation and to mitigate
problems of single point failure.

Figure 3.1 illustrates a potential handle service that consists of
two service sites, one located at the US East coast and the other
at the US West coast. The East coast service site consists of four
host computers that process all the client requests, and the West
coast service site, with more powerful computers deployed, decides
two host servers will suffice. The number of service sites for any
Handle System, as well as the number of servers that are used by
any service site, may be added or removed dynamically according to
the service requirement.

Sun & Lannom Expires - January !Undefined Bookmark, SAVEDATE [Page 6]

Internet Draft 7]

Internet-Draft Handle System Overview January July 2002

------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | S | | S | |
| | server1 | | server2 | | | | E | | E | |
| | | | | | | | R | | R | |
| --------- --------- | | | V | | V | |
| --------- --------- | | | E | | E | |
| | | | | | | | R | | R | |
| | Server3 | | Server4 | | | | | | | |
| | | | | | | | 1 | | 2 | |
| --------- --------- | | ----- ----- |
------------------------- ------------------

Handle Service Site 1 Handle Service Site 2
(US East Coast) (US West Coast)

Fig. 3.1 Handle service configured with two service sites.

Each handle service manages a distinct sub-namespace under the
Handle System. Namespaces under different handle services may not
overlap, however, a handle service itself may consist of many
replicated service sites. The sub-namespace typically consists of
handles under a number of naming authorities. The handle service is
called the "home" service of these naming authorities and is the
only one that provides resolution and administration service for
its handles. Before resolving a handle, a client has to determine
the "home" service of the handle in question. The "home" service of
each handle is the "home" service of its naming authority and is
registered at the Global Handle Registry. This determination is
carried out by the client software.

The Global Handle Registry maintains naming authority handles. Each
naming authority handle maintains the service information that
describes the "home" service of the naming authority. The service
information lists the service sites of the handle service, as well
as the interface to each handle server within each site. To find
the "home" service for any handle, a client can query the Global
Handle Registry for the service information that is maintained by
the corresponding naming authority handle. The service information
provides the necessary information for clients to communicate with
the "home" service for any request.

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 8]

Internet-Draft Handle System Overview July 2002

Figure 3.2 shows an example of a typical handle resolution process
where the "home" service is a local handle service. In this case,
the client is trying to resolve the handle "cnri.dlib/july95-arms"
and has to find its "home" service from the global handle registry.
The "home" service is determined by sending a query to the Global
Handle Registry for the corresponding naming authority handle. The
Global Handle Registry

Sun & Lannom [Page 7]

Internet Draft Handle System Overview January 2002 returns the service information that
describes the local handle service that is responsible for handles
under the naming authority "cnri.dlib", including the handle
"cnri.dlib/july95-arms". The service information allows the client
to identify the local handle service in order to resolve the
handle.

------------------------
| | 4. Result of client request
| Client with global | <-------------------------------.
| service information | |
| | ----------------------------. |
------------------------ 3. Request to responsible | |
| ^ local handle service | |
1. Client | | | |
query for | | | |
naming | | 2. Service information | |
authority | | for "cnri.dlib" V |
"cnri.dlib" | | -------------------
| | | |
V | | Local service |
--------------- | responsible for |
| | | naming authority |
| Global Handle | | "cnri.dlib" |
| Registry | | |
| | -------------------
---------------

Fig. 3.2 Handle resolution starting with global

To improve resolution performance, any client may choose to cache
the service information returned from the Global Handle Registry
and use it for subsequent queries. A separate handle caching
server, either stand-
alone stand-alone or as a piece of a general caching
mechanism, may also be used to provide shared caching within a
local community. Given a cached resolution result, subsequent
queries of the same handle may be answered locally without
contacting any handle service. Given cached service information,
clients can send their requests directly to the responsible handle
service without contacting the Global Handle Registry.

Sun & Lannom Expires - January !Undefined Bookmark, SAVEDATE [Page 8]

Internet Draft 9]

Internet-Draft Handle System Overview January July 2002

4. Handle System Service and its Security

The Handle System provides handle resolution service, as well as
handle administration service over the public Internet. Each handle
can be assigned a set of values. Clients use the handle resolution
service to resolve any handle into its set of values. Each value
has a data type and a unique value index. Clients can query for
specific handle values based on data type or value index.

The handle administration service answers requests from
administrative client to manage handles, including adding handles,
deleting handles or updating their values. It also manages naming
authorities via naming authority handles. Each handle can define
its own administrator(s) and each administrator is granted a
certain set of permissions. The handle system authentication
protocol authenticates the handle administrator before fulfilling
any administrative request.

The Handle System provides authentication and data integrity
services, depending on client request. By default, handle
resolution service does not require any client authentication.
However, resolution requests for confidential data assigned to any
handle (by its administrator), as well as all administration
requests (e.g. adding or deleting handle values) require
authentication of the client as having the requisite authority.
When authentication is required, the responsible handle server will
issue a challenge to the requesting client before carrying out the
client's request. To satisfy the authentication requirement, the
client must send back the correct response that identifies itself
as the administrator or otherwise in possession of the appropriate
credentials. The handle server will respond to the initial request
only after successful authentication of the client. Handle clients
may choose to use either secret key or public key cryptography for
authentication. Authentication under Handle System can also be
carried out via third party authentication services. Handle clients
may also request digitally signed responses from any handle server,
to ensure data integrity. Handle system clients can also set up a
secure communication session with a handle server so that
information transferred within the session can be encrypted with a
session key for data confidentiality.

The Handle System provides service options for the secure
transmission of information between client and server. This does
not imply any credentials of the handle values. Incorrect values
assigned to handles by any of the administrators may very well
mislead clients. On the other hand, any handle value record may
contain references to other handle value records to provide

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 10]

Internet-Draft Handle System Overview July 2002

additional credentials. For example, a value record R (e.g., a
claim) of any handle may contain a reference to some other value
record (from another handle) that contains a digital signature for
the value record R. Clients who trust the signature could then
trust the value record R.

Sun & Lannom [Page 9]

Internet Draft Handle System Overview January 2002

5. The Handle System and other Internet Services

There are a number of existing and proposed Internet identifier
services or specifications that by design or intent cover some of
the functionalities proposed for the Handle System. This section
briefly reviews them in relationship to the Handle System.

5.1 Domain Name Service (DNS)

The Domain Name Service, or DNS, was originally designed and is
heavily used for mapping domain names into IP Addresses for network
routing purposes. RFC1034 [2] and RFC1035 [3] provide detailed
descriptions of its design and implementation. The growth of the
Internet has increased demands for various extensions to DNS, and
even its possible use as a general purpose resource naming system.
However, any such use has the potential to slow down the network
address translation, and alter its effectiveness in network
routing. DNS implementation typically does not scale well when
large amount of data is associated with any particular DNS name,
and is generally considered not adequate to support a very large
number of DNS names used for naming any kind of resources over the
Internet.

An additional factor that argues against using DNS as a general
purpose naming system is the DNS administrative model. DNS names
are typically managed by the network administrator(s) at the DNS
zone level, with no provision for a per name administrative
structure, and no facilities for anyone other than network
administrators to create or manage names. This is appropriate for
domain name administration but less so for general purpose resource
name administration.

The Handle System differs from DNS in its distributed
administration and service model, as well as its secured service
protocol (see section 4). Each handle within the Handle System may
define its own administrator, and the Handle System defines a
distributed administration and access control model that allows an
individual handle and its contents to be managed securely over the
public network. The Handle System service model allows any of its
service sites to dynamically configure its service distribution

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 11]

Internet-Draft Handle System Overview July 2002

among a cluster of servers to accommodate increased service
requests. This also allows less powerful computers to be used
together to support any huge number of handles.

5.2 Directory Services (X.500/LDAP)

X.500 [6] is the OSI Directory Standard defined by ISO and the ITU.
It is designed "to provide a white pages service that would return
either the telephone numbers or X.400 O/R addresses of people", and
is "concerned mainly with providing the name server service for
Open Systems Interconnection (OSI) applications" [7]. X.500 defines
a

Sun & Lannom [Page 10]

Internet Draft Handle System Overview January 2002 hierarchical data and information model with a set of protocols
to allow global name lookup and search. The protocol, however, has
proved difficult to implement and there has been difficulty in
getting "client access integrated into existing products" [15].
LDAP (Lightweight Directory Access Protocol) [8] has overcome many
of these difficulties by making the protocol simpler, and easier to
implement. Some concern remains, however, that as LDAP is emerging
from a local directory access protocol (LDAP v2) into a distributed
service protocol (LDAP v3), it faces many issues not addressed in
its original design, resulting in new complications [15].

The fundamental difference between a name resolution service such
as the Handle System and a directory service such as LDAP is search
capability. The added functionality of being able to search a
directory service necessarily carries with it added complexity. A
pure name service, such as the Handle System can, in comparison, be
designed solely around efficient resolution of known items without
addressing functions and data structures required for discovery of
unknown items based on incomplete criteria.

Directory services such as LDAP or WHOIS++ [16,17] may be used in
tandem with the Handle System to provide reverse name lookup
service. Existing corporate directory services, for example, could
provide a single interface to both services. The handle interface
would provide a highly efficient name resolution service, while the
directory service interface would provide an extended search
capability. Handles could also be used, for example, in LDAP
service referral such that LDAP services could be referenced
independent of network location.

5.3 Uniform Resource Names (URN)

The IETF URN Working Group [12] has defined a syntax, possible
resolution mechanisms, and namespace registration procedure for a
resource identifier intended to cover a large array of existing and
potential namespaces. Namespaces are to be registered and assigned
unique Namespace Ids (NIDs). Any resolution services associated

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 12]

Internet-Draft Handle System Overview July 2002

with these namespaces require further registration with a
Resolution Discovery System (RDS) which clients could use to begin,
or discover, the appropriate resolution mechanisms.

The objectives and some of the approaches of the URN and Handle
System efforts have enough in common that some observers might
think that they are in contention. This is not the case. The URN
effort is explicitly designed to accommodate multiple identifier
namespaces and resolution systems. The Handle System is one such
case, with a very specific data and service model, and a protocol
that supports name resolution and administration. URNs and the
Handle System may interact in variety of ways, the most obvious of
which is that handles could be registered as a

Sun & Lannom [Page 11]

Internet Draft Handle System Overview January 2002 URN namespace, which
is to say, they could be used as a type of URN. It would also be
possible to use the Handle System as a type of RDS for other URN
namespaces. The success of either system however, is not dependent
upon the success of the other.

6. Security Considerations

This section is meant to inform people of security limitations of
the Handle System, as well as precautions that should be taken by
application developers, service providers, and handle system
clients. Specific security considerations regarding the handle
system protocol [22] or its data and service model [23] are
addressed in separate documents.

6.1 General security practice

Handle system security depends on both client and server host
security at every step in the transaction. It assumes the client
host has not been tampered with and that client software will
convey reliably the received data to the client. The client of any
handle service must also assume that any handle servers involved
have not been compromised. To trust the Global Handle Registry
means to trust that it will rightfully direct the client request to
the responsible Local Handle Service. To trust a Local Handle
Service means to trust that it will correctly respond with the data
that was entered by the administrator. A Local Handle Service
typically supports a set of naming authorities. Thus, trusting a
Local Handle Service may imply trusting those naming authorities.

The handle system service integrity depends heavily on the
integrity of the global service information. Invalid global service
information may mislead clients into inappropriate local handle
services, and/or allow attackers to forge server signatures. The
global handle service must take extreme caution in protecting the

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 13]

Internet-Draft Handle System Overview July 2002

global service information, as well as the public key pair used to
sign the global service information. Client applications should
only accept the global service information from the global handle
service, and check its integrity upon every update.

For efficiency reasons, by default, handle servers will not return a
digital signature along with every service response, unless
specifically
asked requrested by the client. To support service integrity over sensitive data, client applications need to provide the option so that clients may ask
the handle server to sign its response using a digital signature.

Sun & Lannom [Page 12]

Internet Draft Handle System Overview January 2002 application.

6.2 Privacy protection

By default, most handle data stored in the Handle System is
publicly accessible, unless otherwise specified by the handle owner (i.e. the
handle administrator). The handle owner
administrator. Handle administrators must pay attention when adding
handle values that may contain private information. Handle owners They may choose
to mark these handle values read-only readable only by the handle
administrator(s), or
choose to store the handle values encrypted, so that
they will can only be readable within a controlled set of audience.

Log files generated by the handle server are another vulnerable
point where client privacy may be under attack. Operators of handle
servers must protect such information carefully.

6.3 Caching and proxy

Besides performance gains and other value-added services, both the
proxy and caching server present themselves as men-in-the-middle,
and as such are vulnerable to man-in-the-middle attacks. It is
important to know that proxy and caching servers are not part of
the handle system service. They are clients of the Handle System.
Service responses from proxy and/or caching servers cannot be
authenticated via handle system protocol. The trust between the
client and its proxy/caching server has to be setup directly.

By using the proxy or caching server, clients assume that the
server will submit their request and relay any response from the
Handle System, without mishandling any of the contents. They also
assume that the caching/proxy server will protect any security and
privacy related information on their behalf.

Proxy and caching server operators should protect the systems on
which such servers are running as they would protect any system
that contains or transports sensitive information. In particular,
log information gathered at proxies often contain highly sensitive
personal information, and/or information about organizations. Such

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 14]

Internet-Draft Handle System Overview July 2002

information should be carefully guarded, and appropriate guidelines
for their use developed and followed.

Caching servers provide additional potential vulnerabilities, since
the contents of the cache represents an attractive target for
malicious exploitation. Potential attacks on the cache can reveal
private data for a handle user, or information still kept after a
user believes that they have been removed from the network.
Therefore, cache contents should be protected as sensitive
information.

Sun & Lannom [Page 13]

Internet Draft Handle System Overview January 2002

6.4 Mirroring

Handle system clients should be aware of possible delays in content
replication among mirroring sites, and may consider sending their
request to the primary service site for time-sensitive data.
Selection of mirroring sites by service administrator must be done
carefully. Each mirroring site must follow the same security
procedures in order to ensure the service integrity. Software tools
may be applied to ensure data consistency among mirroring sites.

6.5 Denial of service (DoS)

As with any public service, the Handle System is subject to denial
of service attack. No general solutions are available to protect
against such attack in today's technology. Server implementations
may be developed to be aware of such attack and notify its
administrator when it happens. The Handle System security protocols
need to ensure that the Handle System server is not easy prey to
DoS by performing expensive cryptographic operations for messages
that are in no way validated as to their source or integrity.
Stateless cookies [20, 21] are one means to mitigate some of the
effects of DoS attacks on hosts that perform authentication,
integrity, and encryption services. Handle System security
services, moreover, need to be upgradeable to take advantage of new
security technologies including anti-DoS technologies as these
become available.

7. History of the Handle System

The Handle System was originally conceived and developed at CNRI as
part of the Computer Science Technical Reports (CSTR) project,
funded by the Defense Advanced Projects Agency (DARPA) under Grant
Number MDA-972-92-J-1029. One aspect of this early digital library
project, which was also a major factor the evolution of the
Networked Computer Science Technical Reference Library (NCSTRL)

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 15]

Internet-Draft Handle System Overview July 2002

[19] and related activities, was to develop a framework for the
underlying infrastructure of digital libraries. It is described in
a paper by Robert Kahn and Robert Wilensky [18]. The first
implementation was created at CNRI in the fall of 1994 in an effort
led by David Ely.

Early adopters of the Handle System have included the Library of
Congress, the Defense Technical Information Center (DTIC), and the
International DOI Foundation (IDF). Feedback from these
organizations as well as NCSTRL, other digital library projects,
and related IETF efforts as mentioned above have all contributed to
the evolution of the Handle System. Current status and available
software, both client and server, can be found at
http://www.handle.net.

Sun & Lannom [Page 14]

Internet Draft Handle System Overview January 2002

8. Acknowledgements Acknowledgement

This work is derived from the earlier versions of the handle system
implementation. Design ideas are based on those discussed within
the handle system development team, including David Ely, Charles
Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie
Nguyen, Jason Petrone, and Helen She. Their contributions to this
work are gratefully acknowledged.

The authors also thanks and acknowledges Mark Baugher
(mbaugher@cisco.com) for his extensive review and comments of these
drafts, as well as recommendations received from other members of
the IRTF IDRM research group (http://www.idrm.org).

Author's Address Addresses

Sam X. Sun
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr. Suite 100
Reston, VA 20191
Phone: 703-262-5316
Email: ssun@cnri.reston.va.us

Larry Lannom
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr. Suite 100
Reston, VA 20191
Phone: 703-620-8990
Email: llannom@cnri.reston.va.us

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 16]

Internet-Draft Handle System Overview July 2002

References and Bibliography

[1] The Unicode Consortium, "The Unicode Standard, Version v3.0",
Addison-Wesley Pub Co; ISBN: 0201616335
[2] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC1034, November 1987, http://www.ietf.org/rfc/rfc1034.txt
[3] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC1035, November 1987,
http://www.ietf.org/rfc/rfc1035.txt
[4] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform
Resource Locators (URL)", RFC1738, December 1994,
http://www.ietf.org/rfc/rfc1738.txt
[5] Yergeau, Francois, "UTF-8, A Transform Format for Unicode and
ISO10646", RFC2044, October 1996,
http://www.ietf.org/rfc/rfc2044.txt
[6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models,
and Services", 1993.
[7] D W Chadwick, "Understanding X.500 - The Directory", Chapman &
Hall ISBN: 0-412-43020-7.

Sun & Lannom [Page 15]

Internet Draft Handle System Overview January 2002
[8] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997,
http://www.ietf.org/rfc/rfc2251.txt
[9] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994,
http://www.ietf.org/rfc/rfc1737.txt
[10] Sollins, K. "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998,
http://www.ietf.org/rfc/rfc2276.txt
[11] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March, 1997, http://www.ietf.org/rfc/rfc2119.txt
[12] IETF Uniform Resource Names (URN) Working Group, April, 1998,
http://www.ietf.org/html.charters/urn-charter.html
[13] D-Lib Magazine, http://www.dlib.org
[14] Sam X. Sun, "Internationalization of the Handle System - A
Persistent Global Name Service", Proceeding of 12th International
Unicode Conference, April, 1998,
http://www.cnri.reston.va.us/unicode-paper.ps
[15] D Goodman, C Robbins, "Understanding LDAP & X.500", August 1997,
1997
[16] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
"Architecture of the Whois++ service", RFC 1835, August 1995,
http://www.ietf.org/rfc/rfc1835.txt
[17] Weider, C., J. Fullton, and S. Spero, "Architecture of the
Whois++ Index Service", RFC 1913, February 1996,
http://www.ietf.org/rfc/rfc1913.txt
[18] Kahn, Robert and Wilensky, Robert. "A Framework for
Distributed Digital Object Services", May, 1995,
http://www.cnri.reston.va.us/tmp_hp/k-w.html

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 17]

Internet-Draft Handle System Overview July 2002

[19] The Networked Computer Science Technical Reports Library
(NCSTRL), http://www.ncstrl.org/
[20] P. Karn, W. Simpson, "Photuris: Session-Key Management
Protocol", March, 1999, ftp://ftp.isi.edu/in-notes/rfc2522.txt
[21] D. Harkins, D Carrel, "The Internet Key Exchange (IKE)",
November, 1998, ftp://ftp.isi.edu/in-notes/rfc2409.txt
[22] S. Sun, S. Reilly, L. Lannom, "Handle System Namespace and
Service Definition", IETF draft, http://www.ietf.org/internet-
drafts/draft-sun-handle-system-def-05.txt, work in progress.
[23] S. Sun, S. Reilly, L. Lannom, J. Petrone, "Handle System
Protocol Specification", IETF draft, http://www.ietf.org/internet-
drafts/draft-sun-handle-system-protocol-02.txt, work in progress.

Sun Expires - January !Undefined Bookmark, SAVEDATE [Page 18]

----