Handle System Overview
draft-sun-handle-system-12
This document is an Internet-Draft (I-D) that has been submitted to the Independent Submission stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 3650.
|
|
|---|---|---|---|
| Authors | Larry Lannom , Lt. Col. Brian P. Boesch , Sam Sun | ||
| Last updated | 2020-01-21 (Latest revision 2003-07-23) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | ISE state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 3650 (Informational) | |
| Action Holders |
(None)
|
||
| Telechat date | (None) | ||
| Responsible AD | Ted Hardie | ||
| IESG note | |||
| Send notices to | (None) |
draft-sun-handle-system-12
Internet Draft Sam X. Sun
Document: draft-sun-handle-system-12.txt CNRI
Expires: January 2003 Larry Lannom
CNRI
Brian Boesch
CNRI
July 2003
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-
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.
Abstract
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. The
Handle System is a general-purpose global name service that allows
secured name resolution and administration over networks such as
the Internet. The Handle System manages handles, which are unique
names for digital objects and other Internet resources.
Table of Contents
1. Introduction..................................................2
2. Motivations...................................................5
3. Handle Namespace..............................................6
4. Handle System Architecture....................................8
5. Handle System Security.......................................11
6. The Handle System and other Internet Services................12
Sun Expires - January 2004 [Page 1]
Internet-Draft Handle System Overview July 2003
6.1 Domain Name Service (DNS)...................................12
6.2 Directory Services (X.500/LDAP).............................13
6.3 Uniform Resource Identifier (URI)/Uniform Resource Name(URN) 13
7. Security Considerations......................................14
7.1 General Security Practice...................................15
7.2 Privacy Protection..........................................15
7.3 Caching and Proxy Servers...................................16
7.4 Mirroring...................................................16
7.5 Denial of Service (DoS).....................................17
8. History of the Handle System.................................17
9. Acknowledgements.............................................17
References and Bibliography.....................................18
Author's Addresses..............................................19
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. This allows 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 Handle System supports
secured handle resolution. Security services such as data
confidentiality, data integrity, and non-repudiation are provided
upon client request.
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.
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. Among these, 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, and administrative
Sun Expires - January 2004 [Page 2]
Internet-Draft Handle System Overview July 2003
organizations" [3]. The growth of the Internet has raised demands
for various extensions to DNS. There are also attempts to use DNS
as a general-purpose resource naming system. However, the
importance of DNS in basic network routing has led to great caution
in implementing any DNS extension or overloading the DNS for
general-purpose resource naming. An additional factor which argues
against using DNS as a general-purpose naming service is the DNS
administrative model. DNS names are typically managed by the
network administrator(s) at the DNS zone level. There is no
provision for per-name administrative structure and no facilities
for anyone other than the network administrator to create or manage
DNS names. This is appropriate for domain name administration but
less so for general-purpose resource naming.
The Handle System has been designed from the start to serve as a
general-purpose naming service. It is designed to accommodate very
large numbers of entities and to allow distributed administration
over the public Internet. The handle system data model allows
access control to be defined at the level of each of the one or
more data values associated with a given handle. Each handle can
further define its own set of administrators that are independent
from the network or host administrator.
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. However, the
URL practice also has some key limitations. Most URL schemes (e.g.,
http) are defined for resolution 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. For example, a
URL will be tied 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. It is especially difficult to
work around this problem when the reason for the location change is
change in ownership of an asset, as ownership is generally
reflected in the domain name.
The Handle System is designed to overcome these limitations and to
add significant functionality. Specifically, the Handle System is
designed with the following objectives:
. Uniqueness: Every handle is globally unique within the Handle
System.
Sun Expires - January 2004 [Page 3]
Internet-Draft Handle System Overview July 2003
. Persistence: Handles may be used as persistent identifiers for
Internet resources. A handle does not have to be derived in
any way from the entity that it names. 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 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 so as to distribute the service
load.
. Multiple Attributes: A single handle can refer to multiple
attributes of a resource, including associated services,
available through any method, again at different and possibly
changing network locations. Handles can thus be used as
persistent entry points into an evolving world of services
associated with identified resources.
. 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 [17], which includes most of the characters
currently used around the world. This allows handles to be
used 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
Sun Expires - January 2004 [Page 4]
Internet-Draft Handle System Overview July 2003
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. (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 the public Internet. The
handle system protocol defines standard mechanisms for both
client and server authentication, as well as service
authorization. It also provides security options to assure
data integrity and confidentiality.
. Distributed Administration Service: Each handle may define its
own administrator(s) or administrator group(s). Ownership of
each handle is defined in terms of its administrator or
administrator 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. Motivations
Since there are a number of name related projects in the Internet
community, it is worth defining exactly where we believe the Handle
System fits. Unfortunately, that is particularly hard because the
other primary naming schemes take either an abstract services
approach (e.g., URI/URN) or an approach to name resolution absent a
self-contained framework for reliable yet distributed
Sun Expires - January 2004 [Page 5]
Internet-Draft Handle System Overview July 2003
administration of the underlying databases (e.g., DNS). This makes
categorizing the Handle System difficult.
The Handle System crosses boundaries. Looked at as a name
resolution system, it might be compared to DNS. If used to
implement a URI/URN namespace, it could be used with any URI/URN
scheme. If used for distributed information update and
administration, it could be considered a simplified-version of a
distributed database system.
It is probably best to view the Handle System as a name-attribute
binding service with a specific protocol for securely creating,
updating, maintaining, and accessing a distributed database. It is
designed to be an enabling service for secured information and
resource sharing over the networks such as the public Internet.
Applications of the Handle System could include meta-data services
for digital publications, identity management services for virtual
identities, or any other applications that require resolution
and/or administration of globally unique identifiers.
In the spirit of exploration, the Handle System has been designed
to have high performance for name resolution and to push the
boundaries of distributed access control and administration.
Unlike most conventional systems (even distributed systems) that
are designed to have a relatively small number of broadly empowered
administrators, the Handle System allows extremely fine granularity
of administrative control. It has a unique self-contained
administrative framework that de-couples the ownership of each
handle from the system administrators and allows access control to
be defined for each handle value.
It should be noted, that as with all real systems, the Handle
System is a compromise between a number of technical and practical
concerns. There are also different opinions within IETF on where
the Handle System fits in relation to other existing Internet name
services. It is with the goal of exposing a broader community to
the concepts, approach, specific decisions, tradeoffs and results
that we are writing this RFC.
3. 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:
<Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>
The naming authority and local name are separated by the ASCII
character "/". The collection of local names under a naming
Sun Expires - January 2004 [Page 6]
Internet-Draft Handle System Overview July 2003
authority defines the local handle 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.
For example, "10.1045/january99-bearman" is a handle for an article
published in D-Lib magazine [12]. Its naming authority is "10.1045"
and its local name is "january99-bearman". The handle namespace can
be considered a superset of many local namespaces, with each local
namespace having a unique naming authority under the Handle System.
The naming authority identifies the administrative unit of
creation, although not necessarily continuing administration, of
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 so that any local name under the namespace
can be globally referenced as a combination of the naming authority
and the local name as shown above.
Naming authorities under the Handle System are defined in a
hierarchical fashion resembling 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.
Handles may consist of any printable characters from the Universal
Character Set (UCS-2) of ISO/IEC 10646, which is the exact
character set defined by Unicode v3.0 [17]. The UCS-2 character set
encompasses most characters used in every major language written
today. To allow compatibility with most of the existing systems and
to prevent ambiguity among different encodings, the handle system
protocol mandates UTF-8 to be the only encoding used for handles.
The UTF-8 encoding preserves any ASCII encoded names so as to allow
Sun Expires - January 2004 [Page 7]
Internet-Draft Handle System Overview July 2003
maximum compatibility with existing systems without causing naming
conflict. Some encoding issues over the global namespace and the
choice of UTF-8 encoding are discussed in [13].
By default, handles are case sensitive. However, any individual
handle service may define its namespace such that ASCII characters
within any handle under that namespace are case insensitive.
4. Handle System Architecture
The Handle System defines a hierarchical service model. The top
level consists of a single handle service, known as the Global
Handle Registry (GHR). The lower level consists of all other handle
services, generically known as Local Handle Services (LHS).
The Global Handle Registry can be used to manage any handle
namespace. It is unique among handle services only in that it
provides the service used to manage naming authorities, all of
which are managed as handles. The naming authority handle provides
information that clients can use to access and utilize the local
handle service for handles under the naming authority.
Local Handle Services are intended to be hosted by organizations
with administrative responsibility for handles under certain naming
authorities. A Local Handle Service may be responsible for any
number of local handle namespaces, each identified by a unique
naming authority. The Local Handle Service and its responsible set
of local handle namespaces must be registered with the Global
Handle Registry.
One important aspect of the Handle System is its distributed
architecture. The Handle System as a whole consists of a number of
individual handle services. Each of these services may consist of
one or more service sites. Each service site is a complete
replication of every other site in the service, in terms of handle
resolution. Each service site may consist of one or more handle
servers. All handles, and hence all handle requests, directed at a
given service site will be evenly distributed across these handle
servers. The Handle System as a whole may consist of any number of
handle services. There are no design limits on the number of handle
services or on the number of sites which make up each service.
Neither are there any limits on the number of servers that make up
each site. Replication among any service sites does not require
that each site contain the same number of servers. In other words,
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.
Sun Expires - January 2004 [Page 8]
Internet-Draft Handle System Overview July 2003
Figure 3.1 illustrates a potential handle service that consists of
two service sites: one located on the U.S. east coast and the other
on the U.S. west coast. The east coast service site consists of
four server computers. The west coast service site, with more
powerful computers deployed, decides two servers will suffice. The
number of service sites for any handle service, as well as the
number of servers that are used by any service site, may be added
or removed dynamically depending on the service requirement.
------------------------- ------------------
| --------- --------- | | ----- ----- |
| | | | | | | | 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. 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 handles under
these naming authorities. 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. Clients
can find the "home" service for each handle by querying the naming
authority handle at the Global Handle Registry.
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 given 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 associated with
the corresponding naming authority handle. The service information
Sun Expires - January 2004 [Page 9]
Internet-Draft Handle System Overview July 2003
provides the necessary information for clients to communicate with
the "home" service.
Figure 3.2 shows an example of a typical handle resolution process.
In this case, the "home" service is a Local Handle Service. The
client is trying to resolve the handle "10.1045/july95-arms" and
has to find its "home" service from the Global Handle Registry. The
"home" service can be found by sending a query to the Global Handle
Registry for the naming authority handle for "10.1045". The Global
Handle Registry returns the service information of the Local Handle
Service that is responsible for handles under the naming authority
"10.1045". The service information allows the client to communicate
with the Local Handle Service to resolve the handle
"10.1045/july95-arms".
------------------------
| | 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 "10.1045" V |
"10.1045" | | ----------------------
| | | |
V | | Local Handle Service |
--------------- | responsible for the |
| | | naming authority |
| Global Handle | | "10.1045" |
| 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 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 correct Local
Handle Service without contacting the Global Handle Registry.
Sun Expires - January 2004 [Page 10]
Internet-Draft Handle System Overview July 2003
5. Handle System Security
The Handle System provides handle resolution and administration
service over networks such as 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 clients to
manage handles. These include adding handles, deleting handles or
updating their values. It also manages naming authorities via
naming authority handles. Each handle can have its own
administrator(s) and each administrator can be granted a certain
set of permissions. The handle system authentication protocol
authenticates the handle administrator before fulfilling any
administrative request.
The Handle System provides security services such as client and
server authentication, data confidentiality and integrity, and non-
repudiation. By default, handle resolution does not require any
client authentication. However, resolution requests for
confidential data assigned to any handle (by its administrator), as
well as any administration requests (e.g., adding or deleting
handle values) require authentication of the client for proper
authorization. The server will decide, during the authorization
process, whether or not the client has permission to access those
confidential handle values, or has permission to add or update
handles and handle values. When authentication is required, the
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 identifying itself as a qualified administrator. 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. Handle System authentication can also be carried
out via third party authentication services. To ensure data
integrity, clients may request digitally signed responses from any
handle server. They may also set up secured communication sessions
with handle servers so that any exchanged information can be
encrypted (for data confidentiality) using a session key. Handle
servers can also provide confidentiality by encrypting the handle
data before sending it to the client.
The Handle System provides service options for secured information
exchange between client and server. This does not, of course,
guarantee the truthfulness of handle values. Incorrect values
assigned to any handle by its administrator may very well mislead
Sun Expires - January 2004 [Page 11]
Internet-Draft Handle System Overview July 2003
clients. On the other hand, a handle value may contain references
to other handle values to provide additional credentials. For
example, a handle value R (e.g., a claim) may contain a reference
to some other handle value that contains the digital signature
(from a creditable source) upon the value R. Clients who trust the
signature could then trust the handle value R.
6. 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.
6.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, 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/or affect its effectiveness in network
routing. DNS implementations typically do not scale well when a
large amount of data is associated with any particular DNS name. It
is therefore generally considered inappropriate to use DNS as a
general-purpose naming service.
An additional factor that argues against using DNS as a general-
purpose naming service is the DNS administrative model. DNS names
are typically managed by the network administrator(s) at the DNS
zone level. There is no provision for a per-name administrative
structure. No facilities are provided for anyone other than network
administrators to create or manage DNS names. This is appropriate
for domain name administration but less so for general-purpose name
administration.
The Handle System differs from DNS in its distributed
administration and service model, as well as its security features.
The handle system protocol includes security options to assure
confidentiality and integrity during data transmission. Each handle
can have its own administrator, independent from the server
administrator. The handle system protocol allows any handle
administrator to manage his or her handles securely over the public
network. Additionally, the Handle System service model allows any
of its service sites to dynamically configure its service
distribution among a cluster of servers to accommodate increased
Sun Expires - January 2004 [Page 12]
Internet-Draft Handle System Overview July 2003
service requests. This also allows less powerful computers to be
used together to support any arbitrarily large number of handles.
6.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 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" [14].
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.
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,
thus affects its efficiency. A pure name service, such as the
Handle System, can 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++ [15,16] may be used in
tandem with the Handle System to provide reverse lookup service.
Existing corporate directory services, for example, could provide
interfaces to both services. The handle system interface would
provide a highly efficient name resolution service. The directory
service interface would provide extended search capability. Handles
could also be used in LDAP service referral. For example, an LDAP
service may be referenced as a handle. Doing so will make the
reference persistent overtime, independent from location change.
6.3 Uniform Resource Identifier (URI)/Uniform Resource Name(URN)
Uniform Resource Identifier (URI) [23] defines a uniform yet
extensible naming mechanism for identifying Internet resources in
web applications. Uniform Resource Name (URN) [11], a subset of
URI, defines a namespace registration mechanism for persistent
namespaces under URI. URI/URN represents most of the Internet name
services used in web applications. This section discusses the
Sun Expires - January 2004 [Page 13]
Internet-Draft Handle System Overview July 2003
relationship of the Handle System to URI/URN and how applications
may utilize the Handle System within the URI/URN context.
The Handle System provides a general-purpose name service for the
Internet. Like DNS or X.500 directory service, the handle system
defines its namespace outside of any URI/URN namespace. Handles can
be transcribed and resolved directly, without any URI/URN scheme as
a prefix. For example, a library application may resolve the handle
"10.1045/july95-arms" directly into its set of handle values. No
URI/URN scheme will be needed in this case.
The Handle System may be used for applications that require a
persistent name service. The Handle System provides the necessary
mechanisms to allow persistent names to be registered as handles.
Specific naming authorities may be defined to host those handles
designed to be persistent. However, the persistence of handles
depends more on administrative policies than the technology itself.
Such policies are beyond the handle system service as described in
this set of documents.
On the other hand, the Handle System can also be used for
applications where persistent names are not required. Such handles
may have a short life-time and they may also be used to identify
different objects at different times.
Different web applications may be developed using the Handle System
as the underlying name service. Each of these applications may
define its own URI/URN namespace for its application needs. For
example, application FOO may have a URI namespace "foo:" registered
to identify any FOO services on the web. In the mean time,
application BAR may have a URN namespace "URN:BAR" registered to
identify any BAR object that needs a persistent name. Both FOO and
BAR applications may use handles (under their respective naming
authority) in naming and resolving to services and/or objects. This
is similar in DNS, where there are different URI schemes (e.g.,
"telnet", "ftp", "mailto", etc.) defined for different
applications, all using the DNS service.
The IETF and IRTF have discussed the Handle System in the realm of
URI-related work. There are different opinions on whether the
Handle System will fit into a specific URI or URN namespace. There
are also concerns on where the Handle System fits in relation to
other existing name services on the Internet. Such discussions are
out of the scope of this document.
7. 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
Sun Expires - January 2004 [Page 14]
Internet-Draft Handle System Overview July 2003
application developers, service providers, and handle system
clients. Specific security considerations regarding the handle
system protocol [21] as well as its data and service model [22] are
addressed in separate documents.
7.1 General Security Practice
The security of the Handle System 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 reliably convey 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 is to believe that the Global Handle Registry will
correctly direct the client request to the responsible Local Handle
Service. To trust a Local Handle Service is to believe that the
Local Handle Service will correctly return the data that was
assigned to the handle by its administrator. A Local Handle Service
typically supports a set of naming authorities. Thus, trusting a
Local Handle Service would imply trusting those naming authorities.
The integrity of the Handle System depends heavily on the integrity
of the global service information. Invalid global service
information may mislead clients into inappropriate Local Handle
Services. It may also allow attackers to forge server signatures.
The Global Handle Registry must take extreme caution in protecting
the global service information and the public key pair used to sign
the global service information. Client applications should only
accept the global service information from the Global Handle
Registry. They should check its integrity upon each update.
For efficiency reasons, handle servers will not generate or return
a digital signature for every service response unless specifically
requested by clients. To assure data integrity, clients must
explicitly ask the server to return the digital signature. To
protect sensitive data from exposure, clients may establish a
communication session with the server and ask the server to encrypt
any data using the session key.
7.2 Privacy Protection
By default, most handle data stored in the Handle System is
publicly accessible unless otherwise specified by the handle
administrator. Handle administrators must pay attention when adding
handle values that contain private information. They may choose to
mark these handle values readable only by the handle
administrator(s), or to store these handle values encrypted, so
that these values can only be readable within a controlled
audience.
Sun Expires - January 2004 [Page 15]
Internet-Draft Handle System Overview July 2003
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.
7.3 Caching and Proxy Servers
Besides performance gains and other value-added services, both
proxy and caching servers 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
any handle service. They are clients of the Handle System. Service
responses from proxy and caching servers cannot be authenticated
via the handle system protocol. The trust between the client and
its immediate proxy/caching server has to be setup independently,
regardless of the number of proxy/caching servers that are in the
middle of the communication path.
By using proxy and caching servers, clients assume that the servers
will submit their requests and relay any responses from the Handle
System, without mishandling any of the contents. They also assume
that the servers will protect any sensitive 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
information should be carefully guarded, and appropriate guidelines
for their use developed and followed.
Caching servers provide additional potential vulnerabilities
because the contents of the cache represent 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.
7.4 Mirroring
Handle System clients should be aware of possible delays in content
replication among mirroring sites. They should consider sending
their request to the primary service site for any time-sensitive
data. Selection of mirroring sites by service administrators must
be done carefully. Each mirroring site must follow the same
security procedures in order to ensure data integrity. Software
Sun Expires - January 2004 [Page 16]
Internet-Draft Handle System Overview July 2003
tools may be applied to ensure data consistency among mirroring
sites.
7.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 attacks in today's technology. Server implementations
may be developed to be aware of such attacks and notify
administrators when they happen. Stateless cookies [19, 20] are one
means to mitigate some of the effects of DoS attacks on hosts that
perform authentication, integrity, and encryption services. Server
implementations, moreover, need to be upgradeable to take advantage
of new security technologies including anti-DoS technologies as
these become available.
8. History of the Handle System
The Handle System was originally conceived and developed at CNRI as
part of an overall digital object architecture. The first public
implementation was created at CNRI in the fall of 1994 in an effort
led by David Ely. The overall digital object architecture,
including the Handle System, was later described in a paper by
Robert Kahn and Robert Wilensky [1] in 1995. Development continued
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 in the
evolution of the Networked Computer Science Technical Reference
Library (NCSTRL) [18] and related activities, was to develop a
framework for the underlying infrastructure of digital libraries.
Early adopters of the Handle System 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.
9. Acknowledgements
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.
Sun Expires - January 2004 [Page 17]
Internet-Draft Handle System Overview July 2003
The authors also thank Russ Housley (housley@vigilsec.com), Ted
Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com)
for their extensive review and comments, as well as recommendations
received from other members of the IETF/IRTF community.
References and Bibliography
[1] R. Kahn, & R. Wilensky, "A Framework for Distributed Digital
Object Services", D-Lib Magazine, 1995
[2] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC1034, November 1987
[3] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC1035, November 1987
[4] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform
Resource Locators (URL)", RFC1738, December 1994
[5] Yergeau, Francois, "UTF-8, A Transform Format for Unicode and
ISO10646", RFC2044, October 1996
[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
[8] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997
[9] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994
[10] Sollins, K. "Architectural Principles of Uniform Resource Name
Resolution", RFC 2276, January 1998
[11] IETF Uniform Resource Names (URN) Working Group, April, 1998,
http://www.ietf.org/html.charters/urn-charter.html
[12] D-Lib Magazine, http://www.dlib.org
[13] Sam X. Sun, "Internationalization of the Handle System - A
Persistent Global Name Service", Proceeding of 12th International
Unicode Conference, April, 1998
[14] D Goodman, C Robbins, "Understanding LDAP & X.500", August
1997
Sun Expires - January 2004 [Page 18]
Internet-Draft Handle System Overview July 2003
[15] Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
"Architecture of the Whois++ service", RFC 1835, August 1995
[16] Weider, C., J. Fullton, and S. Spero, "Architecture of the
Whois++ Index Service", RFC 1913, February 1996
[17] The Unicode Consortium, "The Unicode Standard, Version v3.0",
Addison-Wesley Pub Co; ISBN: 0201616335
[18] The Networked Computer Science Technical Reports Library
(NCSTRL), http://www.ncstrl.org/
[19] P. Karn, W. Simpson, "Photuris: Session-Key Management
Protocol", March, 1999
[20] D. Harkins, D Carrel, "The Internet Key Exchange (IKE)",
November, 1998
[21] 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-08.txt, work in progress
[22] 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-05.txt, work in progress
[23] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998
Author's 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
Brian Boesch
Corporation for National Research Initiatives (CNRI)
1895 Preston White Dr. Suite 100
Sun Expires - January 2004 [Page 19]
Internet-Draft Handle System Overview July 2003
Reston, VA 20191
Phone: 703-262-5316
Email: bboesch@cnri.reston.va.us
Sun Expires - January 2004 [Page 20]