idnits 2.17.1 draft-sun-handle-system-def-08.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: ---------------------------------------------------------------------------- -- 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 (June 2003) is 7620 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? '22' on line 1746 looks like a reference -- Missing reference section? '1' on line 1685 looks like a reference -- Missing reference section? '2' on line 1688 looks like a reference -- Missing reference section? '3' on line 1691 looks like a reference -- Missing reference section? '4' on line 1694 looks like a reference -- Missing reference section? '5' on line 1697 looks like a reference -- Missing reference section? '6' on line 1700 looks like a reference -- Missing reference section? '7' on line 1703 looks like a reference -- Missing reference section? '8' on line 1706 looks like a reference -- Missing reference section? '9' on line 1709 looks like a reference -- Missing reference section? '10' on line 1712 looks like a reference -- Missing reference section? '11' on line 1716 looks like a reference -- Missing reference section? '12' on line 1720 looks like a reference -- Missing reference section? '13' on line 1723 looks like a reference -- Missing reference section? '23' on line 1749 looks like a reference -- Missing reference section? '14' on line 1727 looks like a reference -- Missing reference section? '15' on line 1729 looks like a reference -- Missing reference section? '16' on line 1732 looks like a reference -- Missing reference section? '17' on line 1735 looks like a reference -- Missing reference section? '18' on line 1737 looks like a reference -- Missing reference section? '19' on line 1739 looks like a reference -- Missing reference section? 'Client' on line 1535 looks like a reference -- Missing reference section? '20' on line 1741 looks like a reference -- Missing reference section? '21' on line 1744 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 26 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-def-08.txt Sean Reilly 4 Expires: December 2003 Larry Lannom 5 CNRI 6 June 2003 8 Handle System Namespace and Service Definition 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Handle System is a general-purpose global name service that 34 allows secured name resolution and administration over the public 35 Internet. This document provides a detailed description of the 36 Handle System namespace, and its data, service, and operation 37 models. The namespace definition specifies the handle syntax and 38 its semantic structure. The data model defines the data structures 39 used by the handle system protocol and any pre-defined data types 40 for carrying out the handle service. The service model provides 41 definitions of various Handle System components and explains how 42 they work together over the network. Finally, the handle system 43 operation model describes its service operation in terms of 44 messages transmitted between client and server, and the client 45 authentication process based on the handle system authentication 46 protocol. 48 Table of Contents 50 1. Introduction..................................................2 51 2. Handle System Namespace.......................................3 52 3. Handle System Data Model......................................4 53 3.1 Handle Value Set.............................................4 54 3.2 Pre-defined Handle Data Types................................9 55 3.2.1 Handle Administrator: HS_ADMIN............................9 56 3.2.2 Service Site Information: HS_SITE........................14 57 3.2.3 Naming Authority Delegation Service: HS_NA_DELEGATE......19 58 3.2.4 Service Handle: HS_SERV..................................19 59 3.2.5 Alias Handle: HS_ALIAS...................................20 60 3.2.6 Primary Site: HS_PRIMARY.................................21 61 3.2.7 Handle Value List: HS_VLIST..............................21 62 4. Handle System Service Model..................................21 63 4.1 Handle System Service Components............................22 64 4.1.1 Global Handle Registry (GHR).............................22 65 4.1.2 Local Handle Service (LHS)...............................24 66 4.2 Handle System Middle-Ware Components........................26 67 4.2.1 Handle System Caching Service............................26 68 4.2.2 Handle System Proxy Server...............................26 69 4.3 Handle System Client Components.............................27 70 5. Handle System Operation Model................................28 71 5.1 Handle System Service Request and Response..................28 72 5.2 Handle System Authentication Protocol.......................31 73 6. Security Considerations......................................34 74 References and Bibliography.....................................35 75 Author's Addresses..............................................36 77 1. Introduction 79 The Handle System manages handles as globally unique names for 80 Internet resources. It was originally conceived and described in a 81 paper by Robert Kahn and Robert Wilensky [22] in 1995. The Handle 82 System provides a general-purpose global name service that allows 83 handles to be resolved and administrated securely over the public 84 Internet. The Handle System categorizes its service into two 85 categories: the handle resolution service and the handle 86 administration service. Clients use handle resolution service to 87 resolve handles into their values. The handle administration 88 service deals with client requests to manage these handles, 89 including adding and deleting handles, and updating handle values. 91 The document "Handle System Overview" [1] provides an architectural 92 overview of the Handle System, and its relationship to other 93 Internet services such as DNS [2,3] and LDAP[4]. This document 94 provides a detailed description of the Handle System namespace, its 95 data and service model, and its operation model. It assumes that 96 readers are familiar with the basic concepts of the Handle System 97 as described in the overview document. 99 The namespace definition specifies the handle syntax and its 100 semantic structure. The data model defines the data structures used 101 by the handle system protocol and any pre-defined data types for 102 carrying out the handle service. The service model provides 103 definitions of various Handle System components and explains how 104 they work together over the network. Finally, the handle system 105 operation model describes its service operation in terms of 106 messages transmitted between client and server, and the client 107 authentication process based on the handle system authentication 108 protocol. 110 2. Handle System Namespace 112 Handles are character strings that may consist of a wide range of 113 characters. Every handle in the Handle System consists of two 114 parts: its naming authority, followed by a unique local name under 115 the naming authority. The naming authority and the local name are 116 separated by the ASCII character "/" (octet 0x2F). The following 117 table provides the handle syntax definition in ABNF [5] notation: 119 = "/" 121 = *( ".") 123 = 1*(%x00-2D / %x30-3F / %x41-FF ) 124 ; any octets that map to UTF-8 encoded 125 ; Unicode 2.0 characters except 126 ; octets '0x2E' and '0x2F' (which 127 ; correspond to the ASCII characters '.', 128 ; and '/'). 130 = *(%x00-FF) 131 ; any octets that map to UTF-8 encoded 132 ; Unicode 2.0 characters 134 Table 2.1: Handle syntax 136 As shown in Table 2.1, both and are 137 UTF-8 [6] encoded character strings. The handle system protocol 138 mandates UTF-8 encoding for handles transferred over the wire. The 139 may consist of any characters from the Unicode 2.0 140 standard [7]. The may use any characters from the 141 Unicode 2.0 standard except the ASCII character '/' (0x2F), which 142 is reserved to separate the from the . 143 A may consist of multiple non-empty s, 144 each of which separated by the ASCII character '.' (octet 0x2E). 146 Naming authorities are defined in a hierarchical fashion resembling 147 a tree structure. Each node and leaf of the tree is given a label 148 that corresponds to a naming authority segment (). The 149 parent node represents the parent naming authority. Naming 150 authorities are constructed left to right, concatenating the labels 151 from the root of the tree to the node that represents the naming 152 authority. Each label (or its ) is separated by the 153 character '.' (octet 0x2E). For example, the naming authority for 154 the Digital Object Identifier (DOI) project is "10". It is a root- 155 level naming authority as it has no parent naming authority for 156 itself. It can, however, have many child naming authorities. For 157 example, "10.1045" is a child naming authority of "10" for the D- 158 Lib Magazine. 160 By default, handles are case sensitive. However, a handle service, 161 global or local, may implement its namespace so that ASCII 162 characters under the namespace are treated as case insensitive. For 163 example, the global handle service, formally known as the Global 164 Handle Registry (GHR), is implemented such that ASCII characters 165 are treated as case insensitive. Since the GHR manages all handles 166 for naming authorities, ASCII characters in naming authorities are 167 treated as case insensitive. 169 3. Handle System Data Model 171 The Handle System provides a name-to-value binding service over the 172 public Internet. Each handle may have a set of values assigned to 173 it. The Handle System maintains the value set of each handle and 174 will return it in response to any handle resolution request. The 175 handle system data model defines the conceptual data structure for 176 these values. The data model used by the protocol may not be the 177 exact physical data model used for storage in any specific 178 implementation. Rather, it is the data model followed by the handle 179 system protocol as specified in the "Handle System Protocol 180 Specification" [8]. 182 3.1 Handle Value Set 184 Each handle may have a set of values assigned to it. These handle 185 values use a common data structure for its data. For example, each 186 handle value has a unique index number that distinguishes it from 187 other values in the value set. It also has a specific data type 188 that defines the syntax and semantics of the data in its data 189 field. Besides these, each handle value contains a set of 190 administrative information such as TTL and permissions. Figure 3.1 191 shows the handle "10.1045/may99-payette" with a set of three handle 192 values. One of these values (with index number set to 1) is shown 193 in detail. (Note that the encoding of the length for each field is 194 not shown in Figure 3.1. Also, the empty field consists 195 of a 4-byte integer whose value is zero.) 196 Handle "10.1045/may99-payette" 198 | 199 | 200 V 202 ------------------------------------------------------------- 203 | : 3 | 204 ------------------------------------------------------------- | 205 | : 2 | | 206 ------------------------------------------------------------- | | 207 | | | | 208 | : 1 | | | 209 | : URL | | | 210 | : http://www.dlib.org/dlib... | | | 211 | : {Relative: 24 hours} | | | 212 | : PUBLIC_READ, ADMIN_WRITE | | | 213 | : 927314334000 | | | 214 | : {empty} | |- 215 | |- 216 ------------------------------------------------------------- 218 Figure 3.1: Handle "10.1045/may99-payette" and its set of values 220 In Figure 3.1, it shows a handle value whose its index is set to 1. 221 The data type for the handle value is URL. The URL data as stated 222 in the field is "http://www.dlib.org/dlib...". The TTL (time 223 to live) entry suggests that the value record should be cached no 224 more than 24 hours before the source of the information to be 225 consulted again. The field grants anyone permission to 226 read, but only the administrator to update the value. The 227 field is empty. It may contain a list of references to 228 other handle values as credentials for this handle value. 230 Thus a handle value may be thought of as a record that consists of 231 a group of data fields. Each of these data fields is defined as 232 follows: 234 235 An unsigned 32-bit integer that uniquely identifies a handle 236 value from other handle values. 238 239 A UTF8-string that identifies the data type for the value record. 240 Note that throughout this document, a UTF8-string is defined as a 241 data structure that consists of a 4-byte unsigned integer 242 followed by an UTF-8 encoded character string. The integer 243 specifies the number of octets in the character string. 245 The field identifies the data type that defines the syntax 246 and semantics of data in the next field. The data type may 247 be registered with the Handle System to avoid potential 248 conflicts. The Handle System has a reserved naming authority 249 "0.TYPE" for registered data types. For example, "URL" (as shown 250 in Figure 3.1) is a registered data type. It is registered as the 251 handle "0.TYPE/URL". The handle may have a value that explains 252 the syntax and semantics of the data type. 254 Data types under the Handle System may be hierarchical. Each 255 level of the hierarchy may be named in terms of a UTF8-String 256 with no '.' (0x2E) characters. The '.' character is used to mark 257 the boundary between hierarchy levels. For example, the handle 258 system data type "a.b" may be considered as a sub-type "b" under 259 the type "a". Similarly, handle values of "a.b.x", "a.b.y" 260 and "a.b.z" may be considered as handle values under the common 261 type hierarchy "a.b". 263 For any handle values, the UTF8-string in the field may 264 not end with the '.' character. In other words, no handle system 265 data type should end with the '.' character. However, the '.' 266 character may appear in the end of the parameter in a 267 handle query. This is used to query for all handle values under a 268 common type hierarchy. For example, one may query for all handle 269 values under the type hierarchy "a.b" (e.g. handle values of 270 "a.b.x", "a.b.y" and "a.b.z") by setting the 271 parameter to "a.b.". Note here that the parameter ends 272 with the '.' character. Details of the handle query operation can 273 be found in the handle system protocol specification [8]. 275 276 A sequence of octets (preceded by its length in a 4-byte unsigned 277 integer) that describes the resource identified by the handle. 278 The syntax and semantics of these octets are identified by the 279 field. 281 282 An eight-bit bit-mask for access control of the handle value. 283 Access control is defined in terms of read, write, and execute 284 permissions, applicable to either general public or handle 285 administrator(s). Each handle value can have its permission field 286 specified as any combination of the following bits: 288 PUBLIC_WRITE (0x01) permission that allows anyone to 289 modify or delete the handle value. 291 PUBLIC_READ (0x02) permission that allows anyone to read 292 the handle value. 294 ADMIN_WRITE (0x04) permission that allows any handle 295 administrator to update or delete the 296 handle value. 298 ADMIN_READ (0x08)_ permission that allows the handle 299 value to be read by any handle 300 administrator with AUTHORITIVE_READ 301 privilege. 303 PUBLIC_EXECUTE (0x10) permission that allows anyone to 304 execute the program identified by the 305 handle value on the handle host as 306 anonymous user. Because of the 307 security risks this may have brought 308 up, implementations may choose not to 309 support such permission, or provide 310 options so that it can be disabled at 311 deployment. 313 ADMIN_EXECUTE (0x20) permission that allows handle 314 administrator(s) to run the program 315 identified by the handle value on the 316 handle server. The handle server must 317 authenticate the handle administrator 318 before executing the program. The 319 handle administrator must have a 320 established account on the handle 321 server. The execution of the handle 322 value should assume the same 323 privilege as the one given to the 324 account for the handle administrator. 325 Because of the security risks this 326 may have brought up, implementations 327 may choose not to support such 328 permission, or provide options so 329 that it can be disabled at 330 deployment. 332 Note that a handle value with no PUBLIC_READ nor ADMIN_READ 333 permission can not leave the handle server. It may be used, for 334 example, to store secret keys for authentication purposes. A 335 handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission 336 makes the handle value immutable and cannot be deleted by any 337 handle administrator (via the handle system protocol). 339 The administrator for a given handle must specify the permission 340 for each handle value. Implementations may choose PUBLIC_READ and 341 ADMIN_WRITE as the default permission for each handle value. 343 Handle servers must check permissions before fulfilling any 344 client request. 346 347 An octet followed by a 4-byte integer that specifies the Time-To- 348 Live of the value record. It is used to describe how long the 349 value record can be cached before the source of the information 350 should again be consulted. A zero value for a TTL indicates that 351 the value record should only be used for the transaction in 352 progress and should not be cached. Any non-zero TTL is defined in 353 terms of a TTL type (specified in the first octet), followed by 354 the TTL value (the 32-bit unsigned integer that follows the TTL 355 type). The TTL type indicates whether the TTL value is absolute 356 or relative. The absolute TTL value defines the time to live in 357 terms of seconds since 00:00:00 UTC, January 1st 1970. A relative 358 TTL specifies the time to live in terms of the number of seconds 359 elapsed since the value was obtained by the client from any 360 handle server. 362 363 An 8-byte (long) integer that records the last time the value was 364 updated at the server. The field contains elapsed time since 365 00:00:00 UTC, January 1970 in milliseconds. The choice of 366 milliseconds is to avoid potential collision when updating the 367 value. 369 370 A 4-byte integer followed by a list of references to other handle 371 values. The integer specifies the number of references in the 372 list. Each reference in the list refers to another handle value 373 in terms of a UTF8-string and a 4-byte integer (where the UTF8- 374 string is the handle name and the integer is the value index). 375 References are generally used to add credentials to the current 376 handle value. For example, a handle value may make itself more 377 trust-worthy by referring to a digital signature issued by a 378 commonly trusted entity. 380 By default, the Handle System returns all the handle values with 381 public-read permission in response of any resolution request. It is 382 possible for a client to ask for a subset of those values with 383 specific data type (e.g. all URLs assigned to the handle). The 384 client may also ask for a specific handle value based on a specific 385 value index. 387 Each handle value can be uniquely referenced by the combination of 388 the handle and its value index. Care must be taken when changing 389 the value index as it may break an existing reference to the handle 390 value. For example, suppose the handle X/Y has a value whose index 391 is 1. That value may be referred to as X/Y:1. If the handle 392 administrator changes the value index from 1 to 2, the reference to 393 X/Y:1 will become obsolete. Any reference to the handle value will 394 have to change to X/Y:2. 396 Value records assigned to any handle may or may not have continuous 397 index numbers. Nor can it be assumed that the index will start with 398 0 or 1. A handle administrator may assign a handle value with any 399 index as long as each index is unique within the value set. 401 A handle value may be "privatized" or "disabled" by setting its 402 field as "authorized-read". This limits read-access to 403 the handle administrator only. The "privatized" value can then be 404 used to keep any historical data (on behalf of the handle 405 administrator) without exposing it to public. Such approach may 406 also be used to keep any obsolete handle or naming authority from 407 being reused accidentally. 409 3.2 Pre-defined Handle Data Types 411 Every handle value must have a data type specified in its 412 field. The Handle System provides a type registration service that 413 allows organizations to register new data types for their 414 applications. Data types can be registered as handles under the 415 naming authority "0.TYPE". For example, the URL data type is 416 registered under the Handle System as the handle "0.TYPE/URL". The 417 handle may have a handle value that refers to RFC1738 [9], an IETF 418 standard document that defines the syntax and semantics of URL. 420 The Handle System pre-defines a set of data types to carry out the 421 handle service. For example, HS_ADMIN is a pre-defined data type 422 used to describe handle administrators or administrator groups. 423 HS_SITE is a pre-defined data type to describe the service 424 interface of any handle system service component. The following 425 sections provide detailed descriptions of these pre-defined data 426 types under the Handle System. 428 3.2.1 Handle Administrator: HS_ADMIN 430 Each handle has one or more administrators. Any administrative 431 operation (e.g., add, delete or modify handle values) can only be 432 performed by the handle administrator with adequate privilege. 433 Handle administrators are defined in terms of HS_ADMIN values. 434 Every handle must have at least one HS_ ADMIN value that defines 435 its administrator. Each HS_ADMIN value can be used to define a set 436 of handle administrators sharing the same administration privilege. 437 Handles with multiple administrators of different privileges may 438 have multiple HS_ADMIN values. HS_ADMIN values are used by the 439 Handle System to authenticate handle administrators before 440 fulfilling any handle administration request. 442 Naming authorities, as described above, are themselves registered 443 as handles under the reserved naming authority "0.NA". These 444 handles are referred to as naming authority handles. Administrators 445 for any naming authority are so defined as the administrators of 446 the corresponding naming authority handle. For example, "0.NA/10" 447 is the naming authority handle for the naming authority "10". Hence 448 any administrator for the naming authority handle "0.NA/10" is also 449 the administrator for the naming authority "10". Naming authority 450 administrators are the only ones who can create handles or sub- 451 naming authorities under the naming authority. A sub-naming 452 authority may define its own set of administrators to create 453 handles or further levels of sub-naming authorities. For example, 454 the naming authority "10.1045" may have a totally different group 455 of administrators from its parent naming authority "10". 457 A HS_ADMIN value is a handle value whose field is HS_ADMIN 458 and whose field consists of the following entries: 460 461 A reference to a handle value. The reference consists of the 462 handle name (a UTF8-string) followed by a 4-byte unsigned integer 463 for the handle value index. The handle value identifies the set 464 of administrators for the handle. 466 467 A 16-bit bit-mask that defines the administration privilege of 468 the set of handle administrators identified by the HS_ADMIN 469 value. 471 The entry refers to a handle value that can be used to 472 authenticate the handle administrator. Such handle value is called 473 the handle administrator reference. The handle administrator 474 reference may contain the secret key, public key, or X.509 475 certificate [10] provided by the handle administrator. For example, 476 the entry may contain a handle administrator reference 477 whose field is DSS_WITH_DES_CBC_SHA and whose field 478 contains a DES secret key [11], for use in the Cipher Block 479 Chaining (CBC) mode of operation [12, 13]. The secret key can be 480 used by the handle server to authenticate the handle administrator. 481 For stronger cryptographic algorithm, the handle administrator 482 reference may contain a set of Triple-DES keys [23] and set its 483 to be DES-EDE3-WITH-CBC. 485 A single handle may be assigned with both the HS_ADMIN value and 486 the handle administrator reference. In other words, the 487 entry may refer to a handle value assigned to the same handle that 488 has the HS_ADMIN value. In this case, authentication of the handle 489 administrator does not rely on any other handles. Alternatively, 490 the handle administrator reference may be a handle value under a 491 different handle. Thus HS_ADMIN values from different handles may 492 share a common handle administrator reference. This feature allows 493 sharing of handle administrators among different handles. The 494 handle administrator reference contains the secret key, public key, 495 or X.509 certificate provided by the administrator of these 496 handles. 498 Handle administrator reference may be of type HS_VLIST and has its 499 field contain a list of references to other handle values. 500 Each of these handle values defines a handle administrator 501 reference. The HS_VLIST value defines an administrator group. Each 502 handle administrator reference from the HS_VLIST is a member of the 503 administrator group. Each handle value reference is defined in 504 terms of a : pair. An administrator group may also 505 contain other administrator groups as its members. This allows 506 administrator groups to be defined in a hierarchical fashion. Care 507 must be taken, however, to avoid cyclic definition of 508 administrators or administrator groups. Multiple levels of 509 administrator groups should be avoided due to their lack of 510 efficiency, but will not be signaled as an error. Client software 511 should be prepared to detect any potential cyclic definition of 512 administrators or entries that point to non-existent 513 handle values and treat them as an error. 515 A handle can have multiple HS_ADMIN values, each of which defines a 516 different handle administrator. Different administrators can play 517 different roles or be granted different permissions. For example, 518 the naming authority handle "0.NA/10" may have two administrators, 519 one of which may only have permission to create new handles under 520 the naming authority, while the other may have permission to create 521 new sub-naming authorities (e.g. "10.1045"). The set of possible 522 permissions for a handle administrator is defined as follows: 524 Add_Handle (0x0001) 525 This permission allows naming authority administrator to create 526 new handles under a given naming authority. 528 Delete_Handle (0x0002) 529 This permission allows naming authority administrator to delete 530 handles under a given naming authority. 532 Add_NA (0x0004) 533 This permission allows the naming authority administrator to 534 create new sub-naming authorities. 536 Delete_NA (0x0008) 537 This permission allows naming authority administrator to delete 538 an existing sub-naming authority. 540 Modify_Value (0x0010) 541 This permission allows handle administrator to modify any handle 542 values other than HS_ADMIN values. HS_ADMIN values are used to 543 define handle administrators and are managed by a different set 544 of permissions. 546 Delete_Value (0x0020) 547 This permission allows handle administrator to delete any handle 548 value other than the HS_ADMIN values. 550 Add_Value (0x0040) 551 This permission allows handle administrator to add handle values 552 other than the HS_ADMIN values. 554 Modify_Admin (0x0080) 555 This permission allows handle administrator to modify HS_ADMIN 556 values. 558 Remove_Admin (0x0100) 559 This permission allows handle administrator to remove HS_ADMIN 560 values. 562 Add_Admin (0x0200) 563 This permission allows handle administrator to add new HS_ADMIN 564 values. 566 Authorized_Read (0x0400) 567 This permission grants handle administrator read-access to handle 568 values with the ADMIN_READ permission. Administrators without 569 this permission will not have access to handle values that 570 require authentication for read access. 572 LIST_Handle (0x0800) 573 This permission allows naming authority administrator to list 574 handles under a given naming authority. 576 LIST_NA (0x1000) 577 This permission allows naming authority administrator to list 578 immediate sub-naming authorities under a given naming authority. 580 Administrator permissions are encoded in the 581 entry in the field of any HS_ADMIN value. Each permission is 582 encoded as a bit flag. The permission is granted if the flag is set 583 to 1, otherwise it is set to 0. 585 Figure 3.2.1 shows an example of HS_ADMIN value that defines an 586 administrator for the naming authority handle "0.NA/10". In figure 587 3.2.1, a naming authority administrator is identified by an 588 HS_ADMIN value assigned to the naming authority handle "0.NA/10". 589 The administrator can be authenticated based on the handle value 590 "0.NA/10":3, which is the handle value assigned to the naming 591 authority handle "0.NA/10" and has its index set to 3. The handle 592 value "0.NA/10":3 may contain the secret or public key used by the 593 administrator. The administrator is granted permission to add, 594 delete, or modify sub-naming authorities under "10", and add or 595 delete handles directly under the naming authority. The 596 administrator may also add, delete, or modify any handle values 597 assigned to the naming authority handle except those HS_ADMIN 598 values. In other words, the administrator is not allowed to add, 599 delete, or modify any administrators for the naming authority. 601 ------------------------------------------------------------- 602 ------------------------------------------------------------- | 603 ------------------------------------------------------------- | | 604 | | | | 605 | : 2 | | | 606 | : HS_ADMIN | | | 607 | : | | | 608 | : "0.NA/10": 3 | | | 609 | : Add_NA, Delete_NA, | | | 610 | Add Handle, Delete_Handle, | | | 611 | Add_Value, Delete_Value, Modify_Value, | | | 612 | Authorized_Read, List_Handle, List_NA | | | 613 | | | | 614 | : 24 hours | | | 615 | : PUBLIC_READ, ADMIN_WRITE | | | 616 | : {empty} | |- 617 | |- 618 ------------------------------------------------------------- 620 Figure 3.2.1: Administrator for the naming authority 621 handle "0.NA/10" 623 HS_ADMIN values are used by handle servers to authenticate the 624 handle administrator before fulfilling any administrative requests. 625 The server authenticates a client by checking whether the client 626 has possession of the secret key (or the private key) that matches 627 the one in any of the handle administrator references. The 628 authentication is carried out via the handle system authentication 629 protocol as described later in this document. 631 HS_ADMIN values may require authentication for read access in order 632 to prevent public exposure of the data. Additionally, the handle 633 administrator reference that contains the administrator's secret 634 key should have neither PUBLIC_READ nor ADMIN_READ permission to 635 prevent the key from leaving the server. 637 3.2.2 Service Site Information: HS_SITE 639 The Handle System consists of a single distributed global handle 640 service, also known as the Global Handle Registry (GHR), and 641 unlimited number of Local Handle Services (LHSs). Each handle 642 service, global or local, may be replicated into multiple service 643 sites. Each service site may consist of multiple server computers. 644 Service requests targeted at any handle service can be distributed 645 into different service sites, and into different server computers 646 within any service site. Such architecture assures that each handle 647 service could have the capacity to manage any large number of 648 handles and handle requests. It also provides ways for each handle 649 service to avoid any single point of failure. 651 Each handle service, global or local, may provide the same set of 652 functions for resolving and administering its collection of 653 handles. Handle services differ primarily in that each service is 654 responsible for a distinct set of handles. They are also likely to 655 differ in the selection, number, and configuration of their 656 components such as the servers used to provide handle resolution 657 and administration. Different handle services may be created and 658 managed by different organizations. Each of them may have their own 659 goals and policies. 661 A service site typically consists of a cluster of server computers 662 residing within a local Internet domain. These computers work 663 together to distribute the data storage and processing load at the 664 site. It is possible, although not recommended, to compose a site 665 from servers at widely different locations. Further, it is even 666 possible to compose two different sites from the same set of 667 servers. 669 Each service site is defined by an HS_SITE value. HS_SITE is a pre- 670 defined handle system data type. An HS_SITE value defines a service 671 site by identifying the server computers (e.g., IP addresses) that 672 comprise the site along with their service configurations (e.g., 673 port numbers). HS_SITE values are typically assigned to naming 674 authority handles. The set of HS_SITE values assigned to a naming 675 authority handle is called the service information for the naming 676 authority. 678 The service information is managed by the naming authority 679 administrator. It must reflect the configuration of the handle 680 service for the naming authority. Note that an additional layer of 681 indirection, called a service handle, can be used to allow multiple 682 naming authorities to reference a single set of HS_SITE values, as 683 described later in this document (see section 3.2.3). Clients of 684 the Handle System depend on the service information to locate the 685 responsible handle server before they can send their service 686 requests. The service information can also be used by clients to 687 authenticate any service response from the handle server. 689 An HS_SITE value is a handle value whose field is HS_SITE 690 and whose field consists of the following entries: 692 693 A 2-byte value that identifies the version number of the HS_SITE. 694 The version number identifies the data format used by the HS_SITE 695 value. It is defined to allow backward compatibility over time. 696 This document defines the HS_SITE with version number 0. 698 699 A 2-byte integer value that identifies the handle protocol 700 version. The higher byte of the value identifies the major 701 version and the lower byte the minor version. Details of the 702 handle system protocol is specified in [8]. 704 705 A 2-byte integer value that increases by 1 (and may wrap around 706 through 0) each time the HS_SITE value gets changed. It is used 707 in the handle system protocol to synchronize the HS_SITE values 708 between client and server. 710 711 An 8-bit mask that identifies the primary site(s) of the handle 712 service. The first bit of the octet is the bit. It 713 indicates whether the handle service has multiple primary sites. 714 The second bit of the octet is the bit. It 715 indicates whether the HS_SITE value is a primary site. A primary 716 site is the one that supports administrative operations for its 717 handles. A entry with zero value indicates that 718 the handle service has a single primary site and all handle 719 administration has to be done at that site. A non-zero 720 entry indicates that the handle service has 721 multiple primary sites. Each primary site may be used to 722 administrate handles managed under the handle service. Handles 723 managed by such service may identify its primary sites using an 724 HS_PRIMARY value, as described in section 3.2.5. 726 727 An 8-bit octet that identifies the hash option used by the 728 service site to distribute handles among its servers. Valid 729 options include HASH_BY_NA (0x00), HASH_BY_LOCAL (0x01), or 730 HASH_BY_HANDLE (0x02). These options indicate whether the hash 731 operation should only be applied to the naming authority portion 732 of the handle, or only the local name portion of the handle, or 733 the entire handle, respectively. The standard MD5 hashing 734 algorithm [14] is used by each service site to distribute handles 735 among its servers. 737 738 An UTF8-string entry reserved for future use. 740 741 A 4-byte integer followed by a list of UTF8-string pairs. The 742 integer indicates the number of UTF8-string pairs that follow. 743 Each UTF8-string pair is an : pair. They are 744 used to add literal explanations of the service site. For 745 example, if the is "Organization", the should 746 contain a description of the organization hosting the service 747 site. Other s may be defined to help distinguish the 748 service sites from each other. 750 751 A 4-byte integer that defines the number of servers in the 752 service site. The entry is followed by a list of s. 753 Each defines a handle server that is part of the 754 service site. Each consists of the following data 755 fields: 757 ::= 758
759 760 762 where each field is defined as follows: 764 765 A 4-byte unsigned integer that uniquely identifies a server 766 process under the service site. s do not have to 767 begin with 1 and they don't have be consecutive numbers. They 768 are used to distinguish servers under a service site from 769 each other. Note that there can be multiple servers residing 770 on any given computer, each with a different . 772
773 The 16-byte IPv6 [15, 16] address of the handle server. Any 774 IPv4 address should be presented as :::::FFFF:xxxx:xxxx 775 (where xxxx:xxxx can be any 4-byte IPv4 address). 777 778 A 4-byte integer followed by a byte-array that contains the 779 server's public key. The integer specifies the size of the 780 byte-array. The byte-array (for the publickey) consists of 781 three parts: a UTF8-string that describes the key type, a 782 two-byte option field reserved for future use, and a byte- 783 array that contains the public key itself. For example, the 784 UTF8-String "DSA_PUB_KEY" indicates that the 785 contains a DSA public key. The storage 786 format of the DSA key in the byte-array could then be found 787 from the handle "0.type/DSA_PUB_KEY". Public key in the 788 can be used to authenticate any service 789 response from the handle server. 791 The may also contain a X.509 certificate. 792 This happens if the key type field contains the UTF8-String 793 "CERT.X509". In this case, "CERT.X509" will map to the 794 handle "0.TYPE/CERT.X509". The handle may contain 795 information that describes the syntax and semantics of the 796 public key or its certificate. Additional key type may also 797 be registered (as handles under "0.TYPE") to further 798 distinguish different kind of X.509 certificates. For 799 example, "CERT.X509.DSA" may be used to denote X.509 800 certificates that contain DSA public keys. If the key type 801 field of a declares "CERT.X509.DSA", the 802 must contain a X.509 certificate with a 803 DSA public key in it." 805 ::= 806 * [ 807 808 ] 810 A 4-byte integer followed by an array of triplets consisting 811 of . The 4- 812 byte integer specifies the number of triplets. Each triplet 813 lists a service interface provided by the handle server. For 814 each triplet, the is an octet (as a bit mask) 815 that specifies whether the interface is for handle resolution 816 (0x01), handle administration (0x02), or both. The 817 is also an octet (as a bit mask) that 818 specifies the transmission protocol. Possible transmission 819 protocols include TCP (0x01), UDP (0x02), and HTTP (0x04). 820 The is a 4-byte unsigned integer that specifies 821 the port number used by the interface. The default port 822 number is 2641. 824 Figure 3.2.2 shows an example of handle service site in terms of a 825 HS_SITE value. The HS_SITE value is assigned to the naming 826 authority handle "0.NA/10". The indicates that it is 827 the only primary site of the handle service. The site consists of 828 three handle servers, as indicated in the . These 829 servers provide handle resolution and administration service for 830 every handle under the naming authority "10". The first server 831 record (ServerID 0) shows two service interfaces, one for handle 832 resolution and the other for handle administration. Each interface 833 has its own port. 835 Each server within a service site is responsible for a subset of 836 handles managed by the handle service. Clients can find the 837 responsible server by performing a common hash-operation. The hash- 838 operation will first convert all ASCII characters in the handle 839 into upper-case. It then applies the MD5 hashing upon the portion 840 of the converted handle string (according to the 841 entry). The result is a 16-byte integer. The absolute value of the 842 integer will be divided by the number of servers (specified in the 843 entry). The remainder is the sequence number 844 (starting with zero) of the listed in the HS_SITE 845 value. From the , clients can find the IP address of 846 the handle server for their handle requests. 848 ------------------------------------------------------------ 849 ------------------------------------------------------------ | 850 ----------------------------------------------------------- | | 851 | | | | 852 | : 2 | | | 853 | : HS_SITE | | | 854 | : | | | 855 | Version: 0 | | | 856 | ProtocolVersion: 2.1 | | | 857 | SerialNumber: 1 | | | 858 | PrimaryMask: | | | 859 | MultiPrimary: FALSE | | | 860 | PrimarySite: TRUE | | | 861 | HashOption: HASH_BY_HANDLE | | | 862 | HashFilter: {empty UTF8-String} | | | 863 | AttributeList: 0 {followed by no attributes} | | | 864 | NumOfServer: 3 | | | 865 | {followed by a list of } | | | 866 | | | | 867 | ----------------------------------------- | | | 868 | ------------------------------------------ | | | | 869 | ------------------------------------------ || | | | 870 | | ServerID: 1 ||| | | | 871 | | Address: :FFFF:132.151.1.155 ||| | | | 872 | | PublicKeyRecord: HS_DSAKEY, iQCuR2R... ||| | | | 873 | | ServiceInterface ||| | | | 874 | | ServiceType: Resolution_Only ||| | | | 875 | | TransmissionProtocol: TCP & UDP ||| | | | 876 | | PortNumber: 2641 ||| | | | 877 | | ||| | | | 878 | | ServiceType: Admin only ||| | | | 879 | | TransmissionProtocol: TCP || | | | 880 | | PortNumber: 2642 | | | | 881 | ------------------------------------------ | | | 882 | | | | 883 | : 24 hours | | | 884 | : PUBLIC_READ, ADMIN_WRITE | | | 885 | : {empty} | |- 886 | |- 887 ----------------------------------------------------------- 889 Fig. 3.2.2: The primary service site for the naming authority "10" 891 3.2.3 Naming Authority Delegation Service: HS_NA_DELEGATE 893 The HS_NA_DELEGATE is a pre-defined handle system data type. It has 894 the exact same format as the HS_SITE value. Like HS_SITE values, 895 HS_NA_DELEGATE values are used to describe service sites of a LHS. 896 HS_NA_DELEGATE values may be assigned to naming authority handles 897 to designate naming authority administration to a LHS. A naming 898 authority handle with a set of HS_NA_DELEGATE values indicates that 899 all child naming authorities of the naming authority are managed by 900 the LHS described by the HS_NA_DELEGATE values. 902 For example, suppose the naming authority "foo.bar" decides to have 903 its child naming authorities delegated to a LHS. To achieve this, 904 one may assign the naming authority handle "0.NA/foo.bar" with a 905 set of HS_NA_DELEGATE values that describes the LHS. The set of 906 HS_NA_DELEGATE values indicate that the service information of any 907 child naming authority of the "foo.bar", such as "foo.bar.baz", can 908 be found by querying the naming authority handle "0.NA/foo.bar.baz" 909 from the LHS. 911 3.2.4 Service Handle: HS_SERV 913 Any handle service, global or local, can be defined in terms of a 914 set of HS_SITE values. These HS_SITE values may be assigned 915 directly to the relevant naming authority handle, or an additional 916 level of indirection may be introduced through the use of service 917 handles. A service handle may be thought of as a name for a handle 918 service. It may be used to maintain the HS_SITE values for the 919 handle service and referenced from a naming authority handle via a 920 HS_SERV value. A HS_SERV value is a handle value whose field 921 is HS_SERV and whose field contains the reference to the 922 service handle. HS_SERV values are typically assigned to naming 923 authority handles to refer clients to the responsible handle 924 service. 926 Use of service handle allows sharing of service information among 927 multiple naming authorities. It also allows changes to service 928 configuration (e.g., adding a new site) to be made in one place 929 rather than in every naming authority handle involved. The 930 mechanism may also be used to support service referral from one 931 handle service to another for whatever reason. 933 A naming authority handle may have no more than one HS_SERV value 934 assigned to it, otherwise it is an error. If a naming authority 935 handle has both a list of HS_SITE values and an HS_SERV value, the 936 HS_SITE values should be used as the service information for the 937 naming authority. 939 Service handles can be registered under the reserved naming 940 authority "0.SERV". Handles under "0.SERV" are managed by the GHR. 941 For example, the service handle "0.SERV/123" may be created to 942 maintain the service information for the handle service that 943 manages handles under the naming authority "123" and any of its 944 sub-naming authorities. Similarly, a service handle "0.SERV/a.b.c" 945 may be created to host the service information for the handle 946 service that manages handles under the naming authority "a.b.c". 948 The use of service handles raises several special considerations. 949 Multiple levels of service handle redirection should be avoided due 950 to their lack of efficiency, but are not signaled as an error. 951 Looped reference of service handles or HS_SERV values that point to 952 non-existent service handles should be caught and error conditions 953 passed back to the user. 955 3.2.5 Alias Handle: HS_ALIAS 957 In practice, it is very possible that a digital object may have 958 multiple names that will identify the object. The Handle System 959 supports such feature via the pre-defined data type HS_ALIAS. A 960 HS_ALIAS value is a handle value whose field is HS_ALIAS and 961 whose field contains a reference to another handle. A handle 962 with a HS_ALIAS value is an alias handle to the handle referenced 963 in the HS_ALIAS value. A alias handle should not have any 964 additional handle values other than HS_ALIAS or HS_ADMIN (for 965 administration) values. This is necessary to prevent any 966 inconsistency between a handle and its aliases. 968 During a handle resolution, a client may get back an HS_ALIAS 969 value. This indicates that the handle in question is an alias 970 handle. The client may then retry the query against the handle 971 specified in the HS_ALIAS value until final results are obtained. 973 The use of alias handle introduces a number of special 974 considerations. For example, multiple levels of aliases should be 975 avoided for the sake of efficiency, but are not signaled as an 976 error. Alias loops and aliases that point to non-existent handles 977 should be caught and error conditions passed back to the user. 979 One potential use of alias handle would be to support the transfer 980 of ownership of any named resource. When a resource identified by a 981 handle transfers from one organization to another, a new handle for 982 the resource may be created. To avoid inconsistency and any broken 983 reference, the handle used before the ownership transfer may be 984 changed into an alias handle and has its HS_ALIAS value pointing to 985 the newly created handle. 987 3.2.6 Primary Site: HS_PRIMARY 989 HS_PRIMARY is a pre-defined data type used to designate the primary 990 service sites for any given handle. A handle service with multiple 991 primary service sites is called a multi-primary service. Otherwise 992 it is called a single-primary service. Each handle managed by a 993 multi-primary handle service may specify its primary service sites 994 in terms of a HS_PRIMARY value. A HS_PRIMARY value is a handle 995 value whose field is HS_PRIMARY and whose field 996 contains a list of references to HS_SITE values. Each of these 997 HS_SITE defines a primary service site for the handle. 999 There can be at most one HS_PRIMARY value assigned to each handle. 1000 Otherwise it is an error. A handle with no HS_PRIMARY value but 1001 managed by a multi-primary handle service is not an error. In this 1002 case, every primary service site of the handle service will also be 1003 the primary site for the handle. Handles managed by a single- 1004 primary handle service do not need any HS_PRIMARY values and any 1005 such values should be ignored. 1007 3.2.7 Handle Value List: HS_VLIST 1009 HS_VLIST is a pre-defined data type that allows a handle value to 1010 be used as a reference to a list of other handle values. An 1011 HS_VLIST value is a handle value whose is HS_VLIST and whose 1012 consists of a 4-byte unsigned integer followed by a list of 1013 references to other handle values. The integer specifies the number 1014 of references in the list. The references may refer to handle 1015 values under the same handle or handle values from any other 1016 handles. Each reference is encoded as an UTF8-string followed by a 1017 4-byte unsigned integer that identifies the referenced handle and 1018 its value index. 1020 HS_VLIST values may be used to define administrator groups for 1021 handles. In this case, each reference in the HS_VLIST defines a 1022 member of the administrator group and the HS_VLIST value identifies 1023 the group as a whole. Client software must be careful, however, to 1024 avoid cyclic definition of value references. 1026 4. Handle System Service Model 1027 The Handle System is a distributed global name service. It consists 1028 of a single distributed Global Handle Registry (GHR) and unlimited 1029 number of Local Handle Services (LHS). These service components 1030 provide the name service (both resolution and administration) on 1031 behalf of handle system client components. Handle system client 1032 components may also choose to use handle system middle-ware 1033 components (e.g., the handle system caching service) for 1034 efficiency. This section describes these components and their 1035 relationships to each other. 1037 4.1 Handle System Service Components 1039 The Handle System defines a hierarchical service model. At the top 1040 level is the single distributed global handle service, also known 1041 as the Global Handle Registry (GHR). Underneath the GHR, there can 1042 be any number of Local Handle Services (LHSs). Each LHS must be 1043 registered with the GHR to manage handles under a distinct set of 1044 naming authorities. Naming authorities are managed by the GHR via 1045 naming authority handles (i.e., handles under the naming authority 1046 "0.NA"). A naming authority handle can also be used to locate the 1047 service information (in terms of HS_SITE values) that describes the 1048 handle service responsible for handles under the naming authority. 1049 From the service information, clients can choose a service site and 1050 locate the responsible server for their handle requests. 1052 Handle system service components are scalable and extensible to 1053 accommodate any large amount of service load. A handle service, 1054 global or local, may consist of multiple service sites, replicating 1055 each other. Each service site may also consist of a cluster of 1056 computers working together to serve its respective namespace. 1057 Having multiple service sites avoids any single point of failure 1058 and allows load balancing among these service sites. Using multiple 1059 servers at any service site distributes the service load into 1060 multiple server processes and allows less powerful computers to be 1061 utilized for the name service. 1063 4.1.1 Global Handle Registry (GHR) 1065 The Global Handle Registry (GHR) is mainly used to manage naming 1066 authority handles and to provide service information for every 1067 naming authority under the Handle System. The GHR may also be used 1068 to manage and provide resolution and administration service to non- 1069 naming-authority handles. Unlike any LHS, which mostly manages 1070 handles under a few naming authorities, the GHR is primarily used 1071 to register naming authorities and provide service information for 1072 every LHS. In other words, the GHR is the single root service that 1073 registers every LHS and provides their service information via the 1074 use of naming authority handle(s). Every naming authority under the 1075 Handle System must be registered under the GHR as a naming 1076 authority handle. The naming authority handle provides the service 1077 information of the handle service that manages all the handles 1078 under the naming authority. The service information may be provided 1079 in terms of a set of HS_SITE values, or a HS_SERV value that refers 1080 to a service handle, as described earlier. 1082 The GHR may consist of multiple service sites, each described in a 1083 HS_SITE value. These HS_SITE values are assigned to the designated 1084 naming authority handle "0.NA/0.NA", also called the root handle. 1085 The root handle is the naming authority handle that maintains the 1086 service information for GHR. Top level naming authorities can only 1087 be created by administrators of the root handle. 1089 In order to communicate with the GHR, client software needs the GHR 1090 service information beforehand. The service information may be 1091 distributed initially with the client software, or obtained from 1092 some other secure sources (e.g., postal mail, secure web site, 1093 etc.). Client software may keep the service information to 1094 communicate with the GHR until the service information becomes 1095 expired (according to its TTL). The GHR must update its service 1096 information (assigned to the root handle) every time it changes its 1097 configuration. Client software with out-dated service information 1098 will be notified of the update every time it communicates with the 1099 GHR. The GHR must be maintained in such a way that any client 1100 software with out-dated GHR service information can still query the 1101 root handle for the latest update. 1103 Fig. 4.1.1 shows the GHR service information in terms of a set of 1104 HS_SITE values. The GHR may consist of a number of service sites, 1105 each described in a HS_SITE value. The figure shows a GHR service 1106 site located in US East Coast, as indicated in the . 1108 ------------------------------------------------------------ 1109 ------------------------------------------------------------ | 1110 ----------------------------------------------------------- | | 1111 | | | | 1112 | : 3 | | | 1113 | : HS_SITE | | | 1114 | : | | | 1115 | Version: 1 | | | 1116 | ProtocolVersion: 2.1 | | | 1117 | SerialNumber: 1 | | | 1118 | PrimaryMask: | | | 1119 | MultiPrimary: TRUE | | | 1120 | PrimarySite: TRUE | | | 1121 | HashOption: HASH_BY_HANDLE | | | 1122 | HashFilter: {empty UTF8-String} | | | 1123 | AttributeList: 1 | | | 1124 | Description: Service site at US East Coast | | | 1125 | NumOfServer: 3 | | | 1126 | | | | 1127 | ------------------------------------------ | | | 1128 | ------------------------------------------ | | | | 1129 | ------------------------------------------ || | | | 1130 | | ServerID: 1 ||| | | | 1131 | | Address: :FFFF:132.151.2.150 ||| | | | 1132 | | PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... ||| | | | 1133 | | ServiceInterface ||| | | | 1134 | | ServiceType: Resolution & Admin ||| | | | 1135 | | TransmissionProtocol: TCP & UDP || | | | 1136 | | PortNumber: 2641 | | | | 1137 | ------------------------------------------ | | | 1138 | | | | 1139 | : 24 hours | | | 1140 | : PUBLIC_READ, ADMIN_WRITE | | | 1141 | : {empty} | |- 1142 | |- 1143 ----------------------------------------------------------- 1145 Figure 4.1.1: GHR service information 1147 The GHR and its service information provide an entry point for any 1148 client software to communicate with the Handle System. For any 1149 given handle, client software can query the GHR for its naming 1150 authority handle. This will return the service information of the 1151 LHS that manages every handle under the naming authority. The 1152 service information will direct the client software to the handle 1153 server within the LHS that manages the handle. 1155 4.1.2 Local Handle Service (LHS) 1157 A Local Handle Services (LHS) manages handles under given sets of 1158 naming authorities. Each naming authority defines a "local" 1159 namespace that consists of all of the handles under the naming 1160 authority. Note that a LHS is not a "local" service in terms of any 1161 network topology. It is called a "Local" Handle Service because it 1162 typically manages a restricted (local) namespace. 1164 A naming authority is "homed" at a LHS if all handles under the 1165 naming authority are managed by the LHS. A LHS may be home to 1166 multiple naming authorities. On the other hand, a naming authority 1167 may only be "homed" at one LHS. Note that a naming authority may 1168 also be homed at the GHR. 1170 ------------------------------------------------------------ 1171 ------------------------------------------------------------ | 1172 ----------------------------------------------------------- | | 1173 | | | | 1174 | : 3 | | | 1175 | : HS_SITE | | | 1176 | : | | | 1177 | Version: 1 | | | 1178 | ProtocolVersion: 2.1 | | | 1179 | SerialNumber: 1 | | | 1180 | PrimaryMask: | | | 1181 | MultiPrimary: FALSE | | | 1182 | PrimarySite: TRUE | | | 1183 | HashOption: HASH_BY_LOCALNAME | | | 1184 | HashFilter: {empty UTF8-String} | | | 1185 | AttributeList: 1 | | | 1186 | Description: Local Service for "10" | | | 1187 | NumOfServer: 2 | | | 1188 | | | | 1189 | ----------------------------------------- | | | 1190 | ----------------------------------------- | | | | 1191 | | ServerID: 1 || | | | 1192 | | Address: :FFFF:132.151.3.150 || | | | 1193 | | PublicKeyRecord: HS_DSAKEY, iQCuR2R... || | | | 1194 | | ServiceInteface: || | | | 1195 | | ServiceType: Resolution & Admin || | | | 1196 | | TransmissionProtocol: TCP & UDP || | | | 1197 | | PortNumber: 2641 |' | | | 1198 | -----------------------------------------' | | | 1199 | | | | 1200 | : 24 hours | | | 1201 | : PUBLIC_READ, ADMIN_WRITE | |- 1202 | : {empty} |- 1203 ----------------------------------------------------------- 1205 Figure 4.1.2: LHS service information 1207 Like the GHR, a LHS may also consist of many service sites with 1208 each site described by an HS_SITE value. The set of HS_SITE values 1209 for any LHS may be assigned to a service handle or to the relevant 1210 naming authority handle(s). Fig. 4.1.2 shows an example of HS_SITE 1211 values for a LHS. These HS_SITE values are assigned to the naming 1212 authority handle "0.NA/10". This suggests that the naming authority 1213 "10" is "homed" at the LHS specified in these HS_SITE values. 1214 Clients may query the GHR to obtain the service information in 1215 order to communicate with the LHS. Administrators of the naming 1216 authority handle are responsible for maintaining the service 1217 information and keeping it up to date. 1219 Note that a LHS may refer its clients to another LHS in response to 1220 a service request. This allows the LHS to further distribute its 1221 service in a hierarchical fashion. 1223 4.2 Handle System Middle-Ware Components 1225 Handle system middle-ware components currently include handle 1226 system caching servers and handle system proxy servers. These 1227 handle system middle-ware components are clients to handle system 1228 service components, but servers to handle system client software. 1229 Handle system middle-ware components are used to provide additional 1230 interfaces to the basic handle service. For example, a handle 1231 system caching server may be used to share resolution results 1232 within a local community. Additionally, a handle system proxy 1233 server can be used to bypass any organizational firewall via HTTP 1234 tunneling. 1236 4.2.1 Handle System Caching Service 1238 Handle system caching service can be used to reduce the network 1239 traffic between handle system clients and servers. Caching handle 1240 data, including the service information of any LHS, allows re-use 1241 of information obtained from earlier queries. 1243 Each handle value contains a (Time to Live) field that tells 1244 a caching service how long the cached value may be regarded as 1245 valid. A zero-value TTL indicates that the value can only be used 1246 for the transaction in progress and should not be cached. A caching 1247 service may obtain its data directly from a handle service, or from 1248 another caching service that eventually gets its data from the 1249 handle service. 1251 A caching service may be defined in terms of an HS_SITE value and 1252 may consist of multiple caching servers. For any given handle, 1253 clients can find the responsible caching server within the caching 1254 service by using the same hashing algorithm as used in locating the 1255 handle server within any handle service. 1257 Caching services are not part of any handle system administration 1258 or authentication hierarchy. The handle system protocol does not 1259 authenticate any response from a caching service. Clients are 1260 responsible to set up their trust relationship with the caching 1261 service that they select. They will also rely on the caching 1262 service to properly authenticate any response from any handle 1263 server. 1265 4.2.2 Handle System Proxy Server 1267 Handle system proxy servers can be used to enable handle resolution 1268 via other Internet protocols. For example, CNRI has built and made 1269 available a Handle System HTTP Proxy Server that will process any 1270 handle resolution in terms of HTTP protocol. The current DNS 1271 address for the proxy server is at "hdl.handle.net". The proxy 1272 server allows any handle to be resolved via a HTTP URL. The URL can 1273 be constructed as "http://hdl.handle.net/", where 1274 can be any handle from the Handle System. For example, the handle 1275 "ncstrl.vatech_cs/tr-93-35" can be resolved via the HTTP URL 1276 "http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35" from any web 1277 browser. In this case, the URL is sent to the proxy server in terms 1278 of a HTTP request. The proxy server will query the Handle System 1279 for the handle data and return the results in terms of HTTP 1280 response. 1282 Using HTTP URLs allows handles to be resolved from standard web 1283 browsers without any additional client software. However, such 1284 reference to the handle also ties itself to the proxy server. If 1285 the proxy server changes its DNS name or otherwise becomes invalid, 1286 the reference (i.e. the HTTP URL) to the handle will break. Thus 1287 the selection or use of proxy server should be carefully evaluated. 1289 Proxy servers are not part of any handle system administration or 1290 authentication hierarchy. The handle system protocol does not 1291 authenticate any response from a proxy server. Clients are 1292 responsible to set up their trust relationship with the proxy 1293 server that they select. They will also rely on the proxy server to 1294 properly authenticate any response from any handle server. 1296 4.3 Handle System Client Components 1298 Handle system client components are client software that 1299 communicates with the handle system service components. Client 1300 software may speak the handle system protocol and send its request 1301 directly to a service component. The response from the service 1302 component may be the final answer to the request, or a referral to 1303 another service component. The client software will have to follow 1304 the referral in order to complete the transaction. 1306 Client software may also be configured to tunnel its request via a 1307 middle-ware component. The middle-ware component will thus be 1308 responsible for obtaining the final result and returning it to the 1309 client. Unlike service components, middle-ware components will only 1310 return final results of client's request. No service referral will 1311 be returned from middle-ware components. 1313 Various handle system client components may be developed for 1314 various applications. The CNRI Handle System Resolver [17] is one 1315 such component. The resolver extends web browsers (e.g. Netscape or 1316 Microsoft Internet Explorer) in such a way that handles can be 1317 resolved directly in terms of "hdl:" Uniform Resource Identifiers 1318 (URIs). The Grail web browser [18], a freely downloadable software 1319 developed in Python [19], also supports the "hdl:" URI scheme and 1320 will resolve handles accordingly. For example, the handle 1321 "10.1045/july95-arms" may be resolved by entering its handle URI as 1322 "hdl:10.1045/july95-arms" into any of these resolver-enabled 1323 browsers. Details of the handle URI syntax will be specified in a 1324 separate document. 1326 5. Handle System Operation Model 1328 Handle System operations can be categorized into resolution and 1329 administration. Clients use the handle resolution service to query 1330 for any handle values. Handle administration allows clients to 1331 manage handles, including adding and deleting handles, and updating 1332 their values. It also deals with naming authority administration 1333 via naming authority handles. This section explains how various 1334 handle system components work together to accomplish these service 1335 operations. 1337 Both resolution and administration may require authentication of 1338 the client. The authentication can be done via the handle system 1339 authentication protocol described later in this section. Whether 1340 authentication is required or not depends on the kind of operation 1341 involved and the permissions assigned to the relevant handle value, 1342 and policies deployed by the relevant service components. 1344 The handle system protocol specifies the syntax and semantics of 1345 each message exchanged between handle system clients and its server 1346 components. This section provides a high level overview of the 1347 protocol used to accomplish any service operation. The exact 1348 programmatic detail of each message (i.e. their byte layout or 1349 syntax) is specified in a separate document [8]. 1351 5.1 Handle System Service Request and Response 1353 The Handle System provides its service in response to client 1354 requests. A client may send a request to any handle server to 1355 provoke a response. The response either provides an answer to the 1356 request, or a status code with associated information that either 1357 refers the request to another service component, asks for client 1358 authentication, or signals some error status. 1360 Each handle under the Handle System is managed by its home service. 1361 The naming authority handle provides the service information (in 1362 terms of HS_SERV or HS_SITE values) of the handle service that 1363 manages all handles under the naming authority. Any handle request 1364 must be directed to the home service of the handle in question. 1365 Clients may find the home service by querying the corresponding 1366 naming authority handle against the GHR. Alternatively, this 1367 information may be found in a local cache or even be part of a 1368 local client configuration. Given the service information, clients 1369 may select a service site and locate the responsible handle server 1370 within the site. 1372 To resolve the handle "ncstrl.vatech_cs/te-93-35", for example, 1373 client software needs to know the home service for the naming 1374 authority "ncstrl.vatech_cs". The home service can be obtained by 1375 querying the naming authority handle "0.NA/ncstrl.vatech_cs" 1376 against the GHR. The GHR will return the service information in 1377 terms of the HS_SITE values assigned to the naming authority 1378 handle. From the service information, clients can pick a service 1379 site, find the responsible handle server within the site, and send 1380 the resolution request to the handle server. 1382 Clients may require digital signatures from a handle server in 1383 order to authenticate any response from the server. The signature 1384 can be generated using the server's private key. Clients may verify 1385 the signature using the public key available from the service 1386 information (refer to the entry discussed in 1387 3.2.2). 1389 A communication session may also be established between any client 1390 and handle server. Each session is identified by a unique session 1391 ID managed by the server. A session may be used to manage requests 1392 that require multiple interactions. It may also be used to share 1393 any TCP connection or authentication information among multiple 1394 service transactions. Each session may establish a session key and 1395 use it to authenticate any message exchanged within the session. It 1396 may also be used to encrypt any message between the client and the 1397 server to achieve data confidentiality. 1399 The following diagram shows a handle resolution process in terms of 1400 messages exchanged between client software and handle system 1401 service components. In this case, the client is trying to resolve 1402 the handle "ncstrl.vatech_cs/tr-93-35". It assumes that the client 1403 has yet obtained the service information of the LHS "homed" by the 1404 naming authority "ncstrl.vatech.cs". The client has to get the 1405 service information from the naming authority handle managed by the 1406 GHR. The service information allows the client to locate the 1407 responsible LHS and query for the handle value. 1409 [HS Client] ----------------------------> [Global Handle Registry] 1410 1. ask for the service 1411 information from the 1412 naming authority handle 1413 "0.NA/ncstrl.vatech_cs" 1415 [HS Client] <---------------------------- [Global Handle Registry] 1416 2. service information for 1417 the naming authority 1418 "ncstrl.vatech_cs" 1420 [HS Client] ----------------------------> [Local Handle Service] 1421 3. query the handle 1422 "ncstrl.vatech_cs/tr-93-35" 1423 against the responsible 1424 handle server 1426 ... ... 1428 (optional client authentication, depending on the service request) 1430 ... ... 1432 [HS Client] <---------------------------- [Local Handle Service] 1433 4. query result from the handle 1434 server + (optional) server 1435 signature 1437 Figure 5.1: Handle resolution example 1439 In Figure 5.1, the client is configured to communicate with the GHR 1440 for any handle service. In this case, the client first queries the 1441 GHR to find the home service for the handle's naming authority. The 1442 GHR returns the service information of the LHS that manages every 1443 handle under the naming authority. From the service information, 1444 the client can find the responsible handle server and query the 1445 server for the handle. The server may set up a session to 1446 authenticate the client if any of the handle value requires 1447 authentication. Otherwise, the server will simply return the handle 1448 value to the client. The server may send a digital signature as 1449 part of its response if required by the client. 1451 The above procedure assumes that the client software already has 1452 the GHR service information. That information was likely obtained 1453 from the client software distribution. The GHR will notify the 1454 client software if it learns that the service information used by 1455 the client software is out of date. Client software may retrieve 1456 the latest service information from the root handle "0.NA/0.NA". 1457 The root handle also maintains the public key that may be used to 1458 authenticate the service information. 1460 Note that a client may cache the service information of any naming 1461 authority so that subsequent queries for handles under the same 1462 naming authority may reuse the service information and bypass the 1463 first two steps shown in Figure 5.1. Client software may also be 1464 configured to query a caching or proxy server directly for any 1465 handle. In this case, the caching or proxy server will act as the 1467 [HS Client] in Figure 5.1 before returning the query result to the 1468 client. 1470 Client software under certain organization may also elect to bypass 1471 the GHR and communicate directly with a LHS managed by the 1472 organization. Doing so may achieve quicker response for handles 1473 managed under the LHS. The client software will be referred to the 1474 GHR for handles not managed by the LHS. 1476 5.2 Handle System Authentication Protocol 1478 The Handle System supports handle administration over the public 1479 Internet. Access controls can be defined on each handle value. The 1480 handle system authentication protocol is the protocol used by any 1481 handle server to authenticate handle administrator upon any 1482 administration request. The authentication is also necessary when 1483 clients query for handle values that are read-only by the handle 1484 administrator. Handle administration include adding, deleting or 1485 modifying handle values, and adding or deleting handles. Naming 1486 authority administrations are carried out as handle administrations 1487 over the corresponding naming authority handles. 1489 The handle system authentication protocol does not perform any 1490 server authentication. However, a client may authenticate any 1491 server response by asking the server to sign its response with 1492 digital signature. 1494 By default, the Handle System authenticates clients via a 1495 challenge-response protocol. That is, after receiving a client's 1496 request, the server issues a challenge to the client if 1497 authentication is necessary. To be authenticated as the 1498 administrator, the client has to return a challenge-response, a 1499 message that demonstrates procession of the administrator's secret. 1500 The secret may be the private key or the secret key of the 1501 administrator. This challenge-response allows the server to 1502 authenticate the client as the handle administrator. Upon 1503 successful authentication, the server will fulfill the client's 1504 request if the administrator is given sufficient permission. 1506 For example, suppose a client sends a request to the handle server 1507 to add a new handle value. The server will issue a challenge to the 1508 client in order to authenticate the client as one of the handle 1509 administrators. If the client possesses the private key of the 1510 administrator, she can use it to sign the server's challenge and 1511 return the signature as part of her challenge-response. The server 1512 will validate the signature in order to authenticate the client. 1513 The client will be notified if the validation fails. Otherwise, the 1514 server will further check if the administrator has the permission 1515 to add the handle value. If so, the server will add the handle 1516 value and report success to the client. Otherwise, a permission- 1517 denied message will be returned. 1519 The following diagram shows a typical authentication process in 1520 terms of the messages exchanged between the client and the handle 1521 server. 1523 [Client] --------------------------------> [Handle Server] 1524 1. client request 1525 + (optional) client credential 1527 [Client] <-------------------------------- [Handle Server] 1528 2. server's challenge to client 1529 + (i.e., nonce + MD5 of client request) 1531 [Client] -------------------------------> [Handle Server] 1532 3. reference to handle administrator 1533 + challenge-response from client 1535 [Client] <------------------------------- [Handle Server] 1536 4. server acknowledgement 1538 Figure 5.2: Handle system authentication process 1540 In Figure 5.2, the client sends an administration request to the 1541 handle server (along with optional credential discussed later). The 1542 server decides that client authentication is required and issues a 1543 challenge to the client. The client identifies itself as a handle 1544 administrator and returns the challenge-response to the server. The 1545 server authenticates the client as the administrator based on the 1546 challenge-response. It also checks to see if the administrator is 1547 authorized for the administration request. If so, the server will 1548 fulfill the request and acknowledge the client. 1550 Handle servers must authenticate the client before fulfilling any 1551 request that requires administrator privilege. The exact 1552 authentication process varies depending on whether public key or 1553 secret key is used by the administrator. It also depends on whether 1554 the handle used to store the administrator's key is managed by the 1555 same handle server or not. 1557 When public key is used, the challenge-response from the client 1558 contains its digital signature over the server's challenge. The 1559 server can authenticate the client by verifying the digital 1560 signature based on the administrator's public key. If secret key is 1561 used, the challenge-response from the client carries the Message 1562 Authenticate Code (MAC) generated using the secret key. The server 1563 may authenticate the client by generating the same MAC using the 1564 administrator's secret key and comparing it against the challenge- 1565 response. 1567 The reference to handle administrator in Fig 5.2 is also called a 1568 key-reference. It refers to a handle value that contains the key 1569 used by the administrator. If the key-reference is managed by the 1570 same handle server (e.g., a handle value assigned to the same 1571 handle), the server may use the key directly to do the 1572 authentication. If the key-reference is managed by some other 1573 handle server (whether or not within the same handle service), the 1574 server will have to send a verification-request to this other 1575 handle server, call it the key-server, in order to authenticate the 1576 client. The verification-request to the key-server carries both the 1577 server's challenge and the client's challenge-response. The key- 1578 server will return a verification-response, signed using the key- 1579 server's private key. The content of the verification-response will 1580 depend on the handle value referenced by the key-reference. If the 1581 key-reference refers to a public key used by the administrator, the 1582 verification-response will contain the public key of the 1583 administrator. Otherwise, the key-server will verify the challenge- 1584 response on behalf of the requesting server and return the result 1585 in the verification-response. The following diagram shows the 1586 control flow of the authentication process where the key-reference 1587 refers to a handle value that contains the administrator's public 1588 (or secret) key and the key-server is some other handle server. 1590 -------- ------------- 1591 | | 1. client request. | | 1592 | | -------------------------------> | | 1593 | | | | 1594 | | 2. session ID | | 1595 | | + server's challenge | | 1596 | Handle | <------------------------------- | Handle | 1597 | system | | server | 1598 | client | 3. session ID | receiving | 1599 | | + response to the challenge | client | 1600 | | + administrator reference | request | 1601 | | --------------------------------> | | 1602 | | | | 1603 | | 6. server acknowledgement | | 1604 | | <------------------------------- | | 1605 -------- ------------- 1606 | ^ 1607 4. Verification | | 5. verifi- 1608 request | | cation 1609 | | response 1610 | | (signed) 1611 V | 1612 -------------------------- 1614 | The handle server (the | 1615 | key-server) that manages | 1616 | the key referenced by | 1617 | the key-reference | 1618 -------------------------- 1620 Figure 5.3: Authentication process requiring verification 1621 from a second handle server 1623 Secret key based authentication via a second handle server, i.e., 1624 the key server, provides a convenient way to share a common secret 1625 key (e.g. pass phrase) among handles managed by different handle 1626 servers. However, it should not be used to manage highly sensitive 1627 handles or handle data. The authentication process itself is 1628 expensive and relies on a third party, i.e., the key-server, for 1629 proper operation. Additionally, the secret key itself is subject to 1630 dictionary attack since the key-server cannot determine whether the 1631 verification-request comes from a legitimate handle server. A 1632 handle service may set its local policy so that secret key based 1633 authentication can only be carried out if the handle server 1634 (receiving the client request) is also the key-server. 1636 Local handle services may define additional local policies for 1637 authentication and/or authorization. Handle system service 1638 components may also choose to use other Internet authentication 1639 mechanisms such as Kerberos [20] or some Transport Layer Security 1640 protocol [21]. Details of these will be addressed in a separate 1641 document. 1643 6. Security Considerations 1645 Handle System security considerations are discussed in the "Handle 1646 System Overview" [1] and that discussion applies equally to this 1647 document. 1649 The Handle System delegates handle administration to each handle 1650 administrator who may or may not be the server administrator. 1651 Handle administrators are allowed to choose their own public/secret 1652 keys used for authentication. The security of handle system 1653 authentication depends on the proper key selection and its 1654 maintenance by the handle administrator. Handle administrators must 1655 choose and protect their authentication keys carefully in order to 1656 protect the handle data. Handle server implementations may deploy 1657 policies that regulate the selection of public/secret keys used for 1658 authentication. For example, a handle server may require that any 1659 authentication key must be no less than certain number of bits. It 1660 may also prohibit the use of secret keys because of the potential 1661 dictionary attack. 1663 The handle system data model supports execution permission 1664 (PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value. While this 1665 allows better sharing of network resources, it also raises many 1666 security considerations. Execution privilege should be restricted 1667 within the permissions of certain user account (corresponding to 1668 the handle administrator) on the server to prevent system-wide 1669 disruption. Switching between computing platforms for the server 1670 should also be careful to avoid any unexpected behavior. 1671 Implementations may choose not to support the execution permission, 1672 or provide options so that it can be disabled. 1674 To protect against any irresponsible use of system resource, handle 1675 servers may implement quota control. The quota control can be used 1676 to put limits on the number of handles under a naming authority, 1677 the number of handle values allowed for any given handle, the 1678 maximum size of any handle value, and the number of sub-naming 1679 authorities under a naming authority. Handle servers must report 1680 error if the result of a handle administration violates any of 1681 these limits. 1683 References and Bibliography 1685 [1] S. Sun, L. Lannom, "Handle System Overview", IETF draft, work 1686 in progress. 1688 [2] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", 1689 RFC1034 1691 [3] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND 1692 SPECIFICATION", RFC1035 1694 [4] M. Wahl, T. Howes, and S. Kille, "Lightweight Directory Access 1695 Protocol (v3)", RFC 2251 1697 [5] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 1698 Specifications: ABNF", RFC 2234 1700 [6] F. Yergeau, "UTF-8, A Transform Format for Unicode and 1701 ISO10646", RFC2044 1703 [7] The Unicode Consortium, "The Unicode Standard, Version 2.0", 1704 Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9 1706 [8] S. Sun, S. Reilly, L. Lannom, "Handle System Protocol 1707 Specification", IETF draft, work in progress. 1709 [9] T. Berners-Lee, L. Masinter, M. McCahill, et al., "Uniform 1710 Resource Locators (URL)", RFC1738 1712 [10] R. Housley, W. Polk, W. Ford, D. Solo, "Internet X.509 Public 1713 Key Infrastructure - Certificate and Certificate Revocation List 1714 (CRL) Profile", RFC 3280 1716 [11] Federal Information Processing Standards Publication (FIPS 1717 PUB) 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 1718 (supersedes FIPS PUB 46, 1977 January 15). 1720 [12] Federal Information Processing Standards Publication (FIPS 1721 PUB) 81, DES Modes of Operation, 1980 December 2. 1723 [13] D. Balenson, "Privacy Enhancement for Internet Electronic 1724 Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, 1725 February 1993 1727 [14] R. Rivest, " The MD5 Message-Digest Algorithm", RFC 1321 1729 [15] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 1730 Specification", RFC 1883 1732 [16] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 1733 RFC2373 1735 [17] CNRI Handle System Resolver, http://www.handle.net/resolver 1737 [18] Grail browser home page, http://grail.cnri.reston.va.us/grail/ 1739 [19] Python language website, http://www.python.org/ 1741 [20] J. Kohl, and C. Neuman, "The Kerberos Network Authentication 1742 Service (V5)", RFC1510 1744 [21] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC2246 1746 [22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital 1747 Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html 1749 [23] American National Standards Institute. ANSI X9.52-1998, 1750 Triple Data Encryption Algorithm Modes of Operation. 1998. 1752 Author's Addresses 1754 Sam X. Sun 1755 Corporation for National Research Initiatives (CNRI) 1756 1895 Preston White Dr. Suite 100 1757 Reston, VA 20191 1758 Phone: 703-262-5316 1759 Email: ssun@cnri.reston.va.us 1760 Sean Reilly 1761 Corporation for National Research Initiatives (CNRI) 1762 1895 Preston White Dr. Suite 100 1763 Reston, VA 20191 1764 Phone: 703-620-8990 1765 Email: sreilly@cnri.reston.va.us 1767 Larry Lannom 1768 Corporation for National Research Initiatives (CNRI) 1769 1895 Preston White Dr. Suite 100 1770 Reston, VA 20191 1771 Phone: 703-620-8990 1772 Email: llannom@cnri.reston.va.us