| --------- --------- | | ----- ----- |
------------------------- ------------------
Handle Service Site 1 Handle Service Site 2
(US East Coast) (US West Coast)
Figure 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
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 | | |
| | ----------------------
---------------
Figure 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.
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 the 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
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. RFC 1034 [2] and RFC 1035 [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 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 the 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 of 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 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
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 as encrypted handle values, so that these values can only
be read within a controlled 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.
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 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 attacks. 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 of mitigating 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 and MDA-972-99-1-0018. 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. The current status and available
software, for 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.
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.
10. References and Bibliography
[1] Kahn, R. and R. Wilensky, "A Framework for Distributed Digital
Object Services", D-Lib Magazine, 1995.
[2] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models,