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.
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
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.
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
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
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
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
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.
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.
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.
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