idnits 2.17.1 draft-sun-handle-system-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 377 has weird spacing: '...erms of handl...' == Line 378 has weird spacing: '...ite may consi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2003) is 7584 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 842 looks like a reference -- Missing reference section? '3' on line 845 looks like a reference -- Missing reference section? '4' on line 848 looks like a reference -- Missing reference section? '17' on line 887 looks like a reference -- Missing reference section? '5' on line 851 looks like a reference -- Missing reference section? '6' on line 854 looks like a reference -- Missing reference section? '7' on line 857 looks like a reference -- Missing reference section? '8' on line 860 looks like a reference -- Missing reference section? '9' on line 863 looks like a reference -- Missing reference section? '10' on line 866 looks like a reference -- Missing reference section? '12' on line 872 looks like a reference -- Missing reference section? '13' on line 874 looks like a reference -- Missing reference section? '14' on line 878 looks like a reference -- Missing reference section? '15' on line 881 looks like a reference -- Missing reference section? '16' on line 884 looks like a reference -- Missing reference section? '23' on line 907 looks like a reference -- Missing reference section? '11' on line 869 looks like a reference -- Missing reference section? '21' on line 899 looks like a reference -- Missing reference section? '22' on line 903 looks like a reference -- Missing reference section? '19' on line 893 looks like a reference -- Missing reference section? '20' on line 896 looks like a reference -- Missing reference section? '1' on line 839 looks like a reference -- Missing reference section? '18' on line 890 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 25 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Sam X. Sun 3 Document: draft-sun-handle-system-12.txt CNRI 4 Expires: January 2003 Larry Lannom 5 CNRI 6 Brian Boesch 7 CNRI 8 July 2003 10 Handle System Overview 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document provides an overview of the Handle System in terms of 36 its namespace and service architecture, as well as its relationship 37 to other Internet services such as DNS, LDAP/X.500, and URN. The 38 Handle System is a general-purpose global name service that allows 39 secured name resolution and administration over networks such as 40 the Internet. The Handle System manages handles, which are unique 41 names for digital objects and other Internet resources. 43 Table of Contents 45 1. Introduction..................................................2 46 2. Motivations...................................................5 47 3. Handle Namespace..............................................6 48 4. Handle System Architecture....................................8 49 5. Handle System Security.......................................11 50 6. The Handle System and other Internet Services................12 51 6.1 Domain Name Service (DNS)...................................12 52 6.2 Directory Services (X.500/LDAP).............................13 53 6.3 Uniform Resource Identifier (URI)/Uniform Resource Name(URN) 13 54 7. Security Considerations......................................14 55 7.1 General Security Practice...................................15 56 7.2 Privacy Protection..........................................15 57 7.3 Caching and Proxy Servers...................................16 58 7.4 Mirroring...................................................16 59 7.5 Denial of Service (DoS).....................................17 60 8. History of the Handle System.................................17 61 9. Acknowledgements.............................................17 62 References and Bibliography.....................................18 63 Author's Addresses..............................................19 65 1. Introduction 67 This document provides an overview of the Handle System, a 68 distributed information system designed to provide an efficient, 69 extensible, and secured global name service for use on networks 70 such as the Internet. The Handle System includes an open protocol, 71 a namespace, and a reference implementation of the protocol. The 72 protocol enables a distributed computer system to store names, or 73 handles, of digital resources and resolve those handles into the 74 information necessary to locate, access, and otherwise make use of 75 the resources. These associated values can be changed as needed to 76 reflect the current state of the identified resource without 77 changing the handle. This allows the name of the item to persist 78 over changes of location and other current state information. Each 79 handle may have its own administrator(s) and administration can be 80 done in a distributed environment. The Handle System supports 81 secured handle resolution. Security services such as data 82 confidentiality, data integrity, and non-repudiation are provided 83 upon client request. 85 The Handle System provides a confederated name service that allows 86 any existing local namespace to join the global handle namespace by 87 obtaining a unique handle system naming authority. Local names and 88 their value-binding(s) remain intact after joining the Handle 89 System. Any handle request to the local namespace may be processed 90 by a service interface speaking the handle system protocol. 91 Combined with the unique naming authority, any local name is 92 guaranteed unique under the global handle namespace. 94 There are several services that are in use today to provide name 95 service for Internet resources. Among these, the Domain Name System 96 (DNS) [2,3] is the most widely used. DNS is designed "to provide a 97 mechanism for naming resources in such a way that the names are 98 mappable into IP addresses and are usable in different hosts, 99 networks, protocol families, internets, and administrative 100 organizations" [3]. The growth of the Internet has raised demands 101 for various extensions to DNS. There are also attempts to use DNS 102 as a general-purpose resource naming system. However, the 103 importance of DNS in basic network routing has led to great caution 104 in implementing any DNS extension or overloading the DNS for 105 general-purpose resource naming. An additional factor which argues 106 against using DNS as a general-purpose naming service is the DNS 107 administrative model. DNS names are typically managed by the 108 network administrator(s) at the DNS zone level. There is no 109 provision for per-name administrative structure and no facilities 110 for anyone other than the network administrator to create or manage 111 DNS names. This is appropriate for domain name administration but 112 less so for general-purpose resource naming. 114 The Handle System has been designed from the start to serve as a 115 general-purpose naming service. It is designed to accommodate very 116 large numbers of entities and to allow distributed administration 117 over the public Internet. The handle system data model allows 118 access control to be defined at the level of each of the one or 119 more data values associated with a given handle. Each handle can 120 further define its own set of administrators that are independent 121 from the network or host administrator. 123 Traditional URLs (Uniform Resource Locators) [4] allow certain 124 Internet resources to be named as a combination of a DNS name and 125 local name. The local name may be a local file path, or a reference 126 to some local service (e.g., a cgi-bin script). This combination of 127 DNS name and local name provides a flexible administrative model 128 for naming and managing individual Internet resources. However, the 129 URL practice also has some key limitations. Most URL schemes (e.g., 130 http) are defined for resolution only. Any URL administration has 131 to be done either at the local host, or via some other network 132 service such as NFS. Using a URL as a name typically ties the 133 Internet resource to its current network location. For example, a 134 URL will be tied to its local file path when the file path is part 135 of the URL. When the resource moves from one location to another 136 for whatever reason, the URL breaks. It is especially difficult to 137 work around this problem when the reason for the location change is 138 change in ownership of an asset, as ownership is generally 139 reflected in the domain name. 141 The Handle System is designed to overcome these limitations and to 142 add significant functionality. Specifically, the Handle System is 143 designed with the following objectives: 145 . Uniqueness: Every handle is globally unique within the Handle 146 System. 148 . Persistence: Handles may be used as persistent identifiers for 149 Internet resources. A handle does not have to be derived in 150 any way from the entity that it names. While an existing name, 151 or even a mnemonic, may be included in a handle for 152 convenience, the only operational connection between a handle 153 and the entity it names is maintained within the Handle 154 System. This of course does not guarantee persistence, which 155 is a function of administrative care. But it does allow the 156 same name to persist over changes of location, ownership, and 157 other state conditions. For example, when a named resource 158 moves from one location to another, the handle may be kept 159 valid by updating its value in the Handle System to reflect 160 the new location. 162 . Multiple Instances: A single handle can refer to multiple 163 instances of a resource, at different and possibly changing 164 locations in a network. Applications can take advantage of 165 this to increase performance and reliability. For example, a 166 network service may define multiple entry points for its 167 service with a single handle so as to distribute the service 168 load. 170 . Multiple Attributes: A single handle can refer to multiple 171 attributes of a resource, including associated services, 172 available through any method, again at different and possibly 173 changing network locations. Handles can thus be used as 174 persistent entry points into an evolving world of services 175 associated with identified resources. 177 . Extensible Namespace: Existing local namespaces may join the 178 handle namespace by acquiring a unique handle naming 179 authority. This allows local namespaces to be introduced into 180 a global context while avoiding conflict with existing 181 namespaces. Use of naming authorities also allows delegation 182 of service, both resolution and administration, to a local 183 handle service. 185 . International Support: The handle namespace is based on 186 Unicode 3.0 [17], which includes most of the characters 187 currently used around the world. This allows handles to be 188 used in any native environment. The handle protocol mandates 189 UTF-8 [5] as the encoding used for handles. 191 . Distributed Service Model: The Handle System defines a 192 hierarchical service model such that any local handle 193 namespace may be serviced either by a corresponding local 194 handle service or by the global service or by both. The global 195 service, known as the Global Handle Registry, can be used to 196 dispatch any handle service request to the responsible local 197 handle service. The distributed service model allows 198 replication of any given service into multiple service sites 199 and each service site may further distribute its service into 200 a cluster of individual servers. (Note that local here refers 201 only to namespace and administrative concerns. A local handle 202 service could in fact have many service sites distributed 203 across the Internet.) 205 . Secured Name Service: The Handle System allows secured name 206 resolution and administration over the public Internet. The 207 handle system protocol defines standard mechanisms for both 208 client and server authentication, as well as service 209 authorization. It also provides security options to assure 210 data integrity and confidentiality. 212 . Distributed Administration Service: Each handle may define its 213 own administrator(s) or administrator group(s). Ownership of 214 each handle is defined in terms of its administrator or 215 administrator groups. This, combined with the handle system 216 authentication protocol, allows any handle to be managed 217 securely over the public network by its administrator at any 218 network location. 220 . Efficient Resolution Service: The handle protocol is designed 221 to allow highly efficient name resolution performance. To 222 avoid resolution being affected by computationally costly 223 administration service, separate service interfaces (i.e., 224 server processes and their associated communication ports) for 225 handle name resolution and administration may be defined by 226 any handle service. 228 This document provides an overview of the handle namespace and 229 service architecture. It also compares the Handle System with other 230 existing Internet services, protocols, and specifications (e.g., 231 DNS [2, 3], URLs [4], X.500/LDAP [6,7,8], and URN [9,10]). Details 232 of the handle system data and service model, as well as its 233 communication protocol, are specified in separate documents. They 234 can be found under the Handle System website at 235 http://www.handle.net. 237 2. Motivations 239 Since there are a number of name related projects in the Internet 240 community, it is worth defining exactly where we believe the Handle 241 System fits. Unfortunately, that is particularly hard because the 242 other primary naming schemes take either an abstract services 243 approach (e.g., URI/URN) or an approach to name resolution absent a 244 self-contained framework for reliable yet distributed 245 administration of the underlying databases (e.g., DNS). This makes 246 categorizing the Handle System difficult. 248 The Handle System crosses boundaries. Looked at as a name 249 resolution system, it might be compared to DNS. If used to 250 implement a URI/URN namespace, it could be used with any URI/URN 251 scheme. If used for distributed information update and 252 administration, it could be considered a simplified-version of a 253 distributed database system. 255 It is probably best to view the Handle System as a name-attribute 256 binding service with a specific protocol for securely creating, 257 updating, maintaining, and accessing a distributed database. It is 258 designed to be an enabling service for secured information and 259 resource sharing over the networks such as the public Internet. 260 Applications of the Handle System could include meta-data services 261 for digital publications, identity management services for virtual 262 identities, or any other applications that require resolution 263 and/or administration of globally unique identifiers. 265 In the spirit of exploration, the Handle System has been designed 266 to have high performance for name resolution and to push the 267 boundaries of distributed access control and administration. 268 Unlike most conventional systems (even distributed systems) that 269 are designed to have a relatively small number of broadly empowered 270 administrators, the Handle System allows extremely fine granularity 271 of administrative control. It has a unique self-contained 272 administrative framework that de-couples the ownership of each 273 handle from the system administrators and allows access control to 274 be defined for each handle value. 276 It should be noted, that as with all real systems, the Handle 277 System is a compromise between a number of technical and practical 278 concerns. There are also different opinions within IETF on where 279 the Handle System fits in relation to other existing Internet name 280 services. It is with the goal of exposing a broader community to 281 the concepts, approach, specific decisions, tradeoffs and results 282 that we are writing this RFC. 284 3. Handle Namespace 286 Every handle consists of two parts: its naming authority, otherwise 287 known as its prefix, and a unique local name under the naming 288 authority, otherwise known as its suffix: 290 ::= "/" 292 The naming authority and local name are separated by the ASCII 293 character "/". The collection of local names under a naming 294 authority defines the local handle namespace for that naming 295 authority. Any local name must be unique under its local namespace. 296 The uniqueness of a naming authority and a local name under that 297 authority ensures that any handle is globally unique within the 298 context of the Handle System. 300 For example, "10.1045/january99-bearman" is a handle for an article 301 published in D-Lib magazine [12]. Its naming authority is "10.1045" 302 and its local name is "january99-bearman". The handle namespace can 303 be considered a superset of many local namespaces, with each local 304 namespace having a unique naming authority under the Handle System. 305 The naming authority identifies the administrative unit of 306 creation, although not necessarily continuing administration, of 307 the associated handles. Each naming authority is guaranteed to be 308 globally unique within the Handle System. Any existing local 309 namespace can join the global handle namespace by obtaining a 310 unique naming authority so that any local name under the namespace 311 can be globally referenced as a combination of the naming authority 312 and the local name as shown above. 314 Naming authorities under the Handle System are defined in a 315 hierarchical fashion resembling a tree structure. Each node and 316 leaf of the tree is given a label that corresponds to a naming 317 authority segment. The parent node presents the parent naming 318 authority of its child nodes. Unlike DNS, handle naming authorities 319 are constructed left to right, concatenating the labels from the 320 root of the tree to the node that represents the naming authority. 321 Each label is separated by the octet used for ASCII character "." 322 (0x2E). For example, a naming authority for the National Digital 323 Library Program ("ndlp") at the Library of Congress ("loc") is 324 defined as "loc.ndlp". 326 Each naming authority may have many child naming authorities 327 registered underneath. Any child naming authority can only be 328 registered by its parent after its parent naming authority is 329 registered. However, there is no intrinsic administrative 330 relationship between the namespaces represented by the parent and 331 child naming authorities. The parent namespace and its child 332 namespaces may be served by different handle services, and they may 333 or may not share any administration privileges. 335 Handles may consist of any printable characters from the Universal 336 Character Set (UCS-2) of ISO/IEC 10646, which is the exact 337 character set defined by Unicode v3.0 [17]. The UCS-2 character set 338 encompasses most characters used in every major language written 339 today. To allow compatibility with most of the existing systems and 340 to prevent ambiguity among different encodings, the handle system 341 protocol mandates UTF-8 to be the only encoding used for handles. 342 The UTF-8 encoding preserves any ASCII encoded names so as to allow 343 maximum compatibility with existing systems without causing naming 344 conflict. Some encoding issues over the global namespace and the 345 choice of UTF-8 encoding are discussed in [13]. 347 By default, handles are case sensitive. However, any individual 348 handle service may define its namespace such that ASCII characters 349 within any handle under that namespace are case insensitive. 351 4. Handle System Architecture 353 The Handle System defines a hierarchical service model. The top 354 level consists of a single handle service, known as the Global 355 Handle Registry (GHR). The lower level consists of all other handle 356 services, generically known as Local Handle Services (LHS). 358 The Global Handle Registry can be used to manage any handle 359 namespace. It is unique among handle services only in that it 360 provides the service used to manage naming authorities, all of 361 which are managed as handles. The naming authority handle provides 362 information that clients can use to access and utilize the local 363 handle service for handles under the naming authority. 365 Local Handle Services are intended to be hosted by organizations 366 with administrative responsibility for handles under certain naming 367 authorities. A Local Handle Service may be responsible for any 368 number of local handle namespaces, each identified by a unique 369 naming authority. The Local Handle Service and its responsible set 370 of local handle namespaces must be registered with the Global 371 Handle Registry. 373 One important aspect of the Handle System is its distributed 374 architecture. The Handle System as a whole consists of a number of 375 individual handle services. Each of these services may consist of 376 one or more service sites. Each service site is a complete 377 replication of every other site in the service, in terms of handle 378 resolution. Each service site may consist of one or more handle 379 servers. All handles, and hence all handle requests, directed at a 380 given service site will be evenly distributed across these handle 381 servers. The Handle System as a whole may consist of any number of 382 handle services. There are no design limits on the number of handle 383 services or on the number of sites which make up each service. 384 Neither are there any limits on the number of servers that make up 385 each site. Replication among any service sites does not require 386 that each site contain the same number of servers. In other words, 387 while each site will have the same replicated set of handles, each 388 site may allocate that set of handles across a different number of 389 servers. This distributed approach is intended to aid scalability, 390 to accommodate any large-scale of operation, and to mitigate 391 problems of single point failure. 393 Figure 3.1 illustrates a potential handle service that consists of 394 two service sites: one located on the U.S. east coast and the other 395 on the U.S. west coast. The east coast service site consists of 396 four server computers. The west coast service site, with more 397 powerful computers deployed, decides two servers will suffice. The 398 number of service sites for any handle service, as well as the 399 number of servers that are used by any service site, may be added 400 or removed dynamically depending on the service requirement. 402 ------------------------- ------------------ 403 | --------- --------- | | ----- ----- | 404 | | | | | | | | S | | S | | 405 | | server1 | | server2 | | | | E | | E | | 406 | | | | | | | | R | | R | | 407 | --------- --------- | | | V | | V | | 408 | --------- --------- | | | E | | E | | 409 | | | | | | | | R | | R | | 410 | | Server3 | | Server4 | | | | | | | | 411 | | | | | | | | 1 | | 2 | | 412 | --------- --------- | | ----- ----- | 413 ------------------------- ------------------ 415 Handle Service Site 1 Handle Service Site 2 416 (US East Coast) (US West Coast) 418 Fig. 3.1: Handle service configured with two service sites 420 Each handle service manages a distinct sub-namespace under the 421 Handle System. Namespaces under different handle services may not 422 overlap. The sub-namespace typically consists of handles under a 423 number of naming authorities. The handle service is called the 424 "home" service of these naming authorities and is the only one that 425 provides resolution and administration service for handles under 426 these naming authorities. Before resolving a handle, a client has 427 to determine the "home" service of the handle in question. The 428 "home" service of each handle is the "home" service of its naming 429 authority and is registered at the Global Handle Registry. Clients 430 can find the "home" service for each handle by querying the naming 431 authority handle at the Global Handle Registry. 433 The Global Handle Registry maintains naming authority handles. Each 434 naming authority handle maintains the service information that 435 describes the "home" service of the naming authority. The service 436 information lists the service sites of the given handle service, as 437 well as the interface to each handle server within each site. To 438 find the "home" service for any handle, a client can query the 439 Global Handle Registry for the service information associated with 440 the corresponding naming authority handle. The service information 441 provides the necessary information for clients to communicate with 442 the "home" service. 444 Figure 3.2 shows an example of a typical handle resolution process. 445 In this case, the "home" service is a Local Handle Service. The 446 client is trying to resolve the handle "10.1045/july95-arms" and 447 has to find its "home" service from the Global Handle Registry. The 448 "home" service can be found by sending a query to the Global Handle 449 Registry for the naming authority handle for "10.1045". The Global 450 Handle Registry returns the service information of the Local Handle 451 Service that is responsible for handles under the naming authority 452 "10.1045". The service information allows the client to communicate 453 with the Local Handle Service to resolve the handle 454 "10.1045/july95-arms". 456 ------------------------ 457 | | 4. Result of client request 458 | Client with global | <-------------------------------. 459 | service information | | 460 | | ----------------------------. | 461 ------------------------ 3. Request to responsible | | 462 | ^ Local Handle Service | | 463 1. Client | | | | 464 query for | | | | 465 naming | | 2. Service information | | 466 authority | | for "10.1045" V | 467 "10.1045" | | ---------------------- 468 | | | | 469 V | | Local Handle Service | 470 --------------- | responsible for the | 471 | | | naming authority | 472 | Global Handle | | "10.1045" | 473 | Registry | | | 474 | | ---------------------- 475 --------------- 477 Fig. 3.2: Handle resolution starting with global 479 To improve resolution performance, any client may choose to cache 480 the service information returned from the Global Handle Registry 481 and use it for subsequent queries. A separate handle caching 482 server, either stand-alone or as a piece of a general caching 483 mechanism, may also be used to provide shared caching within a 484 local community. Given a cached resolution result, subsequent 485 queries of the same handle may be answered locally without 486 contacting any handle service. Given cached service information, 487 clients can send their requests directly to the correct Local 488 Handle Service without contacting the Global Handle Registry. 490 5. Handle System Security 492 The Handle System provides handle resolution and administration 493 service over networks such as the public Internet. Each handle can 494 be assigned a set of values. Clients use the handle resolution 495 service to resolve any handle into its set of values. Each value 496 has a data type and a unique value index. Clients can query for 497 specific handle values based on data type or value index. 499 The handle administration service answers requests from clients to 500 manage handles. These include adding handles, deleting handles or 501 updating their values. It also manages naming authorities via 502 naming authority handles. Each handle can have its own 503 administrator(s) and each administrator can be granted a certain 504 set of permissions. The handle system authentication protocol 505 authenticates the handle administrator before fulfilling any 506 administrative request. 508 The Handle System provides security services such as client and 509 server authentication, data confidentiality and integrity, and non- 510 repudiation. By default, handle resolution does not require any 511 client authentication. However, resolution requests for 512 confidential data assigned to any handle (by its administrator), as 513 well as any administration requests (e.g., adding or deleting 514 handle values) require authentication of the client for proper 515 authorization. The server will decide, during the authorization 516 process, whether or not the client has permission to access those 517 confidential handle values, or has permission to add or update 518 handles and handle values. When authentication is required, the 519 handle server will issue a challenge to the requesting client 520 before carrying out the client's request. To satisfy the 521 authentication requirement, the client must send back the correct 522 response identifying itself as a qualified administrator. The 523 handle server will respond to the initial request only after 524 successful authentication of the client. Handle clients may choose 525 to use either secret key or public key cryptography for 526 authentication. Handle System authentication can also be carried 527 out via third party authentication services. To ensure data 528 integrity, clients may request digitally signed responses from any 529 handle server. They may also set up secured communication sessions 530 with handle servers so that any exchanged information can be 531 encrypted (for data confidentiality) using a session key. Handle 532 servers can also provide confidentiality by encrypting the handle 533 data before sending it to the client. 535 The Handle System provides service options for secured information 536 exchange between client and server. This does not, of course, 537 guarantee the truthfulness of handle values. Incorrect values 538 assigned to any handle by its administrator may very well mislead 539 clients. On the other hand, a handle value may contain references 540 to other handle values to provide additional credentials. For 541 example, a handle value R (e.g., a claim) may contain a reference 542 to some other handle value that contains the digital signature 543 (from a creditable source) upon the value R. Clients who trust the 544 signature could then trust the handle value R. 546 6. The Handle System and other Internet Services 548 There are a number of existing and proposed Internet identifier 549 services or specifications that by design or intent cover some of 550 the functionalities proposed for the Handle System. This section 551 briefly reviews them in relationship to the Handle System. 553 6.1 Domain Name Service (DNS) 555 The Domain Name Service, or DNS, was originally designed and is 556 heavily used for mapping domain names into IP Addresses for network 557 routing purposes. RFC1034 [2] and RFC1035 [3] provide detailed 558 descriptions of its design and implementation. The growth of the 559 Internet has increased demands for various extensions to DNS, even 560 its possible use as a general purpose resource naming system. 561 However, any such use has the potential to slow down the network 562 address translation and/or affect its effectiveness in network 563 routing. DNS implementations typically do not scale well when a 564 large amount of data is associated with any particular DNS name. It 565 is therefore generally considered inappropriate to use DNS as a 566 general-purpose naming service. 568 An additional factor that argues against using DNS as a general- 569 purpose naming service is the DNS administrative model. DNS names 570 are typically managed by the network administrator(s) at the DNS 571 zone level. There is no provision for a per-name administrative 572 structure. No facilities are provided for anyone other than network 573 administrators to create or manage DNS names. This is appropriate 574 for domain name administration but less so for general-purpose name 575 administration. 577 The Handle System differs from DNS in its distributed 578 administration and service model, as well as its security features. 579 The handle system protocol includes security options to assure 580 confidentiality and integrity during data transmission. Each handle 581 can have its own administrator, independent from the server 582 administrator. The handle system protocol allows any handle 583 administrator to manage his or her handles securely over the public 584 network. Additionally, the Handle System service model allows any 585 of its service sites to dynamically configure its service 586 distribution among a cluster of servers to accommodate increased 587 service requests. This also allows less powerful computers to be 588 used together to support any arbitrarily large number of handles. 590 6.2 Directory Services (X.500/LDAP) 592 X.500 [6] is the OSI Directory Standard defined by ISO and the ITU. 593 It is designed "to provide a white pages service that would return 594 either the telephone numbers or X.400 O/R addresses of people", and 595 is "concerned mainly with providing the name server service for 596 Open Systems Interconnection (OSI) applications" [7]. X.500 defines 597 a hierarchical data and information model with a set of protocols 598 to allow global name lookup and search. The protocol, however, has 599 proved difficult to implement and there has been difficulty in 600 getting "client access integrated into existing products" [14]. 601 LDAP (Lightweight Directory Access Protocol) [8] has overcome many 602 of these difficulties by making the protocol simpler, and easier to 603 implement. Some concern remains, however, that as LDAP is emerging 604 from a local directory access protocol (LDAP v2) into a distributed 605 service protocol (LDAP v3), it faces many issues not addressed in 606 its original design, resulting in new complications. 608 The fundamental difference between a name resolution service such 609 as the Handle System and a directory service such as LDAP is search 610 capability. The added functionality of being able to search a 611 directory service necessarily carries with it added complexity, 612 thus affects its efficiency. A pure name service, such as the 613 Handle System, can be designed solely around efficient resolution 614 of known items without addressing functions and data structures 615 required for discovery of unknown items based on incomplete 616 criteria. 618 Directory services such as LDAP or WHOIS++ [15,16] may be used in 619 tandem with the Handle System to provide reverse lookup service. 620 Existing corporate directory services, for example, could provide 621 interfaces to both services. The handle system interface would 622 provide a highly efficient name resolution service. The directory 623 service interface would provide extended search capability. Handles 624 could also be used in LDAP service referral. For example, an LDAP 625 service may be referenced as a handle. Doing so will make the 626 reference persistent overtime, independent from location change. 628 6.3 Uniform Resource Identifier (URI)/Uniform Resource Name(URN) 630 Uniform Resource Identifier (URI) [23] defines a uniform yet 631 extensible naming mechanism for identifying Internet resources in 632 web applications. Uniform Resource Name (URN) [11], a subset of 633 URI, defines a namespace registration mechanism for persistent 634 namespaces under URI. URI/URN represents most of the Internet name 635 services used in web applications. This section discusses the 636 relationship of the Handle System to URI/URN and how applications 637 may utilize the Handle System within the URI/URN context. 639 The Handle System provides a general-purpose name service for the 640 Internet. Like DNS or X.500 directory service, the handle system 641 defines its namespace outside of any URI/URN namespace. Handles can 642 be transcribed and resolved directly, without any URI/URN scheme as 643 a prefix. For example, a library application may resolve the handle 644 "10.1045/july95-arms" directly into its set of handle values. No 645 URI/URN scheme will be needed in this case. 647 The Handle System may be used for applications that require a 648 persistent name service. The Handle System provides the necessary 649 mechanisms to allow persistent names to be registered as handles. 650 Specific naming authorities may be defined to host those handles 651 designed to be persistent. However, the persistence of handles 652 depends more on administrative policies than the technology itself. 653 Such policies are beyond the handle system service as described in 654 this set of documents. 656 On the other hand, the Handle System can also be used for 657 applications where persistent names are not required. Such handles 658 may have a short life-time and they may also be used to identify 659 different objects at different times. 661 Different web applications may be developed using the Handle System 662 as the underlying name service. Each of these applications may 663 define its own URI/URN namespace for its application needs. For 664 example, application FOO may have a URI namespace "foo:" registered 665 to identify any FOO services on the web. In the mean time, 666 application BAR may have a URN namespace "URN:BAR" registered to 667 identify any BAR object that needs a persistent name. Both FOO and 668 BAR applications may use handles (under their respective naming 669 authority) in naming and resolving to services and/or objects. This 670 is similar in DNS, where there are different URI schemes (e.g., 671 "telnet", "ftp", "mailto", etc.) defined for different 672 applications, all using the DNS service. 674 The IETF and IRTF have discussed the Handle System in the realm of 675 URI-related work. There are different opinions on whether the 676 Handle System will fit into a specific URI or URN namespace. There 677 are also concerns on where the Handle System fits in relation to 678 other existing name services on the Internet. Such discussions are 679 out of the scope of this document. 681 7. Security Considerations 683 This section is meant to inform people of security limitations of 684 the Handle System, as well as precautions that should be taken by 685 application developers, service providers, and handle system 686 clients. Specific security considerations regarding the handle 687 system protocol [21] as well as its data and service model [22] are 688 addressed in separate documents. 690 7.1 General Security Practice 692 The security of the Handle System depends on both client and server 693 host security at every step in the transaction. It assumes the 694 client host has not been tampered with and that client software 695 will reliably convey the received data to the client. The client of 696 any handle service must also assume that any handle servers 697 involved have not been compromised. To trust the Global Handle 698 Registry is to believe that the Global Handle Registry will 699 correctly direct the client request to the responsible Local Handle 700 Service. To trust a Local Handle Service is to believe that the 701 Local Handle Service will correctly return the data that was 702 assigned to the handle by its administrator. A Local Handle Service 703 typically supports a set of naming authorities. Thus, trusting a 704 Local Handle Service would imply trusting those naming authorities. 706 The integrity of the Handle System depends heavily on the integrity 707 of the global service information. Invalid global service 708 information may mislead clients into inappropriate Local Handle 709 Services. It may also allow attackers to forge server signatures. 710 The Global Handle Registry must take extreme caution in protecting 711 the global service information and the public key pair used to sign 712 the global service information. Client applications should only 713 accept the global service information from the Global Handle 714 Registry. They should check its integrity upon each update. 716 For efficiency reasons, handle servers will not generate or return 717 a digital signature for every service response unless specifically 718 requested by clients. To assure data integrity, clients must 719 explicitly ask the server to return the digital signature. To 720 protect sensitive data from exposure, clients may establish a 721 communication session with the server and ask the server to encrypt 722 any data using the session key. 724 7.2 Privacy Protection 726 By default, most handle data stored in the Handle System is 727 publicly accessible unless otherwise specified by the handle 728 administrator. Handle administrators must pay attention when adding 729 handle values that contain private information. They may choose to 730 mark these handle values readable only by the handle 731 administrator(s), or to store these handle values encrypted, so 732 that these values can only be readable within a controlled 733 audience. 735 Log files generated by the handle server are another vulnerable 736 point where client privacy may be under attack. Operators of handle 737 servers must protect such information carefully. 739 7.3 Caching and Proxy Servers 741 Besides performance gains and other value-added services, both 742 proxy and caching servers present themselves as men-in-the-middle, 743 and as such are vulnerable to man-in-the-middle attacks. It is 744 important to know that proxy and caching servers are not part of 745 any handle service. They are clients of the Handle System. Service 746 responses from proxy and caching servers cannot be authenticated 747 via the handle system protocol. The trust between the client and 748 its immediate proxy/caching server has to be setup independently, 749 regardless of the number of proxy/caching servers that are in the 750 middle of the communication path. 752 By using proxy and caching servers, clients assume that the servers 753 will submit their requests and relay any responses from the Handle 754 System, without mishandling any of the contents. They also assume 755 that the servers will protect any sensitive information on their 756 behalf. 758 Proxy and caching server operators should protect the systems on 759 which such servers are running as they would protect any system 760 that contains or transports sensitive information. In particular, 761 log information gathered at proxies often contain highly sensitive 762 personal information, and/or information about organizations. Such 763 information should be carefully guarded, and appropriate guidelines 764 for their use developed and followed. 766 Caching servers provide additional potential vulnerabilities 767 because the contents of the cache represent an attractive target 768 for malicious exploitation. Potential attacks on the cache can 769 reveal private data for a handle user, or information still kept 770 after a user believes that they have been removed from the network. 771 Therefore, cache contents should be protected as sensitive 772 information. 774 7.4 Mirroring 776 Handle System clients should be aware of possible delays in content 777 replication among mirroring sites. They should consider sending 778 their request to the primary service site for any time-sensitive 779 data. Selection of mirroring sites by service administrators must 780 be done carefully. Each mirroring site must follow the same 781 security procedures in order to ensure data integrity. Software 782 tools may be applied to ensure data consistency among mirroring 783 sites. 785 7.5 Denial of Service (DoS) 787 As with any public service, the Handle System is subject to denial 788 of service attack. No general solutions are available to protect 789 against such attacks in today's technology. Server implementations 790 may be developed to be aware of such attacks and notify 791 administrators when they happen. Stateless cookies [19, 20] are one 792 means to mitigate some of the effects of DoS attacks on hosts that 793 perform authentication, integrity, and encryption services. Server 794 implementations, moreover, need to be upgradeable to take advantage 795 of new security technologies including anti-DoS technologies as 796 these become available. 798 8. History of the Handle System 800 The Handle System was originally conceived and developed at CNRI as 801 part of an overall digital object architecture. The first public 802 implementation was created at CNRI in the fall of 1994 in an effort 803 led by David Ely. The overall digital object architecture, 804 including the Handle System, was later described in a paper by 805 Robert Kahn and Robert Wilensky [1] in 1995. Development continued 806 at CNRI as part of the Computer Science Technical Reports (CSTR) 807 project, funded by the Defense Advanced Projects Agency (DARPA) 808 under Grant Number MDA-972-92-J-1029. One aspect of this early 809 digital library project, which was also a major factor in the 810 evolution of the Networked Computer Science Technical Reference 811 Library (NCSTRL) [18] and related activities, was to develop a 812 framework for the underlying infrastructure of digital libraries. 814 Early adopters of the Handle System included the Library of 815 Congress, the Defense Technical Information Center (DTIC), and the 816 International DOI Foundation (IDF). Feedback from these 817 organizations as well as NCSTRL, other digital library projects, 818 and related IETF efforts as mentioned above have all contributed to 819 the evolution of the Handle System. Current status and available 820 software, both client and server, can be found at 821 http://www.handle.net. 823 9. Acknowledgements 825 This work is derived from the earlier versions of the handle system 826 implementation. Design ideas are based on those discussed within 827 the handle system development team, including David Ely, Charles 828 Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie 829 Nguyen, Jason Petrone, and Helen She. Their contributions to this 830 work are gratefully acknowledged. 832 The authors also thank Russ Housley (housley@vigilsec.com), Ted 833 Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) 834 for their extensive review and comments, as well as recommendations 835 received from other members of the IETF/IRTF community. 837 References and Bibliography 839 [1] R. Kahn, & R. Wilensky, "A Framework for Distributed Digital 840 Object Services", D-Lib Magazine, 1995 842 [2] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 843 RFC1034, November 1987 845 [3] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND 846 SPECIFICATION", RFC1035, November 1987 848 [4] Berners-Lee, T., Masinter, L., McCahill, M., et al., "Uniform 849 Resource Locators (URL)", RFC1738, December 1994 851 [5] Yergeau, Francois, "UTF-8, A Transform Format for Unicode and 852 ISO10646", RFC2044, October 1996 854 [6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models, 855 and Services", 1993 857 [7] D W Chadwick, "Understanding X.500 - The Directory", Chapman & 858 Hall ISBN: 0-412-43020-7 860 [8] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 861 Access Protocol (v3)", RFC 2251, December 1997 863 [9] Sollins, K., and L. Masinter, "Functional Requirements for 864 Uniform Resource Names", RFC 1737, December 1994 866 [10] Sollins, K. "Architectural Principles of Uniform Resource Name 867 Resolution", RFC 2276, January 1998 869 [11] IETF Uniform Resource Names (URN) Working Group, April, 1998, 870 http://www.ietf.org/html.charters/urn-charter.html 872 [12] D-Lib Magazine, http://www.dlib.org 874 [13] Sam X. Sun, "Internationalization of the Handle System - A 875 Persistent Global Name Service", Proceeding of 12th International 876 Unicode Conference, April, 1998 878 [14] D Goodman, C Robbins, "Understanding LDAP & X.500", August 879 1997 881 [15] Deutsch P., Schoultz R., Faltstrom P., and C. Weider, 882 "Architecture of the Whois++ service", RFC 1835, August 1995 884 [16] Weider, C., J. Fullton, and S. Spero, "Architecture of the 885 Whois++ Index Service", RFC 1913, February 1996 887 [17] The Unicode Consortium, "The Unicode Standard, Version v3.0", 888 Addison-Wesley Pub Co; ISBN: 0201616335 890 [18] The Networked Computer Science Technical Reports Library 891 (NCSTRL), http://www.ncstrl.org/ 893 [19] P. Karn, W. Simpson, "Photuris: Session-Key Management 894 Protocol", March, 1999 896 [20] D. Harkins, D Carrel, "The Internet Key Exchange (IKE)", 897 November, 1998 899 [21] S. Sun, S. Reilly, L. Lannom, "Handle System Namespace and 900 Service Definition", IETF draft, http://www.ietf.org/internet- 901 drafts/draft-sun-handle-system-def-08.txt, work in progress 903 [22] S. Sun, S. Reilly, L. Lannom, J. Petrone, "Handle System 904 Protocol Specification", IETF draft, http://www.ietf.org/internet- 905 drafts/draft-sun-handle-system-protocol-05.txt, work in progress 907 [23] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 908 Identifiers (URI): Generic Syntax", RFC 2396, August 1998 910 Author's Addresses 912 Sam X. Sun 913 Corporation for National Research Initiatives (CNRI) 914 1895 Preston White Dr. Suite 100 915 Reston, VA 20191 916 Phone: 703-262-5316 917 Email: ssun@cnri.reston.va.us 919 Larry Lannom 920 Corporation for National Research Initiatives (CNRI) 921 1895 Preston White Dr. Suite 100 922 Reston, VA 20191 923 Phone: 703-620-8990 924 Email: llannom@cnri.reston.va.us 926 Brian Boesch 927 Corporation for National Research Initiatives (CNRI) 928 1895 Preston White Dr. Suite 100 929 Reston, VA 20191 930 Phone: 703-262-5316 931 Email: bboesch@cnri.reston.va.us