diff options
Diffstat (limited to 'doc/rfc/rfc3651.txt')
| -rw-r--r-- | doc/rfc/rfc3651.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc3651.txt b/doc/rfc/rfc3651.txt new file mode 100644 index 0000000..af66793 --- /dev/null +++ b/doc/rfc/rfc3651.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group S. Sun +Request for Comments: 3651 S. Reilly +Category: Informational L. Lannom + CNRI + November 2003 + + + Handle System Namespace and Service Definition + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +IESG Note + + Several groups within the IETF and IRTF have discussed the Handle + System and it relationship to existing systems of identifiers. The + IESG wishes to point out that these discussions have not resulted in + IETF consensus on the described Handle System nor on how it might fit + into the IETF architecture for identifiers. Though there has been + discussion of handles as a form of URI, specifically as a URN, these + documents describe an alternate view of how namespaces and + identifiers might work on the Internet and include characterizations + of existing systems which may not match the IETF consensus view. + +Abstract + + The Handle System is a general-purpose global name service that + allows secured name resolution and administration over the public + Internet. This document provides a detailed description of the + Handle System namespace, and its data, service, and operation models. + The namespace definition specifies the handle syntax and its semantic + structure. The data model defines the data structures used by the + Handle System protocol and any pre-defined data types for carrying + out the handle service. The service model provides definitions of + various Handle System components and explains how they work together + over the network. Finally, the Handle System operation model + describes its service operation in terms of messages transmitted + between client and server, and the client authentication process + based on the Handle System authentication protocol. + + + + + +Sun, et al. Informational [Page 1] + +RFC 3651 Handle System Service Definition November 2003 + + +Table of Contents + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Handle System Namespace. . . . . . . . . . . . . . . . . . . . 3 + 3. Handle System Data Model . . . . . . . . . . . . . . . . . . . 4 + 3.1. Handle Value Set . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Pre-defined Handle Data Types. . . . . . . . . . . . . . 9 + 3.2.1. Handle Administrator: HS_ADMIN . . . . . . . . . 10 + 3.2.2. Service Site Information: HS_SITE. . . . . . . . 14 + 3.2.3. Naming Authority Delegation Service: + HS_NA_DELEGATE . . . . . . . . . . . . . . . . . 19 + 3.2.4. Service Handle: HS_SERV. . . . . . . . . . . . . 20 + 3.2.5. Alias Handle: HS_ALIAS . . . . . . . . . . . . . 21 + 3.2.6. Primary Site: HS_PRIMARY . . . . . . . . . . . . 21 + 3.2.7. Handle Value List: HS_VLIST. . . . . . . . . . . 22 + 4. Handle System Service Model. . . . . . . . . . . . . . . . . . 22 + 4.1. Handle System Service Components . . . . . . . . . . . . 23 + 4.1.1. Global Handle Registry (GHR) . . . . . . . . . . 23 + 4.1.2. Local Handle Service (LHS) . . . . . . . . . . . 26 + 4.2. Handle System Middle-Ware Components . . . . . . . . . . 27 + 4.2.1. Handle System Caching Service. . . . . . . . . . 27 + 4.2.2. Handle System Proxy Server . . . . . . . . . . . 28 + 4.3. Handle System Client Components. . . . . . . . . . . . . 28 + 5. Handle System Operation Model. . . . . . . . . . . . . . . . . 29 + 5.1. Handle System Service Request and Response . . . . . . . 30 + 5.2. Handle System Authentication Protocol. . . . . . . . . . 32 + 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 37 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 + 8. References and Bibliography. . . . . . . . . . . . . . . . . . 38 + 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40 + 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 41 + +1. Introduction + + The Handle System manages handles as globally unique names for + Internet resources. It was originally conceived and described in a + paper by Robert Kahn and Robert Wilensky [22] in 1995. The Handle + System provides a general-purpose global name service that allows + handles to be resolved and administrated securely over the public + Internet. The Handle System categorizes its service into two + categories: the handle resolution service and the handle + administration service. Clients use handle resolution service to + resolve handles into their values. The handle administration service + deals with client requests to manage these handles, including adding + and deleting handles, and updating handle values. + + The document "Handle System Overview" [1] provides an architectural + overview of the Handle System, and its relationship to other Internet + services such as DNS [2,3] and LDAP[4]. This document provides a + + + +Sun, et al. Informational [Page 2] + +RFC 3651 Handle System Service Definition November 2003 + + + detailed description of the Handle System namespace, its data and + service model, and its operation model. It assumes that readers are + familiar with the basic concepts of the Handle System as described in + the overview document. + + The namespace definition specifies the handle syntax and its semantic + structure. The data model defines the data structures used by the + Handle System protocol and any pre-defined data types for carrying + out the handle service. The service model provides definitions of + various Handle System components and explains how they work together + over the network. Finally, the Handle System operation model + describes its service operation in terms of messages transmitted + between client and server, and the client authentication process + based on the Handle System authentication protocol. + +2. Handle System Namespace + + Handles are character strings that may consist of a wide range of + characters. Every handle in the Handle System consists of two parts: + its naming authority, followed by a unique local name under the + naming authority. The naming authority and the local name are + separated by the ASCII character "/" (octet 0x2F). The following + table provides the handle syntax definition in ABNF [5] notation: + + <Handle> = <NamingAuthority> "/" <LocalName> + + <NamingAuthority> = *(<NamingAuthority> ".") <NAsegment> + + <NAsegment> = 1*(%x00-2D / %x30-3F / %x41-FF ) + ; any octets that map to UTF-8 encoded + ; Unicode 2.0 characters except + ; octets '0x2E' and '0x2F' (which + ; correspond to the ASCII characters '.', + ; and '/'). + + <LocalName> = *(%x00-FF) + ; any octets that map to UTF-8 encoded + ; Unicode 2.0 characters + + Table 2.1: Handle syntax + + As shown in Table 2.1, both <NamingAuthority> and <LocalName> are + UTF-8 [6] encoded character strings. The Handle System protocol + mandates UTF-8 encoding for handles transferred over the wire. The + <LocalName> may consist of any characters from the Unicode 2.0 + standard [7]. The <NamingAuthority> may use any characters from the + Unicode 2.0 standard except the ASCII character '/' (0x2F), which is + + + + +Sun, et al. Informational [Page 3] + +RFC 3651 Handle System Service Definition November 2003 + + + reserved to separate the <NamingAuthority> from the <LocalName>. A + <NamingAuthority> may consist of multiple non-empty <NAsegment>s, + each of which separated by the ASCII character '.' (octet 0x2E). + + Naming authorities are defined in a hierarchical fashion resembling a + tree structure. Each node and leaf of the tree is given a label that + corresponds to a naming authority segment (<NAsegment>). The parent + node represents the parent naming authority. Naming authorities are + constructed left to right, concatenating the labels from the root of + the tree to the node that represents the naming authority. Each + label (or its <NAsegment>) is separated by the character '.' (octet + 0x2E). For example, the naming authority for the Digital Object + Identifier (DOI) project is "10". It is a root-level naming + authority as it has no parent naming authority for itself. It can, + however, have many child naming authorities. For example, "10.1045" + is a child naming authority of "10" for the D-Lib Magazine. + + By default, handles are case sensitive. However, a handle service, + global or local, may implement its namespace so that ASCII characters + under the namespace are treated as case insensitive. For example, + the global handle service, formally known as the Global Handle + Registry (GHR), is implemented such that ASCII characters are treated + as case insensitive. Since the GHR manages all handles for naming + authorities, ASCII characters in naming authorities are treated as + case insensitive. + +3. Handle System Data Model + + The Handle System provides a name-to-value binding service over the + public Internet. Each handle may have a set of values assigned to + it. The Handle System maintains the value set of each handle and + will return it in response to any handle resolution request. The + Handle System data model defines the conceptual data structure for + these values. The data model used by the protocol may not be the + exact physical data model used for storage in any specific + implementation. Rather, it is the data model followed by the Handle + System protocol as specified in the "Handle System Protocol + Specification" [8]. + +3.1. Handle Value Set + + Each handle may have a set of values assigned to it. These handle + values use a common data structure for its data. For example, each + handle value has a unique index number that distinguishes it from + other values in the value set. It also has a specific data type that + defines the syntax and semantics of the data in its data field. + Besides these, each handle value contains a set of administrative + information such as TTL and permissions. Figure 3.1 shows the handle + + + +Sun, et al. Informational [Page 4] + +RFC 3651 Handle System Service Definition November 2003 + + + "10.1045/may99-payette" with a set of three handle values. One of + these values (with index number set to 1) is shown in detail. (Note + that the encoding of the length for each field is not shown in Figure + 3.1. Also, the empty <reference> field consists of a 4-byte integer + whose value is zero.) + + Handle "10.1045/may99-payette" + + | + | + V + + ------------------------------------------------------------- + | <index>: 3 | + ------------------------------------------------------------- | + | <index>: 2 | | + ------------------------------------------------------------- | | + | | | | + | <index>: 1 | | | + | <type>: URL | | | + | <data>: http://www.dlib.org/dlib... | | | + | <TTL>: {Relative: 24 hours} | | | + | <permission>: PUBLIC_READ, ADMIN_WRITE | | | + | <timestamp>: 927314334000 | | | + | <reference>: {empty} | |- + | |- + ------------------------------------------------------------- + + Figure 3.1: Handle "10.1045/may99-payette" and its set of values + + In Figure 3.1, it shows a handle value whose its index is set to 1. + The data type for the handle value is URL. The URL data as stated in + the <data> field is "http://www.dlib.org/dlib...". The TTL (time to + live) entry suggests that the value record should be cached no more + than 24 hours before the source of the information to be consulted + again. The <permission> field grants anyone permission to read, but + only the administrator to update the value. The <reference> field is + empty. It may contain a list of references to other handle values as + credentials for this handle value. + + Thus a handle value may be thought of as a record that consists of a + group of data fields. Each of these data fields is defined as + follows: + + <index> + An unsigned 32-bit integer that uniquely identifies a handle value + from other handle values. + + + + +Sun, et al. Informational [Page 5] + +RFC 3651 Handle System Service Definition November 2003 + + + <type> + A UTF8-string that identifies the data type for the value record. + Note that throughout this document, a UTF8-string is defined as a + data structure that consists of a 4-byte unsigned integer followed + by an UTF-8 encoded character string. The integer specifies the + number of octets in the character string. + + The <type> field identifies the data type that defines the syntax + and semantics of data in the next <data> field. The data type may + be registered with the Handle System to avoid potential conflicts. + The Handle System has a reserved naming authority "0.TYPE" for + registered data types. For example, "URL" (as shown in Figure + 3.1) is a registered data type. It is registered as the handle + "0.TYPE/URL". The handle may have a value that explains the + syntax and semantics of the data type. + + Data types under the Handle System may be hierarchical. Each + level of the hierarchy may be named in terms of a UTF8-String with + no '.' (0x2E) characters. The '.' character is used to mark the + boundary between hierarchy levels. For example, the Handle System + data type "a.b" may be considered as a sub-type "b" under the type + "a". Similarly, handle values of <type> "a.b.x", "a.b.y" and + "a.b.z" may be considered as handle values under the common type + hierarchy "a.b". + + For any handle values, the UTF8-string in the <type> field may not + end with the '.' character. In other words, no Handle System data + type should end with the '.' character. However, the '.' + character may appear in the end of the <type> parameter in a + handle query. This is used to query for all handle values under a + common type hierarchy. For example, one may query for all handle + values under the type hierarchy "a.b" (e.g., handle values of + <type> "a.b.x", "a.b.y" and "a.b.z") by setting the <type> + parameter to "a.b.". Note here that the <type> parameter ends + with the '.' character. Details of the handle query operation can + be found in the Handle System protocol specification [8]. + + <data> + A sequence of octets (preceded by its length in a 4-byte unsigned + integer) that describes the resource identified by the handle. The + syntax and semantics of these octets are identified by the <type> + field. + + <permission> + An eight-bit bit-mask for access control of the handle value. + Access control is defined in terms of read, write, and execute + + + + + +Sun, et al. Informational [Page 6] + +RFC 3651 Handle System Service Definition November 2003 + + + permissions, applicable to either general public or handle + administrator(s). Each handle value can have its permission field + specified as any combination of the following bits: + + PUBLIC_WRITE (0x01) permission that allows anyone to + modify or delete the handle value. + + PUBLIC_READ (0x02) permission that allows anyone to read + the handle value. + + ADMIN_WRITE (0x04) permission that allows any handle + administrator to update or delete the + handle value. + + ADMIN_READ (0x08)_ permission that allows the handle + value to be read by any handle + administrator with AUTHORITIVE_READ + privilege. + + PUBLIC_EXECUTE (0x10) permission that allows anyone to + execute the program identified by the + handle value on the handle host as + anonymous user. Because of the + security risks this may have brought + up, implementations may choose not to + support such permission, or provide + options so that it can be disabled at + deployment. + + ADMIN_EXECUTE (0x20) permission that allows handle + administrator(s) to run the program + identified by the handle value on the + handle server. The handle server must + authenticate the handle administrator + before executing the program. The + handle administrator must have an + established account on the handle + server. The execution of the handle + value should assume the same privilege + as the one given to the account for + the handle administrator. Because of + the security risks this may have + brought up, implementations may choose + not to support such permission, or + provide options so that it can be + disabled at deployment. + + + + + +Sun, et al. Informational [Page 7] + +RFC 3651 Handle System Service Definition November 2003 + + + Note that a handle value with no PUBLIC_READ nor ADMIN_READ + permission can not leave the handle server. It may be used, for + example, to store secret keys for authentication purposes. A + handle value with neither PUBLIC_WRITE nor ADMIN_WRITE permission + makes the handle value immutable and cannot be deleted by any + handle administrator (via the Handle System protocol). + + The administrator for a given handle must specify the permission + for each handle value. Implementations may choose PUBLIC_READ and + ADMIN_WRITE as the default permission for each handle value. + Handle servers must check permissions before fulfilling any client + request. + + <TTL> + An octet followed by a 4-byte integer that specifies the Time-To- + Live of the value record. It is used to describe how long the + value record can be cached before the source of the information + should again be consulted. A zero value for a TTL indicates that + the value record should only be used for the transaction in + progress and should not be cached. Any non-zero TTL is defined in + terms of a TTL type (specified in the first octet), followed by + the TTL value (the 32-bit unsigned integer that follows the TTL + type). The TTL type indicates whether the TTL value is absolute + or relative. The absolute TTL value defines the time to live in + terms of seconds since 00:00:00 UTC, January 1st 1970. A relative + TTL specifies the time to live in terms of the number of seconds + elapsed since the value was obtained by the client from any handle + server. + + <timestamp> + An 8-byte (long) integer that records the last time the value was + updated at the server. The field contains elapsed time since + 00:00:00 UTC, January 1970 in milliseconds. The choice of + milliseconds is to avoid potential collision when updating the + value. + + <reference> + A 4-byte integer followed by a list of references to other handle + values. The integer specifies the number of references in the + list. Each reference in the list refers to another handle value + in terms of a UTF8-string and a 4-byte integer (where the UTF8- + string is the handle name and the integer is the value index). + References are generally used to add credentials to the current + handle value. For example, a handle value may make itself more + trust-worthy by referring to a digital signature issued by a + commonly trusted entity. + + + + + +Sun, et al. Informational [Page 8] + +RFC 3651 Handle System Service Definition November 2003 + + + By default, the Handle System returns all the handle values with + public-read permission in response of any resolution request. It is + possible for a client to ask for a subset of those values with + specific data type (e.g., all URLs assigned to the handle). The + client may also ask for a specific handle value based on a specific + value index. + + Each handle value can be uniquely referenced by the combination of + the handle and its value index. Care must be taken when changing the + value index as it may break an existing reference to the handle + value. For example, suppose the handle X/Y has a value whose index + is 1. That value may be referred to as X/Y:1. If the handle + administrator changes the value index from 1 to 2, the reference to + X/Y:1 will become obsolete. Any reference to the handle value will + have to change to X/Y:2. + + Value records assigned to any handle may or may not have continuous + index numbers. Nor can it be assumed that the index will start with + 0 or 1. A handle administrator may assign a handle value with any + index as long as each index is unique within the value set. + + A handle value may be "privatized" or "disabled" by setting its + <permission> field as "authorized-read". This limits read-access to + the handle administrator only. The "privatized" value can then be + used to keep any historical data (on behalf of the handle + administrator) without exposing it to public. Such approach may also + be used to keep any obsolete handle or naming authority from being + reused accidentally. + +3.2. Pre-defined Handle Data Types + + Every handle value must have a data type specified in its <type> + field. The Handle System provides a type registration service that + allows organizations to register new data types for their + applications. Data types can be registered as handles under the + naming authority "0.TYPE". For example, the URL data type is + registered under the Handle System as the handle "0.TYPE/URL". The + handle may have a handle value that refers to RFC1738 [9], an IETF + standard document that defines the syntax and semantics of URL. + + The Handle System pre-defines a set of data types to carry out the + handle service. For example, HS_ADMIN is a pre-defined data type + used to describe handle administrators or administrator groups. + HS_SITE is a pre-defined data type to describe the service interface + of any Handle System service component. The following sections + provide detailed descriptions of these pre-defined data types under + the Handle System. + + + + +Sun, et al. Informational [Page 9] + +RFC 3651 Handle System Service Definition November 2003 + + +3.2.1. Handle Administrator: HS_ADMIN + + Each handle has one or more administrators. Any administrative + operation (e.g., add, delete or modify handle values) can only be + performed by the handle administrator with adequate privilege. + Handle administrators are defined in terms of HS_ADMIN values. Every + handle must have at least one HS_ ADMIN value that defines its + administrator. Each HS_ADMIN value can be used to define a set of + handle administrators sharing the same administration privilege. + Handles with multiple administrators of different privileges may have + multiple HS_ADMIN values. HS_ADMIN values are used by the Handle + System to authenticate handle administrators before fulfilling any + handle administration request. + + Naming authorities, as described above, are themselves registered as + handles under the reserved naming authority "0.NA". These handles + are referred to as naming authority handles. Administrators for any + naming authority are defined as the administrators of the + corresponding naming authority handle. For example, "0.NA/10" is the + naming authority handle for the naming authority "10". Hence any + administrator for the naming authority handle "0.NA/10" is also the + administrator for the naming authority "10". Naming authority + administrators are the only ones who can create handles or sub- + naming authorities under the naming authority. A sub-naming + authority may define its own set of administrators to create handles + or further levels of sub-naming authorities. For example, the naming + authority "10.1045" may have a totally different group of + administrators from its parent naming authority "10". + + An HS_ADMIN value is a handle value whose <type> field is HS_ADMIN + and whose <data> field consists of the following entries: + + <AdminRef> + A reference to a handle value. The reference consists of the + handle name (a UTF8-string) followed by a 4-byte unsigned integer + for the handle value index. The handle value identifies the set + of administrators for the handle. + + <AdminPermission> + A 16-bit bit-mask that defines the administration privilege of the + set of handle administrators identified by the HS_ADMIN value. + + The <AdminRef> entry refers to a handle value that can be used to + authenticate the handle administrator. Such handle value is called + the handle administrator reference. The handle administrator + reference may contain the secret key, public key, or X.509 + certificate [10] provided by the handle administrator. For example, + the <AdminRef> entry may contain a handle administrator reference + + + +Sun, et al. Informational [Page 10] + +RFC 3651 Handle System Service Definition November 2003 + + + whose <type> field is DSS_WITH_DES_CBC_SHA and whose <data> field + contains a DES secret key [11], for use in the Cipher Block Chaining + (CBC) mode of operation [12, 13]. The secret key can be used by the + handle server to authenticate the handle administrator. For stronger + cryptographic algorithm, the handle administrator reference may + contain a set of Triple-DES keys [23] and set its <type> to be DES- + EDE3-WITH-CBC. + + A single handle may be assigned with both the HS_ADMIN value and the + handle administrator reference. In other words, the <AdminRef> entry + may refer to a handle value assigned to the same handle that has the + HS_ADMIN value. In this case, authentication of the handle + administrator does not rely on any other handles. Alternatively, the + handle administrator reference may be a handle value under a + different handle. Thus HS_ADMIN values from different handles may + share a common handle administrator reference. This feature allows + sharing of handle administrators among different handles. The handle + administrator reference contains the secret key, public key, or X.509 + certificate provided by the administrator of these handles. + + Handle administrator reference may be of type HS_VLIST and has its + <data> field contain a list of references to other handle values. + Each of these handle values defines a handle administrator reference. + The HS_VLIST value defines an administrator group. Each handle + administrator reference from the HS_VLIST is a member of the + administrator group. Each handle value reference is defined in terms + of a <handle>:<index> pair. An administrator group may also contain + other administrator groups as its members. This allows administrator + groups to be defined in a hierarchical fashion. Care must be taken, + however, to avoid cyclic definition of administrators or + administrator groups. Multiple levels of administrator groups should + be avoided due to their lack of efficiency, but will not be signaled + as an error. Client software should be prepared to detect any + potential cyclic definition of administrators or <AdminRef> entries + that point to non-existent handle values and treat them as an error. + + A handle can have multiple HS_ADMIN values, each of which defines a + different handle administrator. Different administrators can play + different roles or be granted different permissions. For example, + the naming authority handle "0.NA/10" may have two administrators, + one of which may only have permission to create new handles under the + naming authority, while the other may have permission to create new + sub-naming authorities (e.g., "10.1045"). The set of possible + permissions for a handle administrator is defined as follows: + + Add_Handle (0x0001) + This permission allows naming authority administrator to create new + handles under a given naming authority. + + + +Sun, et al. Informational [Page 11] + +RFC 3651 Handle System Service Definition November 2003 + + + Delete_Handle (0x0002) + This permission allows naming authority administrator to delete + handles under a given naming authority. + + Add_NA (0x0004) + This permission allows the naming authority administrator to create + new sub-naming authorities. + + Delete_NA (0x0008) + This permission allows naming authority administrator to delete an + existing sub-naming authority. + + Modify_Value (0x0010) + This permission allows handle administrator to modify any handle + values other than HS_ADMIN values. HS_ADMIN values are used to + define handle administrators and are managed by a different set of + permissions. + + Delete_Value (0x0020) + This permission allows handle administrator to delete any handle + value other than the HS_ADMIN values. + + Add_Value (0x0040) + This permission allows handle administrator to add handle values + other than the HS_ADMIN values. + + Modify_Admin (0x0080) + This permission allows handle administrator to modify HS_ADMIN + values. + + Remove_Admin (0x0100) + This permission allows handle administrator to remove HS_ADMIN + values. + + Add_Admin (0x0200) + This permission allows handle administrator to add new HS_ADMIN + values. + + Authorized_Read (0x0400) + This permission grants handle administrator read-access to handle + values with the ADMIN_READ permission. Administrators without this + permission will not have access to handle values that require + authentication for read access. + + LIST_Handle (0x0800) + This permission allows naming authority administrator to list + handles under a given naming authority. + + + + +Sun, et al. Informational [Page 12] + +RFC 3651 Handle System Service Definition November 2003 + + + LIST_NA (0x1000) + This permission allows naming authority administrator to list + immediate sub-naming authorities under a given naming authority. + + Administrator permissions are encoded in the <AdminPermission> entry + in the <data> field of any HS_ADMIN value. Each permission is + encoded as a bit flag. The permission is granted if the flag is set + to 1, otherwise it is set to 0. + + Figure 3.2.1 shows an example of HS_ADMIN value that defines an + administrator for the naming authority handle "0.NA/10". In figure + 3.2.1, a naming authority administrator is identified by an HS_ADMIN + value assigned to the naming authority handle "0.NA/10". The + administrator can be authenticated based on the handle value + "0.NA/10":3, which is the handle value assigned to the naming + authority handle "0.NA/10" and has its index set to 3. The handle + value "0.NA/10":3 may contain the secret or public key used by the + administrator. The administrator is granted permission to add, + delete, or modify sub-naming authorities under "10", and add or + delete handles directly under the naming authority. The + administrator may also add, delete, or modify any handle values + assigned to the naming authority handle except those HS_ADMIN values. + In other words, the administrator is not allowed to add, delete, or + modify any administrators for the naming authority. + + ------------------------------------------------------------- + ------------------------------------------------------------- | + ------------------------------------------------------------- | | + | | | | + | <index>: 2 | | | + | <type>: HS_ADMIN | | | + | <data>: | | | + | <AdminRef>: "0.NA/10": 3 | | | + | <AdminPerm>: Add_NA, Delete_NA, | | | + | Add Handle, Delete_Handle, | | | + | Add_Value, Delete_Value, Modify_Value, | | | + | Authorized_Read, List_Handle, List_NA | | | + | | | | + | <TTL>: 24 hours | | | + | <permission>: PUBLIC_READ, ADMIN_WRITE | | | + | <reference>: {empty} | |- + | |- + ------------------------------------------------------------- + + Figure 3.2.1: Administrator for the naming authority + handle "0.NA/10" + + + + + +Sun, et al. Informational [Page 13] + +RFC 3651 Handle System Service Definition November 2003 + + + HS_ADMIN values are used by handle servers to authenticate the handle + administrator before fulfilling any administrative requests. The + server authenticates a client by checking whether the client has + possession of the secret key (or the private key) that matches the + one in any of the handle administrator references. The + authentication is carried out via the Handle System authentication + protocol as described later in this document. + + HS_ADMIN values may require authentication for read access in order + to prevent public exposure of the data. Additionally, the handle + administrator reference that contains the administrator's secret key + should have neither PUBLIC_READ nor ADMIN_READ permission to prevent + the key from leaving the server. + +3.2.2. Service Site Information: HS_SITE + + The Handle System consists of a single distributed global handle + service, also known as the Global Handle Registry (GHR), and + unlimited number of Local Handle Services (LHSs). Each handle + service, global or local, may be replicated into multiple service + sites. Each service site may consist of multiple server computers. + Service requests targeted at any handle service can be distributed + into different service sites, and into different server computers + within any service site. Such architecture assures that each handle + service could have the capacity to manage any large number of handles + and handle requests. It also provides ways for each handle service + to avoid any single point of failure. + + Each handle service, global or local, may provide the same set of + functions for resolving and administering its collection of handles. + Handle services differ primarily in that each service is responsible + for a distinct set of handles. They are also likely to differ in the + selection, number, and configuration of their components such as the + servers used to provide handle resolution and administration. + Different handle services may be created and managed by different + organizations. Each of them may have their own goals and policies. + + A service site typically consists of a cluster of server computers + residing within a local Internet domain. These computers work + together to distribute the data storage and processing load at the + site. It is possible, although not recommended, to compose a site + from servers at widely different locations. Further, it is even + possible to compose two different sites from the same set of servers. + + Each service site is defined by an HS_SITE value. HS_SITE is a + pre-defined Handle System data type. An HS_SITE value defines a + service site by identifying the server computers (e.g., IP addresses) + that comprise the site along with their service configurations (e.g., + + + +Sun, et al. Informational [Page 14] + +RFC 3651 Handle System Service Definition November 2003 + + + port numbers). HS_SITE values are typically assigned to naming + authority handles. The set of HS_SITE values assigned to a naming + authority handle is called the service information for the naming + authority. + + The service information is managed by the naming authority + administrator. It must reflect the configuration of the handle + service for the naming authority. Note that an additional layer of + indirection, called a service handle, can be used to allow multiple + naming authorities to reference a single set of HS_SITE values, as + described later in this document (see section 3.2.3). Clients of the + Handle System depend on the service information to locate the + responsible handle server before they can send their service + requests. The service information can also be used by clients to + authenticate any service response from the handle server. + + An HS_SITE value is a handle value whose <type> field is HS_SITE and + whose <data> field consists of the following entries: + + <Version> + A 2-byte value that identifies the version number of the HS_SITE. + The version number identifies the data format used by the HS_SITE + value. It is defined to allow backward compatibility over time. + This document defines the HS_SITE with version number 0. + + <ProtocolVersion> + A 2-byte integer value that identifies the handle protocol version. + The higher byte of the value identifies the major version and the + lower byte the minor version. Details of the Handle System + protocol is specified in [8]. + + <SerialNumber> + A 2-byte integer value that increases by 1 (and may wrap around + through 0) each time the HS_SITE value gets changed. It is used in + the Handle System protocol to synchronize the HS_SITE values + between client and server. + + <PrimaryMask> + An 8-bit mask that identifies the primary site(s) of the handle + service. The first bit of the octet is the <MultiPrimary> bit. It + indicates whether the handle service has multiple primary sites. + The second bit of the octet is the <PrimarySite> bit. It indicates + whether the HS_SITE value is a primary site. A primary site is the + one that supports administrative operations for its handles. A + <MultiPrimary> entry with zero value indicates that the handle + service has a single primary site and all handle administration has + to be done at that site. A non-zero <MultiPrimary> entry indicates + that the handle service has multiple primary sites. Each primary + + + +Sun, et al. Informational [Page 15] + +RFC 3651 Handle System Service Definition November 2003 + + + site may be used to administrate handles managed under the handle + service. Handles managed by such service may identify its primary + sites using an HS_PRIMARY value, as described in section 3.2.5. + + <HashOption> + An 8-bit octet that identifies the hash option used by the service + site to distribute handles among its servers. Valid options + include HASH_BY_NA (0x00), HASH_BY_LOCAL (0x01), or HASH_BY_HANDLE + (0x02). These options indicate whether the hash operation should + only be applied to the naming authority portion of the handle, or + only the local name portion of the handle, or the entire handle, + respectively. The standard MD5 hashing algorithm [14] is used by + each service site to distribute handles among its servers. + + <HashFilter> + An UTF8-string entry reserved for future use. + + <AttributeList> + A 4-byte integer followed by a list of UTF8-string pairs. The + integer indicates the number of UTF8-string pairs that follow. + Each UTF8-string pair is an <attribute>:<value> pair. They are + used to add literal explanations of the service site. For example, + if the <attribute> is "Organization", the <value> should contain a + description of the organization hosting the service site. Other + <attribute>s may be defined to help distinguish the service sites + from each other. + + <NumOfServer> + A 4-byte integer that defines the number of servers in the service + site. The entry is followed by a list of <ServerRecord>s. Each + <ServerRecord> defines a handle server that is part of the service + site. Each <ServerRecord> consists of the following data fields: + + <ServerRecord> ::= <ServerID> + <Address> <PublicKeyRecord> <ServiceInterface> + + where each field is defined as follows: + + <ServerID> + A 4-byte unsigned integer that uniquely identifies a server + process under the service site. <ServerID>s do not have to + begin with 1 and they don't have be consecutive numbers. They + are used to distinguish servers under a service site from each + other. Note that there can be multiple servers residing on any + given computer, each with a different <ServerID>. + + + + + + +Sun, et al. Informational [Page 16] + +RFC 3651 Handle System Service Definition November 2003 + + + <Address> + The 16-byte IPv6 [15, 16] address of the handle server. Any + IPv4 address should be presented as :::::FFFF:xxxx:xxxx (where + xxxx:xxxx can be any 4-byte IPv4 address). + + <PublicKeyRecord> + A 4-byte integer followed by a byte-array that contains the + server's public key. The integer specifies the size of the + byte-array. The byte-array (for the publickey) consists of + three parts: a UTF8-string that describes the key type, a + two-byte option field reserved for future use, and a byte-array + that contains the public key itself. For example, the UTF8- + String "DSA_PUB_KEY" indicates that the <PublicKeyRecord> + contains a DSA public key. The storage format of the DSA key + in the byte-array could then be found from the handle + "0.type/DSA_PUB_KEY". Public key in the <PublicKeyRecord> can + be used to authenticate any service response from the handle + server. + + The <PublicKeyRecord> may also contain an X.509 certificate. + This happens if the key type field contains the UTF8-String + "CERT.X509". In this case, "CERT.X509" will map to the handle + "0.TYPE/CERT.X509". The handle may contain information that + describes the syntax and semantics of the public key or its + certificate. Additional key type may also be registered (as + handles under "0.TYPE") to further distinguish different kinds + of X.509 certificates. For example, "CERT.X509.DSA" may be + used to denote X.509 certificates that contain DSA public keys. + If the key type field of a <PublicKeyRecord> declares + "CERT.X509.DSA", the <PublicKeyRecord> must contain a X.509 + certificate with a DSA public key in it." + + <ServiceInterface> ::= <InterfaceCounter> + * [ <ServiceType> + <TransmissionProtocol> + <PortNumber> ] + + A 4-byte integer followed by an array of triplets consisting of + <ServiceType, TransmissionProtocol, PortNumber>. The 4-byte + integer specifies the number of triplets. Each triplet lists a + service interface provided by the handle server. For each + triplet, the <ServiceType> is an octet (as a bit mask) that + specifies whether the interface is for handle resolution + (0x01), handle administration (0x02), or both. The + <TransmissionProtocol> is also an octet (as a bit mask) that + specifies the transmission protocol. Possible transmission + protocols include TCP (0x01), UDP (0x02), and HTTP (0x04). The + + + + +Sun, et al. Informational [Page 17] + +RFC 3651 Handle System Service Definition November 2003 + + + <PortNumber> is a 4-byte unsigned integer that specifies the + port number used by the interface. The default port number is + 2641. + + Figure 3.2.2 shows an example of handle service site in terms of a + HS_SITE value. The HS_SITE value is assigned to the naming authority + handle "0.NA/10". The <PrimaryMask> indicates that it is the only + primary site of the handle service. The site consists of three + handle servers, as indicated in the <NumOfServer>. These servers + provide handle resolution and administration service for every handle + under the naming authority "10". The first server record (ServerID + 0) shows two service interfaces, one for handle resolution and the + other for handle administration. Each interface has its own port. + + Each server within a service site is responsible for a subset of + handles managed by the handle service. Clients can find the + responsible server by performing a common hash-operation. The hash- + operation will first convert all ASCII characters in the handle into + upper-case. It then applies the MD5 hashing upon the portion of the + converted handle string (according to the <HashOption> entry). The + result is a 16-byte integer. The absolute value of the integer will + be divided by the number of servers (specified in the <NumOfServer> + entry). The remainder is the sequence number (starting with zero) of + the <ServerRecord> listed in the HS_SITE value. From the + <ServerRecord>, clients can find the IP address of the handle server + for their handle requests. + + + + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 18] + +RFC 3651 Handle System Service Definition November 2003 + + + ------------------------------------------------------------ + ------------------------------------------------------------ | + ----------------------------------------------------------- | | + | | | | + | <index>: 2 | | | + | <type>: HS_SITE | | | + | <data>: | | | + | Version: 0 | | | + | ProtocolVersion: 2.1 | | | + | SerialNumber: 1 | | | + | PrimaryMask: | | | + | MultiPrimary: FALSE | | | + | PrimarySite: TRUE | | | + | HashOption: HASH_BY_HANDLE | | | + | HashFilter: {empty UTF8-String} | | | + | AttributeList: 0 {followed by no attributes} | | | + | NumOfServer: 3 | | | + | {followed by a list of <ServerRecord>} | | | + | | | | + | ----------------------------------------- | | | + | ------------------------------------------ | | | | + | ------------------------------------------ || | | | + | | ServerID: 1 ||| | | | + | | Address: :FFFF:132.151.1.155 ||| | | | + | | PublicKeyRecord: HS_DSAKEY, iQCuR2R... ||| | | | + | | ServiceInterface ||| | | | + | | ServiceType: Resolution_Only ||| | | | + | | TransmissionProtocol: TCP & UDP ||| | | | + | | PortNumber: 2641 ||| | | | + | | ||| | | | + | | ServiceType: Admin only ||| | | | + | | TransmissionProtocol: TCP || | | | + | | PortNumber: 2642 | | | | + | ------------------------------------------ | | | + | | | | + | <TTL>: 24 hours | | | + | <permission>: PUBLIC_READ, ADMIN_WRITE | | | + | <reference>: {empty} | |- + | |- + ----------------------------------------------------------- + + Fig. 3.2.2: The primary service site for the naming authority "10" + +3.2.3. Naming Authority Delegation Service: HS_NA_DELEGATE + + The HS_NA_DELEGATE is a pre-defined Handle System data type. It has + the exact same format as the HS_SITE value. Like HS_SITE values, + HS_NA_DELEGATE values are used to describe service sites of a LHS. + + + +Sun, et al. Informational [Page 19] + +RFC 3651 Handle System Service Definition November 2003 + + + HS_NA_DELEGATE values may be assigned to naming authority handles to + designate naming authority administration to a LHS. A naming + authority handle with a set of HS_NA_DELEGATE values indicates that + all child naming authorities of the naming authority are managed by + the LHS described by the HS_NA_DELEGATE values. + + For example, suppose the naming authority "foo.bar" decides to have + its child naming authorities delegated to a LHS. To achieve this, + one may assign the naming authority handle "0.NA/foo.bar" with a set + of HS_NA_DELEGATE values that describes the LHS. The set of + HS_NA_DELEGATE values indicate that the service information of any + child naming authority of the "foo.bar", such as "foo.bar.baz", can + be found by querying the naming authority handle "0.NA/foo.bar.baz" + from the LHS. + +3.2.4. Service Handle: HS_SERV + + Any handle service, global or local, can be defined in terms of a set + of HS_SITE values. These HS_SITE values may be assigned directly to + the relevant naming authority handle, or an additional level of + indirection may be introduced through the use of service handles. A + service handle may be thought of as a name for a handle service. It + may be used to maintain the HS_SITE values for the handle service and + referenced from a naming authority handle via a HS_SERV value. A + HS_SERV value is a handle value whose <type> field is HS_SERV and + whose <data> field contains the reference to the service handle. + HS_SERV values are typically assigned to naming authority handles to + refer clients to the responsible handle service. + + Use of service handle allows sharing of service information among + multiple naming authorities. It also allows changes to service + configuration (e.g., adding a new site) to be made in one place + rather than in every naming authority handle involved. The mechanism + may also be used to support service referral from one handle service + to another for whatever reason. + + A naming authority handle may have no more than one HS_SERV value + assigned to it, otherwise it is an error. If a naming authority + handle has both a list of HS_SITE values and an HS_SERV value, the + HS_SITE values should be used as the service information for the + naming authority. + + Service handles can be registered under the reserved naming authority + "0.SERV". Handles under "0.SERV" are managed by the GHR. For + example, the service handle "0.SERV/123" may be created to maintain + the service information for the handle service that manages handles + under the naming authority "123" and any of its sub-naming + authorities. + + + +Sun, et al. Informational [Page 20] + +RFC 3651 Handle System Service Definition November 2003 + + + Similarly, a service handle "0.SERV/a.b.c" may be created to host the + service information for the handle service that manages handles under + the naming authority "a.b.c". + + The use of service handles raises several special considerations. + Multiple levels of service handle redirection should be avoided due + to their lack of efficiency, but are not signaled as an error. + Looped reference of service handles or HS_SERV values that point to + non-existent service handles should be caught and error conditions + passed back to the user. + +3.2.5. Alias Handle: HS_ALIAS + + In practice, it is very possible that a digital object may have + multiple names that will identify the object. The Handle System + supports such feature via the pre-defined data type HS_ALIAS. An + HS_ALIAS value is a handle value whose <type> field is HS_ALIAS and + whose <data> field contains a reference to another handle. A handle + with a HS_ALIAS value is an alias handle to the handle referenced in + the HS_ALIAS value. An alias handle should not have any additional + handle values other than HS_ALIAS or HS_ADMIN (for administration) + values. This is necessary to prevent any inconsistency between a + handle and its aliases. + + During a handle resolution, a client may get back an HS_ALIAS value. + This indicates that the handle in question is an alias handle. The + client may then retry the query against the handle specified in the + HS_ALIAS value until final results are obtained. + + The use of alias handle introduces a number of special + considerations. For example, multiple levels of aliases should be + avoided for the sake of efficiency, but are not signaled as an error. + Alias loops and aliases that point to non-existent handles should be + caught and error conditions passed back to the user. + + One potential use of alias handle would be to support the transfer of + ownership of any named resource. When a resource identified by a + handle transfers from one organization to another, a new handle for + the resource may be created. To avoid inconsistency and any broken + reference, the handle used before the ownership transfer may be + changed into an alias handle and point its HS_ALIAS value to the + newly created handle. + +3.2.6. Primary Site: HS_PRIMARY + + HS_PRIMARY is a pre-defined data type used to designate the primary + service sites for any given handle. A handle service with multiple + primary service sites is called a multi-primary service. Otherwise + + + +Sun, et al. Informational [Page 21] + +RFC 3651 Handle System Service Definition November 2003 + + + it is called a single-primary service. Each handle managed by a + multi-primary handle service may specify its primary service sites in + terms of an HS_PRIMARY value. A HS_PRIMARY value is a handle value + whose <type> field is HS_PRIMARY and whose <data> field contains a + list of references to HS_SITE values. Each of these HS_SITE defines + a primary service site for the handle. + + There can be at most one HS_PRIMARY value assigned to each handle. + Otherwise it is an error. A handle with no HS_PRIMARY value but + managed by a multi-primary handle service is not an error. In this + case, every primary service site of the handle service will also be + the primary site for the handle. Handles managed by a single-primary + handle service do not need any HS_PRIMARY values and any such values + should be ignored. + +3.2.7. Handle Value List: HS_VLIST + + HS_VLIST is a pre-defined data type that allows a handle value to be + used as a reference to a list of other handle values. An HS_VLIST + value is a handle value whose <type> is HS_VLIST and whose <data> + consists of a 4-byte unsigned integer followed by a list of + references to other handle values. The integer specifies the number + of references in the list. The references may refer to handle values + under the same handle or handle values from any other handles. Each + reference is encoded as an UTF8-string followed by a 4-byte unsigned + integer that identifies the referenced handle and its value index. + + HS_VLIST values may be used to define administrator groups for + handles. In this case, each reference in the HS_VLIST defines a + member of the administrator group and the HS_VLIST value identifies + the group as a whole. Client software must be careful, however, to + avoid cyclic definition of value references. + +4. Handle System Service Model + + The Handle System is a distributed global name service. It consists + of a single distributed Global Handle Registry (GHR) and unlimited + number of Local Handle Services (LHS). These service components + provide the name service (both resolution and administration) on + behalf of Handle System client components. Handle System client + components may also choose to use Handle System middle-ware + components (e.g., the Handle System caching service) for efficiency. + This section describes these components and their relationships to + each other. + + + + + + + +Sun, et al. Informational [Page 22] + +RFC 3651 Handle System Service Definition November 2003 + + +4.1. Handle System Service Components + + The Handle System defines a hierarchical service model. At the top + level is the single distributed global handle service, also known as + the Global Handle Registry (GHR). Underneath the GHR, there can be + any number of Local Handle Services (LHSs). Each LHS must be + registered with the GHR to manage handles under a distinct set of + naming authorities. Naming authorities are managed by the GHR via + naming authority handles (i.e., handles under the naming authority + "0.NA"). A naming authority handle can also be used to locate the + service information (in terms of HS_SITE values) that describes the + handle service responsible for handles under the naming authority. + From the service information, clients can choose a service site and + locate the responsible server for their handle requests. + + Handle System service components are scalable and extensible to + accommodate any large amount of service load. A handle service, + global or local, may consist of multiple service sites, replicating + each other. Each service site may also consist of a cluster of + computers working together to serve its respective namespace. Having + multiple service sites avoids any single point of failure and allows + load balancing among these service sites. Using multiple servers at + any service site distributes the service load into multiple server + processes and allows less powerful computers to be utilized for the + name service. + +4.1.1. Global Handle Registry (GHR) + + The Global Handle Registry (GHR) is mainly used to manage naming + authority handles and to provide service information for every naming + authority under the Handle System. The GHR may also be used to + manage and provide resolution and administration service to non- + naming-authority handles. Unlike any LHS, which mostly manages + handles under a few naming authorities, the GHR is primarily used to + register naming authorities and provide service information for every + LHS. In other words, the GHR is the single root service that + registers every LHS and provides their service information via the + use of naming authority handle(s). Every naming authority under the + Handle System must be registered under the GHR as a naming authority + handle. The naming authority handle provides the service information + of the handle service that manages all the handles under the naming + authority. The service information may be provided in terms of a set + of HS_SITE values, or an HS_SERV value that refers to a service + handle, as described earlier. + + The GHR may consist of multiple service sites, each described in a + HS_SITE value. These HS_SITE values are assigned to the designated + naming authority handle "0.NA/0.NA", also called the root handle. The + + + +Sun, et al. Informational [Page 23] + +RFC 3651 Handle System Service Definition November 2003 + + + root handle is the naming authority handle that maintains the service + information for GHR. Top level naming authorities can only be + created by administrators of the root handle. + + In order to communicate with the GHR, client software needs the GHR + service information beforehand. The service information may be + distributed initially with the client software, or obtained from some + other secure sources (e.g., postal mail, secure web site, etc.). + Client software may keep the service information to communicate with + the GHR until the service information becomes expired (according to + its TTL). The GHR must update its service information (assigned to + the root handle) every time it changes its configuration. Client + software with out-dated service information will be notified of the + update every time it communicates with the GHR. The GHR must be + maintained in such a way that any client software with out-dated GHR + service information can still query the root handle for the latest + update. + + Fig. 4.1.1 shows the GHR service information in terms of a set of + HS_SITE values. The GHR may consist of a number of service sites, + each described in a HS_SITE value. The figure shows a GHR service + site located in US East Coast, as indicated in the <AttributeList>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 24] + +RFC 3651 Handle System Service Definition November 2003 + + + ------------------------------------------------------------ + ------------------------------------------------------------ | + ----------------------------------------------------------- | | + | | | | + | <index>: 3 | | | + | <type>: HS_SITE | | | + | <data>: | | | + | Version: 1 | | | + | ProtocolVersion: 2.1 | | | + | SerialNumber: 1 | | | + | PrimaryMask: | | | + | MultiPrimary: TRUE | | | + | PrimarySite: TRUE | | | + | HashOption: HASH_BY_HANDLE | | | + | HashFilter: {empty UTF8-String} | | | + | AttributeList: 1 | | | + | Description: Service site at US East Coast | | | + | NumOfServer: 3 | | | + | | | | + | ------------------------------------------ | | | + | ------------------------------------------ | | | | + | ------------------------------------------ || | | | + | | ServerID: 1 ||| | | | + | | Address: :FFFF:132.151.2.150 ||| | | | + | | PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... ||| | | | + | | ServiceInterface ||| | | | + | | ServiceType: Resolution & Admin ||| | | | + | | TransmissionProtocol: TCP & UDP || | | | + | | PortNumber: 2641 | | | | + | ------------------------------------------ | | | + | | | | + | <TTL>: 24 hours | | | + | <permission>: PUBLIC_READ, ADMIN_WRITE | | | + | <reference>: {empty} | |- + | |- + ----------------------------------------------------------- + + Figure 4.1.1: GHR service information + + The GHR and its service information provide an entry point for any + client software to communicate with the Handle System. For any given + handle, client software can query the GHR for its naming authority + handle. This will return the service information of the LHS that + manages every handle under the naming authority. The service + information will direct the client software to the handle server + within the LHS that manages the handle. + + + + + +Sun, et al. Informational [Page 25] + +RFC 3651 Handle System Service Definition November 2003 + + +4.1.2. Local Handle Service (LHS) + + A Local Handle Services (LHS) manages handles under given sets of + naming authorities. Each naming authority defines a "local" + namespace that consists of all of the handles under the naming + authority. Note that a LHS is not a "local" service in terms of any + network topology. It is called a "Local" Handle Service because it + typically manages a restricted (local) namespace. + + A naming authority is "homed" at a LHS if all handles under the + naming authority are managed by the LHS. A LHS may be home to + multiple naming authorities. On the other hand, a naming authority + may only be "homed" at one LHS. Note that a naming authority may + also be homed at the GHR. + + ------------------------------------------------------------ + ------------------------------------------------------------ | + ----------------------------------------------------------- | | + | <index>: 3 | | | + | <type>: HS_SITE | | | + | <data>: | | | + | Version: 1 | | | + | ProtocolVersion: 2.1 | | | + | SerialNumber: 1 | | | + | PrimaryMask: | | | + | MultiPrimary: FALSE | | | + | PrimarySite: TRUE | | | + | HashOption: HASH_BY_LOCALNAME | | | + | HashFilter: {empty UTF8-String} | | | + | AttributeList: 1 | | | + | Description: Local Service for "10" | | | + | NumOfServer: 2 | | | + | ----------------------------------------- | | | + | ----------------------------------------- | | | | + | | ServerID: 1 || | | | + | | Address: :FFFF:132.151.3.150 || | | | + | | PublicKeyRecord: HS_DSAKEY, iQCuR2R... || | | | + | | ServiceInteface: || | | | + | | ServiceType: Resolution & Admin || | | | + | | TransmissionProtocol: TCP & UDP || | | | + | | PortNumber: 2641 |' | | | + | -----------------------------------------' | | | + | <TTL>: 24 hours | | | + | <permission>: PUBLIC_READ, ADMIN_WRITE | |- + | <reference>: {empty} |- + ----------------------------------------------------------- + + Figure 4.1.2: LHS service information + + + +Sun, et al. Informational [Page 26] + +RFC 3651 Handle System Service Definition November 2003 + + + + Like the GHR, a LHS may also consist of many service sites with each + site described by an HS_SITE value. The set of HS_SITE values for + any LHS may be assigned to a service handle or to the relevant naming + authority handle(s). Fig. 4.1.2 shows an example of HS_SITE values + for a LHS. These HS_SITE values are assigned to the naming authority + handle "0.NA/10". This suggests that the naming authority "10" is + "homed" at the LHS specified in these HS_SITE values. Clients may + query the GHR to obtain the service information in order to + communicate with the LHS. Administrators of the naming authority + handle are responsible for maintaining the service information and + keeping it up to date. + + Note that a LHS may refer its clients to another LHS in response to a + service request. This allows the LHS to further distribute its + service in a hierarchical fashion. + +4.2. Handle System Middle-Ware Components + + Handle System middle-ware components currently include Handle System + caching servers and Handle System proxy servers. These Handle System + middle-ware components are clients to Handle System service + components, but servers to Handle System client software. Handle + System middle-ware components are used to provide additional + interfaces to the basic handle service. For example, a Handle System + caching server may be used to share resolution results within a local + community. Additionally, a Handle System proxy server can be used to + bypass any organizational firewall via HTTP tunneling. + +4.2.1. Handle System Caching Service + + Handle System caching service can be used to reduce the network + traffic between Handle System clients and servers. Caching handle + data, including the service information of any LHS, allows re-use of + information obtained from earlier queries. + + Each handle value contains a <TTL> (Time to Live) field that tells a + caching service how long the cached value may be regarded as valid. + A zero-value TTL indicates that the value can only be used for the + transaction in progress and should not be cached. A caching service + may obtain its data directly from a handle service, or from another + caching service that eventually gets its data from the handle + service. + + + + + + + + +Sun, et al. Informational [Page 27] + +RFC 3651 Handle System Service Definition November 2003 + + + A caching service may be defined in terms of an HS_SITE value and may + consist of multiple caching servers. For any given handle, clients + can find the responsible caching server within the caching service by + using the same hashing algorithm as used in locating the handle + server within any handle service. + + Caching services are not part of any Handle System administration or + authentication hierarchy. The Handle System protocol does not + authenticate any response from a caching service. Clients are + responsible to set up their trust relationship with the caching + service that they select. They will also rely on the caching service + to properly authenticate any response from any handle server. + +4.2.2. Handle System Proxy Server + + Handle System proxy servers can be used to enable handle resolution + via other Internet protocols. For example, CNRI has built and made + available a Handle System HTTP Proxy Server that will process any + handle resolution in terms of HTTP protocol. The current DNS address + for the proxy server is at "hdl.handle.net". The proxy server allows + any handle to be resolved via a HTTP URL. The URL can be constructed + as "http://hdl.handle.net/<handle>", where <handle> can be any handle + from the Handle System. For example, the handle + "ncstrl.vatech_cs/tr-93-35" can be resolved via the HTTP URL + "http://hdl.handle.net/ncstrl.vatech_cs/tr-93-35" from any web + browser. In this case, the URL is sent to the proxy server in terms + of a HTTP request. The proxy server will query the Handle System for + the handle data and return the results in terms of HTTP response. + + Using HTTP URLs allows handles to be resolved from standard web + browsers without any additional client software. However, such + reference to the handle also ties itself to the proxy server. If the + proxy server changes its DNS name or otherwise becomes invalid, the + reference (i.e., the HTTP URL) to the handle will break. Thus the + selection or use of proxy server should be carefully evaluated. + + Proxy servers are not part of any Handle System administration or + authentication hierarchy. The Handle System protocol does not + authenticate any response from a proxy server. Clients are + responsible to set up their trust relationship with the proxy server + that they select. They will also rely on the proxy server to + properly authenticate any response from any handle server. + +4.3. Handle System Client Components + + Handle System client components are client software that communicates + with the Handle System service components. Client software may speak + the Handle System protocol and send its request directly to a service + + + +Sun, et al. Informational [Page 28] + +RFC 3651 Handle System Service Definition November 2003 + + + component. The response from the service component may be the final + answer to the request, or a referral to another service component. + The client software will have to follow the referral in order to + complete the transaction. + + Client software may also be configured to tunnel its request via a + middle-ware component. The middle-ware component will thus be + responsible for obtaining the final result and returning it to the + client. Unlike service components, middle-ware components will only + return final results of client's request. No service referral will + be returned from middle-ware components. + + Various Handle System client components may be developed for various + applications. The CNRI Handle System Resolver [17] is one such + component. The resolver extends web browsers (e.g., Netscape or + Microsoft Internet Explorer) in such a way that handles can be + resolved directly in terms of "hdl:" Uniform Resource Identifiers + (URIs). The Grail web browser [18], a freely downloadable software + developed in Python [19], also supports the "hdl:" URI scheme and + will resolve handles accordingly. For example, the handle + "10.1045/july95-arms" may be resolved by entering its handle URI as + "hdl:10.1045/july95-arms" into any of these resolver-enabled + browsers. Details of the handle URI syntax will be specified in a + separate document. + +5. Handle System Operation Model + + Handle System operations can be categorized into resolution and + administration. Clients use the handle resolution service to query + for any handle values. Handle administration allows clients to + manage handles, including adding and deleting handles, and updating + their values. It also deals with naming authority administration via + naming authority handles. This section explains how various Handle + System components work together to accomplish these service + operations. + + Both resolution and administration may require authentication of the + client. The authentication can be done via the Handle System + authentication protocol described later in this section. Whether + authentication is required or not depends on the kind of operation + involved and the permissions assigned to the relevant handle value, + and policies deployed by the relevant service components. + + The Handle System protocol specifies the syntax and semantics of each + message exchanged between Handle System clients and its server + components. This section provides a high level overview of the + + + + + +Sun, et al. Informational [Page 29] + +RFC 3651 Handle System Service Definition November 2003 + + + protocol used to accomplish any service operation. The exact + programmatic detail of each message (i.e., their byte layout or + syntax) is specified in a separate document [8]. + +5.1. Handle System Service Request and Response + + The Handle System provides its service in response to client + requests. A client may send a request to any handle server to + provoke a response. The response either provides an answer to the + request, or a status code with associated information that either + refers the request to another service component, asks for client + authentication, or signals some error status. + + Each handle under the Handle System is managed by its home service. + The naming authority handle provides the service information (in + terms of HS_SERV or HS_SITE values) of the handle service that + manages all handles under the naming authority. Any handle request + must be directed to the home service of the handle in question. + Clients may find the home service by querying the corresponding + naming authority handle against the GHR. Alternatively, this + information may be found in a local cache or even be part of a local + client configuration. Given the service information, clients may + select a service site and locate the responsible handle server within + the site. + + To resolve the handle "ncstrl.vatech_cs/te-93-35", for example, + client software needs to know the home service for the naming + authority "ncstrl.vatech_cs". The home service can be obtained by + querying the naming authority handle "0.NA/ncstrl.vatech_cs" against + the GHR. The GHR will return the service information in terms of the + HS_SITE values assigned to the naming authority handle. From the + service information, clients can pick a service site, find the + responsible handle server within the site, and send the resolution + request to the handle server. + + Clients may require digital signatures from a handle server in order + to authenticate any response from the server. The signature can be + generated using the server's private key. Clients may verify the + signature using the public key available from the service information + (refer to the <PublicKeyRecord> entry discussed in 3.2.2). + + A communication session may also be established between any client + and handle server. Each session is identified by a unique session ID + managed by the server. A session may be used to manage requests that + require multiple interactions. It may also be used to share any TCP + connection or authentication information among multiple service + transactions. Each session may establish a session key and use it to + + + + +Sun, et al. Informational [Page 30] + +RFC 3651 Handle System Service Definition November 2003 + + + authenticate any message exchanged within the session. It may also + be used to encrypt any message between the client and the server to + achieve data confidentiality. + + The following diagram shows a handle resolution process in terms of + messages exchanged between client software and Handle System service + components. In this case, the client is trying to resolve the handle + "ncstrl.vatech_cs/tr-93-35". It assumes that the client has yet + obtained the service information of the LHS "homed" by the naming + authority "ncstrl.vatech.cs". The client has to get the service + information from the naming authority handle managed by the GHR. The + service information allows the client to locate the responsible LHS + and query for the handle value. + + [HS Client] ----------------------------> [Global Handle Registry] + 1. ask for the service + information from the + naming authority handle + "0.NA/ncstrl.vatech_cs" + + + [HS Client] <---------------------------- [Global Handle Registry] + 2. service information for + the naming authority + "ncstrl.vatech_cs" + + [HS Client] ----------------------------> [Local Handle Service] + 3. query the handle + "ncstrl.vatech_cs/tr-93-35" + against the responsible + handle server + + \... ... + + (optional client authentication, depending on the service request) + + \... ... + + [HS Client] <---------------------------- [Local Handle Service] + 4. query result from the handle + server + (optional) server + signature + + Figure 5.1: Handle resolution example + + In Figure 5.1, the client is configured to communicate with the GHR + for any handle service. In this case, the client first queries the + GHR to find the home service for the handle's naming authority. The + + + +Sun, et al. Informational [Page 31] + +RFC 3651 Handle System Service Definition November 2003 + + + GHR returns the service information of the LHS that manages every + handle under the naming authority. From the service information, the + client can find the responsible handle server and query the server + for the handle. The server may set up a session to authenticate the + client if any of the handle value requires authentication. + Otherwise, the server will simply return the handle value to the + client. The server may send a digital signature as part of its + response if required by the client. + + The above procedure assumes that the client software already has the + GHR service information. That information was likely obtained from + the client software distribution. The GHR will notify the client + software if it learns that the service information used by the client + software is out of date. Client software may retrieve the latest + service information from the root handle "0.NA/0.NA". The root handle + also maintains the public key that may be used to authenticate the + service information. + + Note that a client may cache the service information of any naming + authority so that subsequent queries for handles under the same + naming authority may reuse the service information and bypass the + first two steps shown in Figure 5.1. Client software may also be + configured to query a caching or proxy server directly for any + handle. In this case, the caching or proxy server will act as the + [HS Client] in Figure 5.1 before returning the query result to the + client. + + Client software under certain organization may also elect to bypass + the GHR and communicate directly with a LHS managed by the + organization. Doing so may achieve quicker response for handles + managed under the LHS. The client software will be referred to the + GHR for handles not managed by the LHS. + +5.2. Handle System Authentication Protocol + + The Handle System supports handle administration over the public + Internet. Access controls can be defined on each handle value. The + Handle System authentication protocol is the protocol used by any + handle server to authenticate handle administrator upon any + administration request. The authentication is also necessary when + clients query for handle values that are read-only by the handle + administrator. Handle administration include adding, deleting or + modifying handle values, and adding or deleting handles. Naming + authority administrations are carried out as handle administrations + over the corresponding naming authority handles. + + + + + + +Sun, et al. Informational [Page 32] + +RFC 3651 Handle System Service Definition November 2003 + + + The Handle System authentication protocol does not perform any server + authentication. However, a client may authenticate any server + response by asking the server to sign its response with digital + signature. + + By default, the Handle System authenticates clients via a challenge- + response protocol. That is, after receiving a client's request, the + server issues a challenge to the client if authentication is + necessary. To be authenticated as the administrator, the client has + to return a challenge-response, a message that demonstrates + procession of the administrator's secret. The secret may be the + private key or the secret key of the administrator. This challenge- + response allows the server to authenticate the client as the handle + administrator. Upon successful authentication, the server will + fulfill the client's request if the administrator is given sufficient + permission. + + For example, suppose a client sends a request to the handle server to + add a new handle value. The server will issue a challenge to the + client in order to authenticate the client as one of the handle + administrators. If the client possesses the private key of the + administrator, she can use it to sign the server's challenge and + return the signature as part of her challenge-response. The server + will validate the signature in order to authenticate the client. The + client will be notified if the validation fails. Otherwise, the + server will further check if the administrator has the permission to + add the handle value. If so, the server will add the handle value + and report success to the client. Otherwise, a permission-denied + message will be returned. + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 33] + +RFC 3651 Handle System Service Definition November 2003 + + + The following diagram shows a typical authentication process in terms + of the messages exchanged between the client and the handle server. + + [Client] --------------------------------> [Handle Server] + 1. client request + + (optional) client credential + + [Client] <-------------------------------- [Handle Server] + 2. server's challenge to client + + (i.e., nonce + MD5 of client request) + + [Client] -------------------------------> [Handle Server] + 3. reference to handle administrator + + challenge-response from client + + [Client] <------------------------------- [Handle Server] + 4. server acknowledgement + + Figure 5.2: Handle System authentication process + + In Figure 5.2, the client sends an administration request to the + handle server (along with optional credential discussed later). The + server decides that client authentication is required and issues a + challenge to the client. The client identifies itself as a handle + administrator and returns the challenge-response to the server. The + server authenticates the client as the administrator based on the + challenge-response. It also checks to see if the administrator is + authorized for the administration request. If so, the server will + fulfill the request and acknowledge the client. + + Handle servers must authenticate the client before fulfilling any + request that requires administrator privilege. The exact + authentication process varies depending on whether public key or + secret key is used by the administrator. It also depends on whether + the handle used to store the administrator's key is managed by the + same handle server or not. + + When public key is used, the challenge-response from the client + contains its digital signature over the server's challenge. The + server can authenticate the client by verifying the digital signature + based on the administrator's public key. If secret key is used, the + challenge-response from the client carries the Message Authenticate + Code (MAC) generated using the secret key. The server may + authenticate the client by generating the same MAC using the + administrator's secret key and comparing it against the challenge- + response. + + + + + +Sun, et al. Informational [Page 34] + +RFC 3651 Handle System Service Definition November 2003 + + + The reference to handle administrator in Fig 5.2 is also called a + key-reference. It refers to a handle value that contains the key + used by the administrator. If the key-reference is managed by the + same handle server (e.g., a handle value assigned to the same + handle), the server may use the key directly to do the + authentication. If the key-reference is managed by some other handle + server (whether or not within the same handle service), the server + will have to send a verification-request to this other handle server, + call it the key-server, in order to authenticate the client. The + verification-request to the key-server carries both the server's + challenge and the client's challenge-response. The key-server will + return a verification-response, signed using the key-server's private + key. The content of the verification-response will depend on the + handle value referenced by the key-reference. If the key-reference + refers to a public key used by the administrator, the verification- + response will contain the public key of the administrator. + Otherwise, the key-server will verify the challenge-response on + behalf of the requesting server and return the result in the + verification-response. The following diagram shows the control flow + of the authentication process where the key-reference refers to a + handle value that contains the administrator's public (or secret) key + and the key-server is some other handle server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 35] + +RFC 3651 Handle System Service Definition November 2003 + + + -------- ------------- + | | 1. client request. | | + | | -------------------------------> | | + | | | | + | | 2. session ID | | + | | + server's challenge | | + | Handle | <------------------------------- | Handle | + | System | | server | + | client | 3. session ID | receiving | + | | + response to the challenge | client | + | | + administrator reference | request | + | | --------------------------------> | | + | | | | + | | 6. server acknowledgement | | + | | <------------------------------- | | + -------- ------------- + | ^ + 4. Verification | | 5. verifi- + request | | cation + | | response + | | (signed) + V | + -------------------------- + | The handle server (the | + | key-server) that manages | + | the key referenced by | + | the key-reference | + -------------------------- + + Figure 5.3: Authentication process requiring verification + from a second handle server + + Secret key based authentication via a second handle server, i.e., the + key server, provides a convenient way to share a common secret key + (e.g., pass phrase) among handles managed by different handle + servers. However, it should not be used to manage highly sensitive + handles or handle data. The authentication process itself is + expensive and relies on a third party, i.e., the key-server, for + proper operation. Additionally, the secret key itself is subject to + dictionary attack since the key-server cannot determine whether the + verification-request comes from a legitimate handle server. A handle + service may set its local policy so that secret key based + authentication can only be carried out if the handle server + (receiving the client request) is also the key-server. + + + + + + + +Sun, et al. Informational [Page 36] + +RFC 3651 Handle System Service Definition November 2003 + + + Local handle services may define additional local policies for + authentication and/or authorization. Handle System service + components may also choose to use other Internet authentication + mechanisms such as Kerberos [20] or some Transport Layer Security + protocol [21]. Details of these will be addressed in a separate + document. + +6. Security Considerations + + Handle System security considerations are discussed in the "Handle + System Overview" [1] and that discussion applies equally to this + document. + + The Handle System delegates handle administration to each handle + administrator who may or may not be the server administrator. Handle + administrators are allowed to choose their own public/secret keys + used for authentication. The security of Handle System + authentication depends on the proper key selection and its + maintenance by the handle administrator. Handle administrators must + choose and protect their authentication keys carefully in order to + protect the handle data. Handle server implementations may deploy + policies that regulate the selection of public/secret keys used for + authentication. For example, a handle server may require that any + authentication key must be no less than certain number of bits. It + may also prohibit the use of secret keys because of the potential + dictionary attack. + + The Handle System data model supports execution permission + (PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value. While this + allows better sharing of network resources, it also raises many + security considerations. Execution privilege should be restricted + within the permissions of certain user account (corresponding to the + handle administrator) on the server to prevent system-wide + disruption. Switching between computing platforms for the server + should also be careful to avoid any unexpected behavior. + Implementations may choose not to support the execution permission, + or provide options so that it can be disabled. + + To protect against any irresponsible use of system resource, handle + servers may implement quota control. The quota control can be used + to put limits on the number of handles under a naming authority, the + number of handle values allowed for any given handle, the maximum + size of any handle value, and the number of sub-naming authorities + under a naming authority. Handle servers must report error if the + result of a handle administration violates any of these limits. + + + + + + +Sun, et al. Informational [Page 37] + +RFC 3651 Handle System Service Definition November 2003 + + +7. Acknowledgements + + This work is derived from the earlier versions of the Handle System + implementation. The overall digital object architecture, including + the Handle System, was described in a paper by Robert Kahn and Robert + Wilensky [22] in 1995. Development continued at CNRI as part of the + Computer Science Technical Reports (CSTR) project, funded by the + Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972- + 92-J-1029 and MDA-972-99-1-0018. Design ideas are based on those + discussed within the Handle System development team, including David + Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine + Rey, Stephanie Nguyen, Jason Petrone, and Helen She. Their + contributions to this work are gratefully acknowledged. + + The authors also thank Russ Housley (housley@vigilsec.com), Ted + Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) + for their extensive review and comments, as well as recommendations + received from other members of the IETF/IRTF community. + +8. References and Bibliography + + [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650, + November 2003. + + [2] Mockapetris, P., "Domain Names - Concepts and Facilities," STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [6] Yergeau, F., "UTF-8, A Transform Format for Unicode and + ISO10646", RFC 2279, January 1998. + + [7] The Unicode Consortium, "The Unicode Standard, Version 2.0", + Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9 + + [8] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver + 2.1) Specification", RFC 3652, November 2003. + + [9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource + Locators (URL)", RFC 1738, December 1994. + + + + +Sun, et al. Informational [Page 38] + +RFC 3651 Handle System Service Definition November 2003 + + + [10] Housley, R., Polk, W. Ford, W. and D. Solo, "Internet X.509 + Public Key Infrastructure - Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + + [11] Federal Information Processing Standards Publication (FIPS PUB) + 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 + (supersedes FIPS PUB 46, 1977 January 15). + + [12] Federal Information Processing Standards Publication (FIPS PUB) + 81, DES Modes of Operation, 1980 December 2. + + [13] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: + Part III: Algorithms, Modes, and Identifiers", RFC 1423, + February 1993. + + [14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 1883, December 1995. + + [16] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [17] CNRI Handle System Resolver, http://www.handle.net/resolver + + [18] Grail browser home page, http://grail.sourceforge.net/ + + [19] Python language website, http://www.python.org/ + + [20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993. + + [21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital + Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html + + [23] American National Standards Institute. ANSI X9.52-1998, Triple + Data Encryption Algorithm Modes of Operation. 1998. + + + + + + + + + + +Sun, et al. Informational [Page 39] + +RFC 3651 Handle System Service Definition November 2003 + + +9. Authors' Addresses + + Sam X. Sun + Corporation for National Research Initiatives (CNRI) + 1895 Preston White Dr., Suite 100 + Reston, VA 20191 + + Phone: 703-262-5316 + EMail: ssun@cnri.reston.va.us + + + Sean Reilly + Corporation for National Research Initiatives (CNRI) + 1895 Preston White Dr., Suite 100 + Reston, VA 20191 + + Phone: 703-620-8990 + EMail: sreilly@cnri.reston.va.us + + + Larry Lannom + Corporation for National Research Initiatives (CNRI) + 1895 Preston White Dr., Suite 100 + Reston, VA 20191 + + Phone: 703-620-8990 + EMail: llannom@cnri.reston.va.us + + + + + + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 40] + +RFC 3651 Handle System Service Definition November 2003 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Sun, et al. Informational [Page 41] + |