Internet Draft Sam X. Sun Document: draft-sun-handle-system-11.txt CNRI Expires: November 2003 Larry Lannom CNRI June 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 the public 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....................................7 5. Handle System Service and its Security.......................10 6. The Handle System and other Internet Services................11 6.1 Domain Name Service (DNS)...................................12 6.2 Directory Services (X.500/LDAP).............................12 Sun Expires - December 2003 [Page 1]
Internet-Draft Handle System Overview June 2003 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...........................................16 7.4 Mirroring...................................................16 7.5 Denial of Service (DoS).....................................16 8. History of the Handle System.................................17 9. Acknowledgement..............................................17 References and Bibliography.....................................17 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 service such as data confidentiality, data integrity, and non-repudiation are provided upon client's 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 organizations" [3]. The growth of the Internet has raised demands for various extensions to DNS. There are also attempts to use DNS Sun Expires - December 2003 [Page 2]
Internet-Draft Handle System Overview June 2003 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 handle data. 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. 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. . 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 Sun Expires - December 2003 [Page 3]
Internet-Draft Handle System Overview June 2003 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. . 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 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. Sun Expires - December 2003 [Page 4]
Internet-Draft Handle System Overview June 2003 . 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 would be well worth defining exactly where we believe the Handle System fits. Unfortunately, that is particularly hard because the other main approaches to naming take either an approach of naming as an abstract services (e.g. URI/URN) or name resolution absent self-contained framework for reliable yet distributed administration of the underlying databases (e.g. DNS). This makes categorizing the Handle System difficult. The Handle System crosses boundaries, thus if you look at it as a name resolution system one might compare it to DNS. If one were to use it to implement a URI/URN namespace one might consider it to used under any URI/URN scheme; and if one were to view it for distributed information update and administration one might consider it a simplified-version of distributed file system. It is probably best to view the handle system as a 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 public Internet. Applications of the Handle System may include Sun Expires - December 2003 [Page 5]
Internet-Draft Handle System Overview June 2003 meta-data service for digital publications, identity management service for virtual identities, and any applications that require resolution and/or administration of global 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 administration framework that de-couples the ownership of each handle from the system administrators and allows access control be defined upon 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 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 as 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 Sun Expires - December 2003 [Page 6]
Internet-Draft Handle System Overview June 2003 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 between each other. 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 v2.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 prevent ambiguity among different encoding, 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 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 [13]. By default, handles are case sensitive. However, a handle service may define its namespace so that ASCII characters within any handle under the namespace are case insensitive. 4. 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 (GHR). The lower level consists of all other handle services, generically known as Local Handle Services (LHS). Sun Expires - December 2003 [Page 7]
Internet-Draft Handle System Overview June 2003 The Global Handle Registry can be used to manage any handle namespace. It is unique from any other 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 authority. A Local Handle Service may be responsible for any number of local handle namespaces, each of which identified by a unique naming authority. The Local Handle Service and its responsible set of local handle namespaces must be registered under 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 service may consist of one or more service sites. Each of these service site is a complete replication of each other, at least for handle resolution. Additionally, a service site may also consist of one or more handle servers. Handle requests directed at the service site may be evenly distributed into these handle servers. The Handle System may consist of any number of handle services. There are no design limits on the number of sites which make up each service. Neither there are any limits on the number of servers that make up each site. Replication among any service sites does not require that each site contains 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. 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 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. Sun Expires - December 2003 [Page 8]
Internet-Draft Handle System Overview June 2003 ------------------------- ------------------ | --------- --------- | | ----- ----- | | | | | | | | | 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 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 to 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 "cnri.dlib/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 "cnri.lib". The Global Handle Registry returns the service information of the Local Handle Sun Expires - December 2003 [Page 9]
Internet-Draft Handle System Overview June 2003 Service that is responsible for handles under the naming authority "cnri.dlib". The service information allows the client to communicate with the Local Handle Service to resolve the handle "cnri.dlib/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 "cnri.dlib" V | "cnri.dlib" | | ---------------------- | | | | V | | Local Handle Service | --------------- | responsible for the | | | | 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 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 Local Handle Service without contacting the Global Handle Registry. 5. Handle System Service and its Security The Handle System provides handle resolution and administration service over the public Internet. Each handle can be assigned with 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. Sun Expires - December 2003 [Page 10]
Internet-Draft Handle System Overview June 2003 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 define 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, as well as non-repudiation. By default, handle resolution service does not require any client authentication. However, resolution request for confidential data assigned to any handle (by its administrator), as well as any administration request (e.g. adding or deleting handle values) require authentication of the client for proper authorization. Via the authorization process, the server may decide whether the client has the permission to access those confidential handle values, or has permissions 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 that identifies itself as the 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. Authentication under Handle System 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 a secured communication session with the handle server so that any exchanged information can be encrypted (for data confidentiality) using the session key. The handle server can also provide confidentiality service by encrypting the handle data before sending them to the client. The Handle System provides service options for secured information exchange between client and server. This does not 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 Sun Expires - December 2003 [Page 11]
Internet-Draft Handle System Overview June 2003 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 large amount of data is associated with any particular DNS name. It is generally considered inadequate to use DNS for naming any kind of resources over the Internet. 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 with 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 comprise security options to assure confidentiality and integrity during data transmission. Each handle under the Handle System may define its own administrator that is independent from the server administrator. The handle system protocol allows any handle administrator to manage its 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 huge 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 Sun Expires - December 2003 [Page 12]
Internet-Draft Handle System Overview June 2003 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, a 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 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 Sun Expires - December 2003 [Page 13]
Internet-Draft Handle System Overview June 2003 "cnri.dlib/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 persistent name service. The Handle System provides necessary mechanism to allow persistent names registered as handles. Specific naming authorities may be defined to host those handles that designed to be persistent. However, the persistence of handles depends more on the administrative policies than the technology itself. They 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 namespace persistency is not required. These applications may have their specific naming authorities where handles under these naming authorities are not necessarily persistent. 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 need. 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 perspective naming authority) in naming and resolving their 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 regarding to other existing name services on the Internet. Such discussions are out of the scope of this document and will be discussed in a separate 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] or its data and service model [22] are addressed in separate documents. Sun Expires - December 2003 [Page 14]
Internet-Draft Handle System Overview June 2003 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 rightfully 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 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 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. Sun Expires - December 2003 [Page 15]
Internet-Draft Handle System Overview June 2003 7.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 any handle service. They are clients of the Handle System. Service responses from proxy and caching servers cannot be authenticated via 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 the proxy and 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 server 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 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. 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 administrator must be done carefully. Each mirroring site must follow the same security procedures in order to ensure the 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 attack. No general solutions are available to protect Sun Expires - December 2003 [Page 16]
Internet-Draft Handle System Overview June 2003 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. 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 described in a paper by Robert Kahn and Robert Wilensky [1] in 1995. It was then 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 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. 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 include 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. 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, Helen She, and Brian Boesch. 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). References and Bibliography Sun Expires - December 2003 [Page 17]
Internet-Draft Handle System Overview June 2003 [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 [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 Sun Expires - December 2003 [Page 18]
Internet-Draft Handle System Overview June 2003 [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-05.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-02.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 Sun Expires - December 2003 [Page 19]