summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3652.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3652.txt')
-rw-r--r--doc/rfc/rfc3652.txt2971
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc3652.txt b/doc/rfc/rfc3652.txt
new file mode 100644
index 0000000..fcdf895
--- /dev/null
+++ b/doc/rfc/rfc3652.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group S. Sun
+Request for Comments: 3652 S. Reilly
+Category: Informational L. Lannom
+ J. Petrone
+ CNRI
+ November 2003
+
+
+ Handle System Protocol (ver 2.1) Specification
+
+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 its 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 describes the protocol used for client
+ software to access the Handle System for both handle resolution and
+ administration. The protocol specifies the procedure for a client
+ software to locate the responsible handle server of any given handle.
+ It also defines the messages exchanged between the client and server
+ for any handle operation.
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 1]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
+ 2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
+ 2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
+ 2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
+ 2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
+ 2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
+ 2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
+ 2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
+ 2.2.4. Message Credential . . . . . . . . . . . . . . . 18
+ 2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
+ 3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
+ 3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
+ 3.1.1. Global Handle Registry and its Service
+ Information. . . . . . . . . . . . . . . . . . . 21
+ 3.1.2. Locating the Handle System Service Component . . 22
+ 3.1.3. Selecting the Responsible Server . . . . . . . . 23
+ 3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
+ 3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
+ 3.2.2. Successful Query Response. . . . . . . . . . . . 25
+ 3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
+ 3.3. Error Response from Server . . . . . . . . . . . . . . . 26
+ 3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
+ 3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
+ 3.5.1. Challenge from Server to Client. . . . . . . . . 29
+ 3.5.2. Challenge-Response from Client to Server . . . . 30
+ 3.5.3. Challenge-Response Verification-Request. . . . . 33
+ 3.5.4. Challenge-Response Verification-Response . . . . 33
+ 3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
+ 3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
+ 3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
+ 3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
+ 3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
+ 3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
+ 3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
+ 3.7.1. List Handle(s) under a Naming Authority. . . . . 40
+ 3.7.2. List Sub-Naming Authorities under a Naming
+ Authority. . . . . . . . . . . . . . . . . . . . 41
+ 3.8. Session and Session Management . . . . . . . . . . . . . 42
+ 3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
+ 3.8.2. Session Setup Response . . . . . . . . . . . . . 46
+ 3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
+ 3.8.4. Session Termination. . . . . . . . . . . . . . . 48
+
+
+
+
+Sun, et al. Informational [Page 2]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ 4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
+ 4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
+ 4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
+ 7. Informative References . . . . . . . . . . . . . . . . . . . . 50
+ 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
+ 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
+
+1. Overview
+
+ The Handle System provides a general-purpose, secured global name
+ service for the Internet. It was originally conceived and described
+ in a paper by Robert Kahn and Robert Wilensky [18] in 1995. The
+ Handle System defines a client server protocol in which client
+ software submits requests via a network to handle servers. Each
+ request describes the operation to be performed on the server. The
+ server will process the request and return a message indicating the
+ result of the operation. This document specifies the protocol for
+ client software to access a handle server for handle resolution and
+ administration. It does not include the description of the protocol
+ used to manage handle servers. A discussion of the management
+ protocol is out of the scope of this document and will be made
+ available in a separate document. The document assumes that readers
+ are familiar with the basic concepts of the Handle System as
+ introduced in the "Handle System Overview" [1], as well as the data
+ model and service definition given in the "Handle System Namespace
+ and Service Definition" [2].
+
+ The Handle System consists of a set of service components as defined
+ in [2]. From the client's point of view, the Handle System is a
+ distributed database for handles. Different handles under the Handle
+ System may be maintained by different handle servers at different
+ network locations. The Handle protocol specifies the procedure for a
+ client to locate the responsible handle server of any given handle.
+ It also defines the messages exchanged between the client and server
+ for any handle operation.
+
+ Some key aspects of the Handle protocol include:
+
+ o The Handle protocol supports both handle resolution and
+ administration. The protocol follows the data and service
+ model defined in [2].
+
+ o A client may authenticate any server response based on the
+ server's digital signature.
+
+
+
+
+
+Sun, et al. Informational [Page 3]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ o A server may authenticate its client as handle administrator
+ via the Handle authentication protocol. The Handle
+ authentication protocol is a challenge-response protocol that
+ supports both public-key and secret-key based authentication.
+
+ o A session may be established between the client and server so
+ that authentication information and network resources (e.g.,
+ TCP connection) may be shared among multiple operations. A
+ session key can be established to achieve data integrity and
+ confidentiality.
+
+ o The protocol can be extended to support new operations.
+ Controls can be used to extend the existing operations. The
+ protocol is defined to allow future backward compatibility.
+
+ o Distributed service architecture. Support service referral
+ among different service components.
+
+ o Handles and their data types are based on the ISO-10646
+ (Unicode 2.0) character set. UTF-8 [3] is the mandated
+ encoding under the Handle protocol.
+
+ The Handle protocol (version 2.1) specified in this document has
+ changed significantly from its earlier versions. These changes are
+ necessary due to changes made in the Handle System data model and the
+ service model. Servers that implement this protocol may continue to
+ support earlier versions of the protocol by checking the protocol
+ version specified in the Message Envelope (see section 2.2.1).
+
+2. Protocol Elements
+
+2.1. Conventions
+
+ The following conventions are followed by the Handle protocol to
+ ensure interoperability among different implementations.
+
+2.1.1. Data Transmission Order
+
+ The order of transmission of data packets follows the network byte
+ order (also called the Big-Endian [11]). That is, when a data-gram
+ consists of a group of octets, the order of transmission of those
+ octets follows their natural order from left to right and from top to
+ bottom, as they are read in English. For example, in the following
+ diagram, the octets are transmitted in the order they are numbered.
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 4]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ .-------------------------------.
+ | 1 | 2 |
+ |-------------------------------|
+ | 3 | 4 |
+ |-------------------------------|
+ | 5 | 6 |
+ '-------------------------------'
+
+ If an octet represents a numeric quantity, the left most bit is the
+ most significant bit. For example, the following diagram represents
+ the value 170 (decimal).
+
+ 0 1 2 3 4 5 6 7
+ .---------------.
+ |1 0 1 0 1 0 1 0|
+ '---------------'
+
+ Similarly, whenever a multi-octet field represents a numeric
+ quantity, the left most bit is the most significant bit and the most
+ significant octet of the whole field is transmitted first.
+
+2.1.2. Transport Layer
+
+ The Handle protocol is designed so that messages may be transmitted
+ either as separate data-grams over UDP or as a continuous byte stream
+ via a TCP connection. The recommended port number for both UDP and
+ TCP is 2641.
+
+ UDP Usage
+
+ Messages carried by UDP are restricted to 512 bytes (not including
+ the IP or UDP header). Longer messages must be fragmented into
+ UDP packets where each packet carries a proper sequence number in
+ the Message Envelope (see Section 2.2.1).
+
+ The optimum retransmission policy will vary depending on the
+ network or server performance, but the following are recommended:
+
+ o The client should try other servers or service interfaces
+ before repeating a request to the same server address.
+
+ o The retransmission interval should be based on prior
+ statistics if possible. Overly aggressive retransmission
+ should be avoided to prevent network congestion. The
+ recommended retransmission interval is 2-5 seconds.
+
+
+
+
+Sun, et al. Informational [Page 5]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ o When transmitting large amounts of data, TCP-friendly
+ congestion control, such as an interface to the Congestion
+ Manager [12], should be implemented whenever possible to
+ avoid unfair consumption of the bandwidth against TCP-based
+ applications. Details of the congestion control will be
+ discussed in a separate document.
+
+ TCP Usage
+
+ Messages under the Handle protocol can be mapped directly into a
+ TCP byte-stream. However, the size of each message is limited by
+ the range of a 4-byte unsigned integer. Longer messages may be
+ fragmented into multiple messages before the transmission and
+ reassembled at the receiving end.
+
+ Several connection management policies are recommended:
+
+ o The server should support multiple connections and should
+ not block other activities waiting for TCP data.
+
+ o By default, the server should close the connection after
+ completing the request. However, if the request asks to
+ keep the connection open, the server should assume that the
+ client will initiate connection closing.
+
+2.1.3. Character Case
+
+ Handles are character strings based on the ISO-10646 character set
+ and must be encoded in UTF-8. By default, handle characters are
+ treated as case-sensitive under the Handle protocol. A handle
+ service, however, may be implemented in such a way that ASCII
+ characters are processed case-insensitively. For example, the Global
+ Handle Registry (GHR) provides a handle service where ASCII
+ characters are processed in a case-insensitive manner. This suggests
+ that ASCII characters in any naming authority are case-insensitive.
+
+ When handles are created under a case-insensitive handle server,
+ their original case should be preserved. To avoid any confusion, the
+ server should avoid creating any handle whose character string
+ matches that of an existing handle, ignoring the case difference.
+ For example, if the handle "X/Y" was already created, the server
+ should refuse any request to create the handle "x/y" or any of its
+ case variations.
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 6]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.1.4. Standard String Type: UTF8-String
+
+ Handles are transmitted as UTF8-Strings under the Handle protocol.
+ Throughout this document, UTF8-String stands for the data type that
+ consists of a 4-byte unsigned integer followed by a character string
+ in UTF-8 encoding. The leading integer specifies the number of
+ octets of the character string.
+
+2.2. Common Elements
+
+ Each message exchanged under the system protocol consists of four
+ sections (see Fig. 2.2). Some of these sections (e.g., the Message
+ Body) may be empty depending on the protocol operation.
+
+ The Message Envelope must always be present. It has a fixed size of
+ 20 octets. The Message Envelope does not carry any application layer
+ information and is primarily used to help deliver the message.
+ Content in the Message Envelope is not protected by the digital
+ signature in the Message Credential.
+
+ The Message Header must always be present as well. It has a fixed
+ size of 24 octets and holds the common data fields of all messages
+ exchanged between client and server. These include the operation
+ code, the response code, and the control options for each protocol
+ operation. Content in the Message Header is protected by the digital
+ signature in the Message Credential.
+
+ The Message Body contains data specific to each protocol operation.
+ Its format varies according to the operation code and the response
+ code in the Message Header. The Message Body may be empty. Content
+ in the Message Body is protected by the digital signature in the
+ Message Credential.
+
+ The Message Credential provides a mechanism for transport security
+ for any message exchanged between the client and server. A non-empty
+ Message Credential may contain the digital signature from the
+ originator of the message or the one-way Message Authentication Code
+ (MAC) based on a pre-established session key. The Message Credential
+ may be used to authenticate the message between the client and
+ server. It can also be used to check data integrity after its
+ transmission.
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 7]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ .----------------------.
+ | | ; Message wrapper for proper message
+ | Message Envelope | ; delivery. Not protected by the
+ | | ; digital signature in the Message
+ | | ; Credential.
+ |----------------------|
+ | | ; Common data fields for all handle
+ | Message Header | ; operations.
+ | |
+ |----------------------|
+ | | ; Specific data fields for each
+ | Message Body | ; request/response.
+ | |
+ |----------------------|
+ | | ; Contains digital signature or
+ | Message Credential | ; message authentication code (MAC)
+ | | ; upon Message Header and Message
+ '----------------------' ; Body.
+
+ Fig 2.2: Message format under the Handle protocol
+
+2.2.1. Message Envelope
+
+ Each message begins with a Message Envelope under the Handle
+ protocol. If a message has to be truncated before its transmission,
+ each truncated portion must also begin with a Message Envelope.
+
+ The Message Envelope allows the reassembly of the message at the
+ receiving end. It has a fixed size of 20 octets and consists of
+ seven fields:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ .---------------------------------------------------------------.
+ | MajorVersion | MinorVersion | MessageFlag |
+ |---------------------------------------------------------------|
+ | SessionId |
+ |---------------------------------------------------------------|
+ | RequestId |
+ |---------------------------------------------------------------|
+ | SequenceNumber |
+ |---------------------------------------------------------------|
+ | MessageLength |
+ '---------------------------------------------------------------'
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 8]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.2.1.1. <MajorVersion> and <MinorVersion>
+
+ The <MajorVersion> and <MinorVersion> are used to identify the
+ version of the Handle protocol. Each of them is defined as a one-
+ byte unsigned integer. This specification defines the protocol
+ version whose <MajorVersion> is 2 and <MinorVersion> is 1.
+
+ <MajorVersion> and <MinorVersion> are designed to allow future
+ backward compatibility. A difference in <MajorVersion> indicates
+ major variation in the protocol format and the party with the lower
+ <MajorVersion> will have to upgrade its software to ensure precise
+ communication. An increment in <MinorVersion> is made when
+ additional capabilities are added to the protocol without any major
+ change to the message format.
+
+2.2.1.2. <MessageFlag>
+
+ The <MessageFlag> consists of two octets defined as follows:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ .---------------------------------------------------------------.
+ |CP |EC |TC | Reserved |
+ '---------------------------------------------------------------'
+
+ Bit 0 is the CP (ComPressed) flag that indicates whether the message
+ (excluding the Message Envelope) is compressed. If the CP bit is set
+ (to 1), the message is compressed. Otherwise, the message is not
+ compressed. The Handle protocol uses the same compression method as
+ used by the FTP protocol[8].
+
+ Bit 1 is the EC (EnCrypted) flag that indicates whether the message
+ (excluding the Message Envelope) is encrypted. The EC bit should
+ only be set under an established session where a session key is in
+ place. If the EC bit is set (to 1), the message is encrypted using
+ the session key. Otherwise the message is not encrypted.
+
+ Bit 2 is the TC (TrunCated) flag that indicates whether this is a
+ truncated message. Message truncation happens most often when
+ transmitting a large message over the UDP protocol. Details of
+ message truncation (or fragmentation) will be discussed in section
+ 2.3.
+
+ Bits 3 to 15 are currently reserved and must be set to zero.
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 9]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.2.1.3. <SessionId>
+
+ The <SessionId> is a four-byte unsigned integer that identifies a
+ communication session between the client and server.
+
+ Session and its <SessionId> are assigned by a server, either upon an
+ explicit request from a client or when multiple message exchanges are
+ expected to fulfill the client's request. For example, the server
+ will assign a unique <SessionId> in its response if it has to
+ authenticate the client. A client may explicitly ask the server to
+ set up a session as a virtually private communication channel like
+ SSL [4]. Requests from clients without an established session must
+ have their <SessionId> set to zero. The server must assign a unique
+ non-zero <SessionId> for each new session. It is also responsible
+ for terminating those sessions that are not in use after some period
+ of time.
+
+ Both clients and servers must maintain the same <SessionId> for
+ messages exchanged under an established session. A message whose
+ <SessionId> is zero indicates that no session has been established.
+
+ The session and its state information may be shared among multiple
+ handle operations. They may also be shared over multiple TCP
+ connections as well. Once a session is established, both client and
+ server must maintain their state information according to the
+ <SessionId>. The state information may include the stage of the
+ conversation, the other party's authentication information, and the
+ session key that was established for message encryption or
+ authentication. Details of these are discussed in section 3.8.
+
+2.2.1.4. <RequestId>
+
+ Each request from a client is identified by a <RequestId>, a 4-byte
+ unsigned integer set by the client. Each <RequestId> must be unique
+ from all other outstanding requests from the same client. The
+ <RequestId> allows the client to keep track of its requests, and any
+ response from the server must include the correct <RequestId>.
+
+2.2.1.5. <SequenceNumber>
+
+ Messages under the Handle protocol may be truncated during their
+ transmission (e.g., under UDP). The <SequenceNumber> is a 4-byte
+ unsigned integer used as a counter to keep track of each truncated
+ portion of the original message. The message recipient can
+ reassemble the original message based on the <SequenceNumber>. The
+ <SequenceNumber> must start with 0 for each message. Each truncated
+ message must set its TC flag in the Message Envelope. Messages that
+ are not truncated must set their <SequenceNumber> to zero.
+
+
+
+Sun, et al. Informational [Page 10]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.2.1.6. <MessageLen>
+
+ A 4-byte unsigned integer that specifies the total number of octets
+ of any message, excluding those in the Message Envelope. The length
+ of any single message exchanged under the Handle protocol is limited
+ by the range of a 4-byte unsigned integer. Longer data can be
+ transmitted as multiple messages with a common <RequestId>.
+
+2.2.2. Message Header
+
+ The Message Header contains the common data elements among any
+ protocol operation. It has a fixed size of 24 octets and consists of
+ eight fields.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ .---------------------------------------------------------------.
+ | OpCode |
+ |---------------------------------------------------------------|
+ | ResponseCode |
+ |---------------------------------------------------------------|
+ | OpFlag |
+ |---------------------------------------------------------------|
+ | SiteInfoSerialNumber | RecursionCount| |
+ |---------------------------------------------------------------|
+ | ExpirationTime |
+ |---------------------------------------------------------------|
+ | BodyLength |
+ '---------------------------------------------------------------'
+
+ Every message that is not truncated must have a Message Header. If a
+ message has to be truncated for its transmission, the Message Header
+ must appear in the first truncated portion of the message.
+
+ This is different from the Message Envelope, which appears in each
+ truncated portion of the message.
+
+2.2.2.1. <OpCode>
+
+ The <OpCode> stands for operation code, which is a four-byte unsigned
+ integer that specifies the intended operation. The following table
+ lists the <OpCode>s that MUST be supported by all implementations in
+ order to conform to the base protocol specification. Each operation
+ code is given a symbolic name that is used throughout this document
+ for easy reference.
+
+
+
+
+
+
+Sun, et al. Informational [Page 11]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ Op_Code Symbolic Name Remark
+ --------- ------------- ------
+
+ 0 OC_RESERVED Reserved
+ 1 OC_RESOLUTION Handle query
+ 2 OC_GET_SITEINFO Get HS_SITE values
+
+ 100 OC_CREATE_HANDLE Create new handle
+ 101 OC_DELETE_HANDLE Delete existing handle
+ 102 OC_ADD_VALUE Add handle value(s)
+ 103 OC_REMOVE_VALUE Remove handle value(s)
+ 104 OC_MODIFY_VALUE Modify handle value(s)
+ 105 OC_LIST_HANDLE List handles
+ 106 OC_LIST_NA List sub-naming authorities
+
+ 200 OC_CHALLENGE_RESPONSE Response to challenge
+ 201 OC_VERIFY_RESPONSE Verify challenge response
+
+ 300
+ : { Reserved for handle server administration }
+ 399
+
+ 400 OC_SESSION_SETUP Session setup request
+ 401 OC_SESSION_TERMINATE Session termination request
+ 402 OC_SESSION_EXCHANGEKEY Session key exchange
+
+ A detailed description of each of these <OpCode>s can be found in
+ section 3 of this document. In general, clients use the <OpCode> to
+ tell the server what kind of handle operation they want to
+ accomplish. Response from the server must maintain the same <OpCode>
+ as the original request and use the <ResponseCode> to indicate the
+ result.
+
+2.2.2.2. <ResponseCode>
+
+ The <ResponseCode> is a 4-byte unsigned integer that is given by a
+ server to indicate the result of any service request. The list of
+ <ResponseCode>s used in the Handle protocol is defined in the
+ following table. Each response code is given a symbolic name that is
+ used throughout this document for easy reference.
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 12]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ Res. Code Symbolic Name Remark
+ --------- ------------- ------
+
+ 0 RC_RESERVED Reserved for request
+ 1 RC_SUCCESS Success response
+ 2 RC_ERROR General error
+ 3 RC_SERVER_BUSY Server too busy to respond
+ 4 RC_PROTOCOL_ERROR Corrupted or
+ unrecognizable message
+ 5 RC_OPERATION_DENIED Unsupported operation
+ 6 RC_RECUR_LIMIT_EXCEEDED Too many recursions for
+ the request
+
+ 100 RC_HANDLE_NOT_FOUND Handle not found
+ 101 RC_HANDLE_ALREADY_EXIST Handle already exists
+ 102 RC_INVALID_HANDLE Encoding (or syntax) error
+
+ 200 RC_VALUE_NOT_FOUND Value not found
+ 201 RC_VALUE_ALREADY_EXIST Value already exists
+ 202 RC_VALUE_INVALID Invalid handle value
+
+ 300 RC_EXPIRED_SITE_INFO SITE_INFO out of date
+ 301 RC_SERVER_NOT_RESP Server not responsible
+ 302 RC_SERVICE_REFERRAL Server referral
+ 303 RC_NA_DELEGATE Naming authority delegation
+ takes place.
+
+ 400 RC_NOT_AUTHORIZED Not authorized/permitted
+ 401 RC_ACCESS_DENIED No access to data
+ 402 RC_AUTHEN_NEEDED Authentication required
+ 403 RC_AUTHEN_FAILED Failed to authenticate
+ 404 RC_INVALID_CREDENTIAL Invalid credential
+ 405 RC_AUTHEN_TIMEOUT Authentication timed out
+ 406 RC_UNABLE_TO_AUTHEN Unable to authenticate
+
+ 500 RC_SESSION_TIMEOUT Session expired
+ 501 RC_SESSION_FAILED Unable to establish session
+ 502 RC_NO_SESSION_KEY No session yet available
+ 503 RC_SESSION_NO_SUPPORT Session not supported
+ 504 RC_SESSION_KEY_INVALID Invalid session key
+
+ 900 RC_TRYING Request under processing
+ 901 RC_FORWARDED Request forwarded to
+ another server
+ 902 RC_QUEUED Request queued for later
+ processing
+
+
+
+
+
+Sun, et al. Informational [Page 13]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ Response codes under 10000 are reserved for system use. Any message
+ with a response code under 10000 but not listed above should be
+ treated as an unknown error. Response codes above 10000 are user
+ defined and can be used for application specific purposes.
+
+ Detailed descriptions of these <ResponseCode>s can be found in
+ section 3 of this document. In general, any request from a client
+ must have its <ResponseCode> set to 0. The response message from the
+ server must have a non-zero <ResponseCode> to indicate the result.
+ For example, a response message from a server with <ResponseCode> set
+ to RC_SUCCESS indicates that the server has successfully fulfilled
+ the client's request.
+
+2.2.2.3. <OpFlag>
+
+ The <OpFlag> is a 32-bit bit-mask that defines various control
+ options for protocol operation. The following figure shows the
+ location of each option flag in the <OpFlag> field.
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ .---------------------------------------------------------------.
+ |AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved |
+ |---------------------------------------------------------------|
+ | Reserved |
+ '---------------------------------------------------------------'
+
+ AT - AuThoritative bit. A request with the AT bit set (to 1)
+ indicates that the request should be directed to the
+ primary service site (instead of any mirroring sites). A
+ response message with the AT bit set (to 1) indicates
+ that the message is returned from a primary server
+ (within the primary service site).
+
+ CT - CerTified bit. A request with the CT bit set (to 1) asks
+ the server to sign its response with its digital
+ signature. A response with the CT bit set (to 1)
+ indicates that the message is signed. The server must
+ sign its response if the request has its CT bit set (to
+ 1). If the server fails to provide a valid signature in
+ its response, the client should discard the response and
+ treat the request as failed.
+
+ ENC - ENCryption bit. A request with the ENC bit set (to 1)
+ requires the server to encrypt its response using the
+ pre-established session key.
+
+
+
+
+
+Sun, et al. Informational [Page 14]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ REC - RECursive bit. A request with the REC bit set (to 1)
+ asks the server to forward the query on behalf of the
+ client if the request has to be processed by another
+ handle server. The server may honor the request by
+ forwarding the request to the appropriate handle server
+ and passing on any result back to the client. The server
+ may also deny any such request by sending a response
+ with <ResponseCode> set to RC_SERVER_NOT_RESP.
+
+ CA - Cache Authentication. A request with the CA bit set (to
+ 1) asks the caching server (if any) to authenticate any
+ server response (e.g., verifying the server's signature)
+ on behalf of the client. A response with the CA bit set
+ (to 1) indicates that the response has been
+ authenticated by the caching server.
+
+ CN - ContiNuous bit. A message with the CN bit set (to 1)
+ tells the message recipient that more messages that are
+ part of the same request (or response) will follow. This
+ happens if a request (or response) has data that is too
+ large to fit into any single message and has to be
+ fragmented into multiple messages.
+
+ KC - Keep Connection bit. A message with the KC bit set
+ requires the message recipient to keep the TCP
+ connection open (after the response is sent back). This
+ allows the same TCP connection to be used for multiple
+ handle operations.
+
+ PO - Public Only bit. Used by query operations only. A query
+ request with the PO bit set (to 1) indicates that the
+ client is only asking for handle values that have the
+ PUB_READ permission. A request with PO bit set to zero
+ asks for all the handle values regardless of their read
+ permission. If any of the handle values require
+ ADMIN_READ permission, the server must authenticate the
+ client as the handle administrator.
+
+ RD - Request-Digest bit. A request with the RD bit set (to 1)
+ asks the server to include in its response the message
+ digest of the request. A response message with the RD
+ bit set (to 1) indicates that the first field in the
+ Message Body contains the message digest of the original
+ request. The message digest can be used to check the
+ integrity of the server response. Details of these are
+ discussed later in this document.
+
+
+
+
+
+Sun, et al. Informational [Page 15]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ All other bits in the <OpFlag> field are reserved and must be set to
+ zero.
+
+ In general, servers must honor the <OpFlag> specified in the request.
+ If a requested option cannot be met, the server should return an
+ error message with the proper <ResponseCode> as defined in the
+ previous section.
+
+2.2.2.4. <SiteInfoSerialNumber>
+
+ The <SiteInfoSerialNumber> is a two-byte unsigned integer. The
+ <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of
+ the HS_SITE value used by the client (to access the server). Servers
+ can check the <SiteInfoSerialNumber> in the request to find out if
+ the client has up-to-date service information.
+
+ When possible, the server should fulfill a client's request even if
+ the service information used by the client is out-of-date. However,
+ the response message should specify the latest version of service
+ information in the <SiteInforSerialNumber> field. Clients with out-
+ of-date service information can update the service information from
+ the Global Handle Registry. If the server cannot fulfill a client's
+ request due to expired service information, it should reject the
+ request and return an error message with <ResponseCode> set to
+ RC_EXPIRED_SITE_INFO.
+
+2.2.2.5. <RecursionCount>
+
+ The <RecursionCount> is a one-byte unsigned integer that specifies
+ the number of service recursions. Service recursion happens if the
+ server has to forward the client's request to another server. Any
+ request directly from the client must have its <RecursionCount> set
+ to 0. If the server has to send a recursive request on behalf of the
+ client, it must increment the <RecursionCount> by 1. Any response
+ from the server must maintain the same <RecursionCount> as the one in
+ the request. To prevent an infinite loop of service recursion, the
+ server should be configurable to stop sending a recursive request
+ when the <RecursionCount> reaches a certain value.
+
+2.2.2.6. <ExpirationTime>
+
+ The <ExpirationTime> is a 4-byte unsigned integer that specifies the
+ time when the message should be considered expired, relative to
+ January 1st, 1970 GMT, in seconds. It is set to zero if no
+ expiration is expected.
+
+
+
+
+
+
+Sun, et al. Informational [Page 16]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.2.2.7. <BodyLength>
+
+ The <BodyLength> is a 4-byte unsigned integer that specifies the
+ number of octets in the Message Body. The <BodyLength> does not
+ count the octets in the Message Header or those in the Message
+ Credential.
+
+2.2.3. Message Body
+
+ The Message Body always follows the Message Header. The number of
+ octets in the Message Body can be determined from the <BodyLength> in
+ the Message Header. The Message Body may be empty. The exact format
+ of the Message Body depends on the <OpCode> and the <ResponseCode> in
+ the Message Header. Details of the Message Body under each <OpCode>
+ and <ResponseCode> are described in section 3 of this document.
+
+ For any response message, if the Message Header has its RD bit (in
+ <OpFlag>) set to 1, the Message Body must begin with the message
+ digest of the original request. The message digest is defined as
+ follows:
+
+ <RequestDigest> ::= <DigestAlgorithmIdentifier>
+ <MessageDigest>
+
+ where
+
+ <DigestAlgorithmIdentifier>
+ An octet that identifies the algorithm used to generate the
+ message digest. If the octet is set to 1, the digest is
+ generated using the MD5 [9] algorithm. If the octet is set
+ to 2, SHA-1 [10] algorithm is used.
+
+ <MessageDigest>
+ The message digest itself. It is calculated upon the
+ Message Header and the Message Body of the original request.
+ The length of the field is fixed according to the digest
+ algorithm. For MD5 algorithm, the length is 16 octets. For
+ SHA-1, the length is 20 octets.
+
+ The Message Body may be truncated into multiple portions during its
+ transmission (e.g., over UDP). Recipients of such a message may
+ reassemble the Message Body from each portion based on the
+ <SequenceNumber> in the Message Envelope.
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 17]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+2.2.4. Message Credential
+
+ The Message Credential is primarily used to carry any digital
+ signatures signed by the message issuer. It may also carry the
+ Message Authentication Code (MAC) if a session key has been
+ established. The Message Credential is used to protect contents in
+ the Message Header and the Message Body from being tampered with
+ during transmission. The format of the Message Credential is
+ designed to be semantically compatible with PKCS#7 [5]. Each Message
+ Credential consists of the following fields:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ .---------------------------------------------------------------.
+ | CredentialLength |
+ |---------------------------------------------------------------|
+ | Version | Reserved | Options |
+ |---------------------------------------------------------------|
+ |
+ | Signer: <Handle, Index>
+ |
+ |---------------------------------------------------------------|
+ | Type (UTF8-String) |
+ |---------------------------------------------------------------|
+ |
+ | SignedInfo: <Length> : 4-byte unsigned integer
+ | DigestAlgorithm: <UTF8-String>
+ | SignedData: <Length, Signature>
+ |
+ '---------------------------------------------------------------'
+
+ where
+
+ <CredentialLength>
+ A 4-byte unsigned integer that specifies the number of octets in
+ the Message Credential. It must be set to zero if the message has
+ no Message Credential.
+
+ <Version>
+ An octet that identifies the version number of the Message
+ Credential. The version number specified in this document is
+ zero.
+
+ <Reserved>
+ An octet that must be set to zero.
+
+ <Options>
+ Two octets reserved for various cryptography options.
+
+
+
+Sun, et al. Informational [Page 18]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+
+ <Signer> ::= <HANDLE>
+ <INDEX>
+ A reference to a handle value in terms of the <HANDLE> and the
+ <INDEX> of the handle value. The handle value may contain the
+ public key, or the X.509 certificate, that can be used to
+ validate the digital signature.
+
+ <Type>
+ A UTF8-String that indicates the type of content in the
+ <SignedInfo> field (described below). It may contain HS_DIGEST if
+ <SignedInfo> contains the message digest, or HS_MAC if
+ <SignedInfo> contains the Message Authentication Code (MAC). The
+ <Type> field will specify the signature algorithm identifier if
+ <SignedInfo> contains a digital signature. For example, with the
+ <Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will
+ contain the digital signature generated using the RSA-PSS
+ algorithm [16]. If the <Type> field is set to HS_SIGNED, the
+ <SignedInfo> field will contain the digital signature generated
+ from a DSA public key pair.
+
+ <SignedInfo> ::= <Length>
+ <DigestAlgorithm>
+ <SignedData>
+ where
+
+ <Length>
+ A 4-byte unsigned integer that specifies the number of
+ octets in the <SignedInfo> field.
+
+ <DigestAlgorithm>
+ A UTF8-String that refers to the digest algorithm used to
+ generate the digital signature. For example, the value
+ "SHA-1" indicates that the SHA-1 algorithm is used to
+ generate the message digest for the signature.
+
+ <SignedData> ::= <LENGTH>
+ <SIGNATURE>
+ where
+
+ <LENGTH>
+ A 4-byte unsigned integer that specifies the number of
+ octets in the <SIGNATURE>.
+
+ <SIGNATURE>
+ Contains the digital signature or the MAC over the
+ Message Header and Message Body. The syntax and
+ semantics of the signature depend on the <Type> field
+
+
+
+Sun, et al. Informational [Page 19]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ and the public key referenced in the <Signer> field.
+ For example, if the <Type> field is "HS_SIGNED" and
+ the public key referred to by the <Signer> field is
+ a DSA [6] public key, the signature will be the
+ ASN.1 octet string representation of the parameter R
+ and S as described in [7]. If the <Signer> field
+ refers to a handle value that contains a X.509
+ certificate, the signature should be encoded according
+ to RFC 3279 and RFC 3280 [14, 15].
+
+ The Message Credential may contain the message authentication code
+ (MAC) generated using a pre-established session key. In this case,
+ the <Signer> field must set its <HANDLE> to a zero-length UTF8-String
+ and its <INDEX> to the <SessionId> specified in the Message Envelope.
+ The <Signature> field must contain the MAC in its <SIGNATURE> field.
+ The MAC is the result of the one-way hash over the concatenation of
+ the session key, the <Message Header>, the <MessageBody>, and the
+ session key again.
+
+ The Message Credential in a response message may contain the digital
+ signature signed by the server. The server's public key can be found
+ in the service information used by the client to send the request to
+ the server. In this case, the client should ignore any reference in
+ the <Signer> field and use the public key in the service information
+ to verify the signature.
+
+ The Message Credential can also be used for non-repudiation purposes.
+ This happens if the Message Credential contains a server's digital
+ signature. The signature may be used as evidence to demonstrate that
+ the server has rendered its service in response to a client's
+ request.
+
+ The Message Credential provides a mechanism for safe transmission of
+ any message between the client and server. Any message whose Message
+ Header and Message Body complies with its Message Credential suggests
+ that the message indeed comes from its originator and assures that
+ the message has not been tampered with during its transmission.
+
+2.3. Message Transmission
+
+ A large message may be truncated into multiple packets during its
+ transmission. For example, to fit the size limit of a UDP packet,
+ the message issuer must truncate any large message into multiple UDP
+ packets before its transmission. The message recipient must
+ reassemble the message from these truncated packets before further
+ processing. Message truncation must be carried out over the entire
+
+
+
+
+
+Sun, et al. Informational [Page 20]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ message except the Message Envelope. A new Message Envelope has to
+ be inserted in front of each truncated packet before its
+ transmission. For example, a large message that consists of
+
+ .--------------------------------------------------------.
+ | Message Envelope | Message Header, Body, Credential |
+ '--------------------------------------------------------'
+
+ may be truncated into:
+
+ .--------------------------------------------.
+ | Message Envelope 1 | Truncated_Packet 1 |
+ '--------------------------------------------'
+ .--------------------------------------------.
+ | Message Envelope 2 | Truncated_Packet 2 |
+ '--------------------------------------------'
+
+ ......
+
+ .--------------------------------------------.
+ | Message Envelope N | Truncated Packet N |
+ '--------------------------------------------'
+
+ where the "Truncated_packet 1", "Truncated_packet 2", ..., and
+ "Truncated_packet N" result from truncating the Message Header, the
+ Message Body and the Message Credential. Each "Message Envelope i"
+ (inserted before each truncation) must set its TC flag to 1 and
+ maintain the proper sequence count (in the <SequenceNumber>). Each
+ "Message Envelope i" must also set its <MessageLength> to reflect the
+ size of the packet. The recipient of these truncated packets can
+ reassemble the message by concatenating these packets based on their
+ <SequenceNumber>.
+
+3. Handle Protocol Operations
+
+ This section describes the details of each protocol operation in
+ terms of messages exchanged between the client and server. It also
+ defines the format of the Message Body according to each <OpCode> and
+ <ResponseCode> in the Message Header.
+
+3.1. Client Bootstrapping
+
+3.1.1. Global Handle Registry and its Service Information
+
+ The service information for the Global Handle Registry (GHR) allows
+ clients to contact the GHR to find out the responsible service
+ components for their handles. The service information is a set of
+ HS_SITE values assigned to the root handle "0.NA/0.NA" and is also
+
+
+
+Sun, et al. Informational [Page 21]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ called the root service information. The root service information
+ may be distributed along with the client software, or be downloaded
+ from the Handle System website at http://www.handle.net.
+
+ Changes to the root service information are identified by the
+ <SerialNumber> in the HS_SITE values. A server at GHR can find out
+ if the root service information used by the client is outdated by
+ checking the <SerialNumber> in the client's request. The client
+ should update the root service information if the <ResponseCode> of
+ the response message is RC_EXPIRED_SITE_INFO. Clients may obtain the
+ most up-to-date root service information from the root handle. The
+ GHR must sign the root service information using the public key
+ specified in the outdated service information (identified in the
+ client's request) so that the client can validate the signature.
+
+3.1.2. Locating the Handle System Service Component
+
+ Each handle under the Handle System is managed by a unique handle
+ service component (e.g., LHS). For any given handle, the responsible
+ service component (and its service information) can be found from its
+ naming authority handle. Before resolving any given handle, the
+ client needs to find the responsible service component by querying
+ the naming authority handle from the GHR.
+
+ For example, to find the responsible LHS for the handle "1000/abc",
+ client software can query the GHR for the HS_SITE (or HS_SERV) values
+ assigned to the naming authority handle "0.NA/1000". The set of
+ HS_SITE values provides the service information of the LHS that
+ manages every handle under the naming authority "1000". If no
+ HS_SITE values are found, the client can check if there is any
+ HS_SERV value assigned to the naming authority handle. The HS_SERV
+ value provides the service handle that maintains the service
+ information for the LHS. Service handles are used to manage the
+ service information shared by different naming authorities.
+
+ It is possible that the naming authority handle requested by the
+ client does not reside at the GHR. This happens when naming
+ authority delegation takes place. Naming authority delegation
+ happens when a naming authority delegates an LHS to manage all its
+ child naming authorities. In this case, the delegating naming
+ authority must contain the service information, a set of
+ HS_NA_DELEGATE values, of the LHS that manages its child naming
+ authorities.
+
+ All top-level naming authority handles must be registered and managed
+ by the GHR. When a server at the GHR receives a request for a naming
+ authority that has been delegated to an LHS, it must return a message
+ with the <ResponseCode> set to RC_NA_DELEGATE, along with the
+
+
+
+Sun, et al. Informational [Page 22]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ HS_NA_DELAGATE values from the nearest ancestor naming authority.
+ The client can query the LHS described by the HS_NA_DELAGATE values
+ for the delegated naming authority handle. In practice, the ancestor
+ naming authority should make itself available to any handle server
+ within the GHR, by replicating itself at the time of delegation.
+ This will prevent any cross-queries among handle servers (within a
+ service site) when the naming authority in query and the ancestor
+ naming authority do not hash into the same handle server.
+
+3.1.3. Selecting the Responsible Server
+
+ Each handle service component is defined in terms of a set of HS_SITE
+ values. Each of these HS_SITE values defines a service site within
+ the service component. A service site may consist of a group of
+ handle servers. For any given handle, the responsible handle server
+ within the service component can be found following this procedure:
+
+ 1. Select a preferred service site.
+
+ Each service site is defined in terms of an HS_SITE value. The
+ HS_SITE value may contain a <Description> or other attributes
+ (under the <AttributeList>) to help the selection. Clients
+ must select the primary service site for any administrative
+ operations.
+
+ 2. Locate the responsible server within the service site.
+
+ This can be done as follows: Convert every ASCII character in
+ the handle to its upper case. Calculate the MD5 hash of the
+ converted handle string according to the <HashOption> given in
+ the HS_SITE value. Take the last 4 bytes of the hash result as
+ a signed integer. Modulo the absolute value of the integer by
+ the <NumOfServer> given in the HS_SITE value. The result is
+ the sequence number of the <ServerRecord> listed in the HS_SITE
+ value. For example, if the result of the modulation is 2, the
+ third <ServerRecord> listed in the <HS_SITE> should be
+ selected. The <ServerRecord> defines the responsible handle
+ server for the given handle.
+
+3.2. Query Operation
+
+ A query operation consists of a client sending a query request to the
+ responsible handle server and the server returning the query result
+ to the client. Query requests are used to retrieve handle values
+ assigned to any given handle.
+
+
+
+
+
+
+Sun, et al. Informational [Page 23]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+3.2.1. Query Request
+
+ The Message Header of any query request must set its <OpCode> to
+ OC_RESOLUTION (defined in section 2.2.2.1) and <ResponseCode> to 0.
+
+ The Message Body for any query request is defined as follows:
+
+ <Message Body of Query Request> ::= <Handle>
+ <IndexList>
+ <TypeList>
+
+ where
+
+ <Handle>
+ A UTF8-String (as defined in section 2.1.4) that specifies
+ the handle to be resolved.
+
+ <IndexList>
+ A 4-byte unsigned integer followed by an array of 4-byte
+ unsigned integers. The first integer indicates the number
+ of integers in the integer array. Each number in the
+ integer array is a handle value index and refers to a handle
+ value to be retrieved. The client sets the first integer to
+ zero (followed by an empty array) to ask for all the handle
+ values regardless of their index.
+
+ <TypeList>
+ A 4-byte unsigned integer followed by a list of UTF8-
+ Strings. The first integer indicates the number of
+ UTF8-Strings in the list that follows. Each UTF8-String in
+ the list specifies a data type. This tells the server to
+ return all handle values whose data type is listed in the
+ list. If a UTF8-String ends with the '.' (0x2E) character,
+ the server must return all handle values whose data type is
+ under the type hierarchy specified in the UTF8-String. The
+ <TypeList> may contain no UTF8-String if the first integer
+ is 0. In this case, the server must return all handle
+ values regardless of their data type.
+
+ If a query request does not specify any index or data type and the PO
+ flag (in the Message Header) is set, the server will return all the
+ handle values that have the PUBLIC_READ permission. Clients can also
+ send queries without the PO flag set. In this case, the server will
+ return all the handle values with PUBLIC_READ permission and all the
+ handle values with ADMIN_READ permission. If the query requests a
+ specific handle value via the value index and the value does not have
+ PUBLIC_READ permission, the server should accept the request (and
+ authenticate the client) even if the request has its PO flag set.
+
+
+
+Sun, et al. Informational [Page 24]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ If a query consists of a non-empty <IndexList> but an empty
+ <TypeList>, the server should only return those handle values whose
+ indexes are listed in the <IndexList>. Likewise, if a query consists
+ of a non-empty <TypeList> but an empty <IndexList>, the server should
+ only return those handle values whose data types are listed in the
+ <TypeList>.
+
+ When both <IndexList> and <TypeList> fields are non-empty, the server
+ should return all handle values whose indexes are listed in the
+ <IndexList> AND all handle values whose data types are listed in the
+ <TypeList>.
+
+3.2.2. Successful Query Response
+
+ The Message Header of any query response must set its <OpCode> to
+ OC_RESOLUTION. A successful query response must set its
+ <ResponseCode> to RC_SUCCESS.
+
+ The message body of the successful query response is defined as
+ follows:
+
+ <Message Body of Successful Query Response> ::= [<RequestDigest>]
+ <Handle>
+ <ValueList>
+
+ where
+
+ <RequestDigest>
+ Optional field as defined in section 2.2.3.
+
+ <Handle>
+ A UTF8-String that specifies the handle queried by the
+ client.
+
+ <ValueList>
+ A 4-byte unsigned integer followed by a list of handle
+ values. The integer specifies the number of handle values
+ in the list. The encoding of each handle value follows the
+ specification given in [2] (see section 3.1). The integer
+ is set to zero if there is no handle value that satisfies
+ the query.
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 25]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+3.2.3. Unsuccessful Query Response
+
+ If a server cannot fulfill a client's request, it must return an
+ error message. The general format for any error message from the
+ server is specified in section 3.3 of this document.
+
+ For example, a server must return an error message if the queried
+ handle does not exist in its database. The error message will have
+ an empty message body and have its <ResponseCode> set to
+ RC_HANDLE_NOT_FOUND.
+
+ Note that a server should NOT return an RC_HANDLE_NOT_FOUND message
+ if the server is not responsible for the handle being queried. It is
+ possible that the queried handle exists but is managed by another
+ handle server (under some other handle service). When this happens,
+ the server should either send a service referral (see section 3.4) or
+ simply return an error message with <ResponseCode> set to
+ RC_SERVER_NOT_RESP.
+
+ The server may return an error message with <ResponseCode> set to
+ RC_SERVER_BUSY if the server is too busy to process the request.
+ Like RC_HANDLE_NOT_FOUND, an RC_SERVER_BUSY message also has an empty
+ message body.
+
+ Servers should return an RC_ACCESS_DENIED message if the request asks
+ for a specific handle value (via the handle value index) that has
+ neither PUBLIC_READ nor ADMIN_READ permission.
+
+ A handle Server may ask its client to authenticate itself as the
+ handle administrator during the resolution. This happens if any
+ handle value in query has ADMIN_READ permission, but no PUBLIC_READ
+ permission. Details of client authentication are described later in
+ this document.
+
+3.3. Error Response from Server
+
+ A handle server will return an error message if it encounters an
+ error when processing a request. Any error response from the server
+ must maintain the same <OpCode> (in the message header) as the one in
+ the original request. Each error condition is identified by a unique
+ <ResponseCode> as defined in section 2.2.2.2 of this document.
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 26]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ The Message Body of an error message may be empty. Otherwise it
+ consists of the following data fields (unless otherwise specified):
+
+ <Message Body of Error Response from Server> ::= [<RequestDigest>]
+ <ErrorMessage>
+ [ <IndexList> ]
+
+ where
+
+ <RequestDigest>
+ Optional field as defined in section 2.2.3.
+
+ <ErrorMessage>
+ A UTF8-String that explains the error.
+
+ <IndexList>
+ An optional field. When not empty, it consists of a 4-byte
+ unsigned integer followed by a list of handle value indexes.
+ The first integer indicates the number of indexes in the
+ list. Each index in the list is a 4-byte unsigned integer
+ that refers to a handle value that contributed to the error.
+ An example would be a server that is asked to add three
+ handle values, with indexes 1, 2, and 3, and handle values
+ with indexes of 1 and 2 already in existence. In this case,
+ the server could return an error message with <REsponseCode>
+ set to RC_VALUE_ALREADY_EXIST and add index 1 and 2 to the
+ <IndexList>. Note that the server is not obligated to
+ return the complete list of handle value indexes that may
+ have caused the error.
+
+3.4. Service Referral
+
+ A handle server may receive requests for handles that are managed by
+ some other handle server or service. When this happens, the server
+ has the option to either return a referral message that directs the
+ client to the proper handle service, or simply return an error
+ message with <ResponseCode> set to RC_SERVER_NOT_RESP. Service
+ referral also happens when ownership of handles moves from one handle
+ service to another. It may also be used by any local handle service
+ to delegate its service into multiple service layers.
+
+ The Message Header of a service referral must maintain the same
+ <OpCode> as the one in the original request and set its
+ <ResponseCode> to RC_SERVICE_REFERRAL.
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 27]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ The Message Body of any service referral is defined as follows:
+
+ <Message Body of Service Referral> ::= [ <RequestDigest> ]
+ <ReferralHandle>
+ [ <ValueList> ]
+
+ where
+
+ <RequestDigest>
+ Optional field as defined in section 2.2.3.
+
+ <ReferralHandle>
+ A UTF8-String that identifies the handle (e.g., a service
+ handle) that maintains the referral information (i.e., the
+ service information of the handle service in which this
+ refers). If the <ReferralHandle> is set to "0.NA/0.NA",
+ it is referring the client to the GHR.
+
+ <ValueList>
+ An optional field that must be empty if the <ReferralHandle>
+ is provided. When not empty, it consists of a 4-byte
+ unsigned integer, followed by a list of HS_SITE values. The
+ integer specifies the number of HS_SITE values in the list.
+
+ Unlike regular query responses that may consist of handle values of
+ any data type, a service referral can only have zero or more HS_SITE
+ values in its <ValueList>. The <ReferralHandle> may contain an empty
+ UTF8-String if the HS_SITE values in the <ValueList> are not
+ maintained by any handle.
+
+ Care must be taken by clients to avoid any loops caused by service
+ referrals. It is also the client's responsibility to authenticate
+ the service information obtained from the service referral. A client
+ should always use its own copy of the GHR service information if the
+ <ReferralHandle> is set to "0.NA/0.NA".
+
+3.5. Client Authentication
+
+ Clients are asked to authenticate themselves as handle administrators
+ when querying for any handle value with ADMIN_READ but no PUBLIC_READ
+ permission. Client authentication is also required for any handle
+ administration requests that require administrator privileges. This
+ includes adding, removing, or modifying handles or handle values.
+
+ Client authentication consists of multiple messages exchanged between
+ the client and server. Such messages include the challenge from the
+ server to the client to authenticate the client, the challenge-
+ response from the client in response to the server's challenge, and
+
+
+
+Sun, et al. Informational [Page 28]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ the verification request and response message if secret key
+ authentication takes place. Messages exchanged during the
+ authentication are correlated via a unique <SessionId> assigned by
+ the server. For each authentication session, the server needs to
+ maintain the state information that includes the server's challenge,
+ the challenge-response from the client, as well as the original
+ client request.
+
+ The authentication starts with a response message from the server
+ that contains a challenge to the client. The client must respond to
+ the challenge with a challenge-response message. The server
+ validates the challenge-response, either by verifying the digital
+ signature inside the challenge-response, or by sending a verification
+ request to another handle server (herein referred to as the
+ verification server), that maintains the secret key for the
+ administrator. The purpose of the challenge and the challenge-
+ response is to prove to the server that the client possesses the
+ private key (or the secret key) of the handle administrator. If the
+ authentication fails, an error response will be sent back with the
+ <ResponseCode> set to RC_AUTHEN_FAILED.
+
+ Upon successful client authentication, the server must also make sure
+ that the administrator is authorized for the request. If the
+ administrator has sufficient privileges, the server will process the
+ request and send back the result. If the administrator does not have
+ sufficient privileges, the server will return an error message with
+ <ResponseCode> set to RC_NOT_AUTHORIZED.
+
+ The following sections provide details of each message exchanged
+ during the authentication process.
+
+3.5.1. Challenge from Server to Client
+
+ The Message Header of the CHALLENGE must keep the same <OpCode> as
+ the original request and set the <ResponseCode> to RC_AUTH_NEEDED.
+ The server must assign a non-zero unique <SessionId> in the Message
+ Envelope to keep track of the authentication. It must also set the
+ RD flag of the <OpFlag> (see section 2.2.2.3) in the Message Header,
+ regardless of whether the original request had the RD bit set or not.
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 29]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ The Message Body of the server's CHALLENGE is defined as follows:
+
+ <Message Body of Server's Challenge> ::= <RequestDigest>
+ <Nonce>
+ where
+
+ <RequestDigest>
+ Message Digest of the request message, as defined in section
+ 2.2.3.
+
+ <Nonce>
+ A 4-byte unsigned integer followed by a random string
+ generated by the server via a secure random number
+ generator. The integer specifies the number of octets in
+ the random string. The size of the random string should be
+ no less than 20 octets.
+
+ Note that the server will not sign the challenge if the client did
+ not request the server to do so. If the client worries about whether
+ it is speaking to the right server, it may ask the server to sign the
+ <Challenge>. If the client requested the server to sign the
+ <Challenge> but failed to validate the server's signature, the client
+ should discard the server's response and reissue the request to the
+ server.
+
+3.5.2. Challenge-Response from Client to Server
+
+ The Message Header of the CHALLENGE_RESPONSE must set its <OpCode> to
+ OC_CHALLENGE_RESPONSE and its <ResponseCode> to 0. It must also keep
+ the same <SessionId> (in the Message Envelope) as specified in the
+ challenge from the server.
+
+ The Message Body of the CHALLENGE_RESPONSE request is defines as
+ follows:
+
+ <Message Body of CHALLENGE_RESPONSE> ::= <AuthenticationType>
+ <KeyHandle>
+ <KeyIndex>
+ <ChallengeResponse>
+
+ where
+
+ <AuthenticationType>
+ A UTF8-String that identifies the type of authentication key
+ used by the client. For example, the field is set to
+ "HS_SECKEY" if the client chooses to use a secret key for
+ its authentication. The field is set to "HS_PUBKEY" if a
+ public key is used instead.
+
+
+
+Sun, et al. Informational [Page 30]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+
+ <KeyHandle>
+ A UTF8-String that identifies the handle that holds the
+ public or secret key of the handle administrator.
+
+ <KeyIndex>
+ A 4-byte unsigned integer that specifies the index of the
+ handle value (of the <KeyHandle>) that holds the public or
+ secret key of the administrator.
+
+ <ChallengeResponse>
+ Contains either the Message Authentication Code (MAC) or the
+ digital signature over the challenge from the server. If
+ the <AuthenticationType> is "HS_SECKEY", the
+ <ChallengeResponse> consists of an octet followed by the
+ MAC. The octet identifies the algorithm used to generate
+ the MAC. For example, if the first octet is set to 0x01,
+ the MAC is generated by
+
+ MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
+
+ where the <SecretKey> is the administrator's secret key
+ referenced by the <KeyHandle> and <KeyIndex>. The
+ <ServerChallenge> is the Message Body portion of the
+ server's challenge. If the first octet in the
+ <ChallengeResponse> is set to 0x02, the MAC is generated
+ using
+
+ SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
+
+ A more secure approach is to use HMAC [17] for the
+ <ChallengeResponse>. The HMAC can be generated using the
+ <SecretKey> and <ServerChallenge>. A <ChallengeResponse>
+ with its first octet set to 0x11 indicates that the HMAC
+ is generated using the MD5 algorithm. Likewise, a
+ <ChallengeResponse> with its first octet set to 0x12
+ indicates that the HMAC is generated using the SHA-1
+ algorithm.
+
+ If the <AuthenticationType> is "HS_PUBKEY", the
+ <ChallengeResponse> contains the digital signature over the
+ Message Body portion of the server's challenge. The
+ signature is generated in two steps: First, a one-way hash
+ value is computed over the blob that is to be signed.
+ Second, the hash value is signed using the private key.
+ The signature consists of a UTF8-String that specifies the
+ digest algorithm used for the signature, followed by the
+ signature over the server's challenge. The <KeyHandle> and
+
+
+
+Sun, et al. Informational [Page 31]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <KeyIndex> refers to the administrator's public key that can
+ be used to verify the signature.
+
+ Handle administrators are defined in terms of HS_ADMIN values
+ assigned to the handle. Each HS_ADMIN value defines the set of
+ privileges granted to the administrator. It also provides the
+ reference to the authentication key that can be used to authenticate
+ the administrator. The reference can be made directly if the
+ <AdminRef> field of the HS_ADMIN value refers to the handle value
+ that holds the authentication key. Indirect reference to the
+ authentication key can also be made via administrator groups. In
+ this case, the <AdminRef> field may refer to a handle value of type
+ HS_VLIST. An HS_VLIST value defines an administrator group via a
+ list of handle value references, each of which refers to the
+ authentication key of a handle administrator.
+
+ For handles with multiple HS_ADMIN values, the server will have to
+ check each of those with sufficient privileges to see if its
+ <AdminRef> field matches the <KeyHandle> and <KeyIndex>. If no match
+ is found, but there are administrator groups defined, the server must
+ check if the <KeyHandle> and <KeyIndex> belong to any of the
+ administrator groups that have sufficient privileges. An
+ administrator group may contain another administrator group as a
+ member. Servers must be careful to avoid infinite loops when
+ navigating these groups.
+
+ If the <KeyHandle> and <KeyIndex> are not referenced by any of the
+ HS_ADMIN values, or the administrator group that has sufficient
+ privileges, the server will return an error message with
+ <ResponseCode> set to RC_NOT_AUTHORIZED. Otherwise, the server will
+ continue to authenticate the client as follows:
+
+ If the <AuthenticationType> is "HS_PUBKEY", the server will retrieve
+ the administrator's public key based on the <KeyHandle> and
+ <KeyIndex>. The public key can be used to verify the
+ <ChallengeResponse> against the server's <Challenge>. If the
+ <ChallengeResponse> matches the <Challenge>, the server will continue
+ to process the original request and return the result. Otherwise,
+ the server will return an error message with <ResponseCode> set to
+ RC_AUTHENTICATION_FAILED.
+
+ If the <AuthenticationType> is "HS_SECKEY", the server will have to
+ send a verification request to the verification server; that is, the
+ handle server that manages the handle referenced by the <KeyHandle>.
+ The verification request and its response are defined in the
+ following sections. The verification server will verify the
+ <ChallengeResponse> against the <Challenge> on behalf of the handle
+ server.
+
+
+
+Sun, et al. Informational [Page 32]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+3.5.3. Challenge-Response Verification-Request
+
+ The message header of the VERIFICATION_REQUEST must set its <OpCode>
+ to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
+
+ The message body of the Verification-Request is defined as follows:
+
+ <Message Body of VERIFICATION_REQUEST> ::= <KeyHandle>
+ <KeyIndex>
+ <Challenge>
+ <ChallengeResponse>
+
+ where
+
+ <KeyHandle>
+ A UTF8-String that refers to the handle that holds the
+ secret key of the administrator.
+
+ <KeyIndex>
+ A 4-byte unsigned integer that is the index of the handle
+ value that holds the secret key of the administrator.
+
+ <Challenge>
+ The message body of the server's challenge, as described in
+ section 3.5.1.
+
+ <ChallengeResponse>
+ The <ChallengeResponse> from the client in response to
+ the server's <Challenge>, as defined in section 3.5.2.
+
+ Any Challenge-Response Verification-Request must set its CT bit in
+ the message header. This is to ensure that the verification server
+ will sign the Verification-Response as specified in the next section.
+
+3.5.4. Challenge-Response Verification-Response
+
+ The Verification-Response tells the requesting handle server whether
+ the <ChallengeResponse> matches the <Challenge> in the Verification-
+ Request.
+
+ The Message Header of the Verification-Response must set its
+ <ResponseCode> to RC_SUCCESS whether or not the <ChallengeResponse>
+ matches the <Challenge>. The RD flag in the <OpFlag> field should
+ also be set (to 1) since the <RequestDigist> will be mandatory in the
+ Message Body.
+
+
+
+
+
+
+Sun, et al. Informational [Page 33]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ The Message Body of the Verification-Response is defined as follows:
+
+ <Challenge-Response Verification-Response>
+ ::= <RequestDigest>
+ <VerificationResult>
+ where
+
+ <RequestDigest>
+ Contains the message digest of the Verification-Request.
+
+ <VerificationResult>
+ An octet that is set to 1 if the <ChallengeResponse>
+ matches the <Challenge>. Otherwise it must be set to
+ 0.
+
+ The verification server may return an error with <ResponseCode> set
+ to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the
+ <KeyHandle> does not exist, or the <KeyHandle> and <KeyIndex> refer
+ to an invalid handle value). When this happens, the server that
+ performs the client authentication should relay the same error
+ message back to the client.
+
+3.6. Handle Administration
+
+ The Handle System protocol supports a set of handle administration
+ functions that include adding, deleting, and modifying handles or
+ handle values. Before fulfilling any administration request, the
+ server must authenticate the client as the handle administrator that
+ is authorized for the administrative operation. Handle
+ administration can only be carried out by the primary handle server.
+
+3.6.1. Add Handle Value(s)
+
+ Clients add values to existing handles by sending ADD_VALUE requests
+ to the responsible handle server. The Message Header of the
+ ADD_VALUE request must set its <OpCode> to OC_ADD_VALUE.
+
+ The Message Body of the ADD_VALUE request is encoded as follows:
+
+ <Message Body of ADD_VALUE Request> ::= <Handle>
+ <ValueList>
+
+ where
+
+ <Handle>
+ A UTF8-String that specifies the handle.
+
+
+
+
+
+Sun, et al. Informational [Page 34]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <ValueList>
+ A 4-byte unsigned integer followed by a list of handle
+ values. The integer indicates the number of handle values
+ in the list.
+
+ The server that receives the ADD_VALUE request must first
+ authenticate the client as the administrator with the ADD_VALUE
+ privilege. Upon successful authentication, the server will proceed
+ to add each value in the <ValueList> to the <Handle>. If successful,
+ the server will return an RC_SUCCESS message to the client.
+
+ Each ADD_VALUE request must be carried out as a transaction. If
+ adding any value in the <ValueList> raises an error, the entire
+ operation must be rolled back. For any failed ADD_VALUE request,
+ none of the values in the <ValueList> should be added to the
+ <Handle>. The server must also send a response to the client that
+ explains the error. For example, if a value in the <ValueList> has
+ the same index as one of the existing handle values, the server will
+ return an error message that has the <ResponseCode> set to
+ RC_VALUE_ALREADY_EXISTS.
+
+ ADD_VALUE requests can also be used to add handle administrators.
+ This happens if the <ValueList> in the ADD_VALUE request contains any
+ HS_ADMIN values. The server must authenticate the client as an
+ administrator with the ADD_ADMIN privilege before fulfilling such
+ requests.
+
+ An ADD_VALUE request will result in an error if the requested handle
+ does not exist. When this happens, the server will return an error
+ message with <ResponseCode> set to RC_HANDLE_NOT_EXIST.
+
+3.6.2. Remove Handle Value(s)
+
+ Clients remove existing handle values by sending REMOVE_VALUE
+ requests to the responsible handle server. The Message Header of the
+ REMOVE_VALUE request must set its <OpCode> to OC_REMOVE_VALUE.
+
+ The Message Body of any REMOVE_VALUE request is encoded as follows:
+
+ <Message Body of REMOVE_VALUE Request> ::= <Handle>
+ <IndexList>
+
+ where
+
+ <Handle>
+ A UTF8-String that specifies the handle whose value(s) needs
+ to be removed.
+
+
+
+
+Sun, et al. Informational [Page 35]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <IndexList>
+ A 4-byte unsigned integer followed by a list of handle value
+ indexes. Each index refers to a handle value to be removed
+ from the <Handle>. The integer specifies the number of
+ indexes in the list. Each index is also encoded as a 4-byte
+ unsigned integer.
+
+ The server that receives the REMOVE_VALUE request must first
+ authenticate the client as the administrator with the REMOVE VALUE
+ privilege. Upon successful authentication, the server will proceed
+ to remove the handle values specified in the <IndexList> from the
+ <Handle>. If successful, the server will return an RC_SUCCESS
+ message to the client.
+
+ Each REMOVE_VALUE request must be carried out as a transaction. If
+ removing any value specified in the <IndexList> raises an error, the
+ entire operation must be rolled back. For any failed REMOVE_VALUE
+ request, none of values referenced in the <IndexList> should be
+ removed from the <Handle>. The server must also send a response to
+ the client that explains the error. For example, attempts to remove
+ any handle value with neither PUB_WRITE nor ADMIN_WRITE permission
+ will result in an RC_ACCESS_DENIED error. Note that a REMOVE_VALUE
+ request asking to remove a non-existing handle value will not be
+ treated as an error.
+
+ REMOVE_VALUE requests can also be used to remove handle
+ administrators. This happens if any of the indexes in the
+ <IndexList> refer to an HS_ADMIN value. Servers must authenticate
+ the client as an administrator with the REMOVE_ADMIN privilege before
+ fulfilling such requests.
+
+3.6.3. Modify Handle Value(s)
+
+ Clients can make modifications to an existing handle value by sending
+ MODIFY_VALUE requests to the responsible handle server. The Message
+ Header of the MODIFY_VALUE request must set its <OpCode> to
+ OC_MODIFY_VALUE.
+
+ The Message Body of any MODIFY_VALUE request is defined as follows:
+
+ <Message Body of MODIFY_VALUE Response> ::= <Handle>
+ <ValueList>
+
+ where
+
+ <Handle>
+ A UTF8-String that specifies the handle whose value(s) needs
+ to be modified.
+
+
+
+Sun, et al. Informational [Page 36]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+
+ <ValueList>
+ A 4-byte unsigned integer followed by a list of handle
+ values. The integer specifies the number of handle values
+ in the list. Each value in the <ValueList> specifies a
+ handle value that will replace the existing handle value
+ with the same index.
+
+ The server that receives the MODIFY_VALUE request must first
+ authenticate the client as an administrator with the MODIFY_VALUE
+ privilege. Upon successful authentication, the server will proceed
+ to replace those handle values listed in the <ValueList>, provided
+ each handle value has PUB_WRITE or ADMIN_WRITE permission. If
+ successful, the server must notify the client with an RC_SUCCESS
+ message.
+
+ Each MODIFY_VALUE request must be carried out as a transaction. If
+ replacing any value listed in the <ValueList> raises an error, the
+ entire operation must be rolled back. For any failed MODIFY_VALUE
+ request, none of values in the <ValueList> should be replaced. The
+ server must also return a response to the client that explains the
+ error. For example, if a MODIFY_VALUE requests to remove a handle
+ value that has neither PUB_WRITE nor ADMIN_WRITE permission, the
+ server must return an error message with the <ResponseCode> set to
+ RC_ACCESS_DENIED. Any MODIFY_VALUE request to replace non- existing
+ handle values is also treated as an error. In this case, the server
+ will return an error message with <ResponseCode> set to
+ RC_VALUE_NOT_FOUND.
+
+ MODIFY_VALUE requests can also be used to update handle
+ administrators. This happens if both the values in the <ValueList>
+ and the value to be replaced are HS_ADMIN values. Servers must
+ authenticate the client as an administrator with the MODIFY_ADMIN
+ privilege before fulfilling such a request. It is an error to
+ replace a non-HS_ADMIN value with an HS_ADMIN value. In this case,
+ the server will return an error message with <ResponseCode> set to
+ RC_VALUE_INVALID.
+
+3.6.4. Create Handle
+
+ Clients can create new handles by sending CREATE_HANDLE requests to
+ the responsible handle server. The Message Header of any
+ CREATE_HANDLE request must set its <OpCode> to OC_CREATE_HANDLE.
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 37]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ The Message Body of any CREATE_HANDLE request is defined as follows:
+
+ <Message Body of CREATE_HANDLE Response> ::= <Handle>
+ <ValueList>
+
+ where
+
+ <Handle>
+ A UTF8-String that specifies the handle.
+
+ <ValueList>
+ A 4-byte unsigned integer followed by a list of handle
+ values. The integer indicates the number of handle values
+ in the list. The <ValueList> should at least include one
+ HS_ADMIN value that defines the handle administrator.
+
+ Only naming authority administrators with the CREATE_HANDLE privilege
+ are allowed to create new handles under the naming authority. The
+ server that receives a CREATE_HANDLE request must authenticate the
+ client as the administrator of the corresponding naming authority
+ handle and make certain that the administrator is authorized to
+ create handles under the naming authority. This is different from
+ the ADD_VALUE request where the server authenticates the client as an
+ administrator of the handle. Upon successful authentication, the
+ server will proceed to create the new handle and add each value in
+ the <ValueList> to the new <Handle>. If successful, the server will
+ return an RC_SUCCESS message to the client.
+
+ Each CREATE_HANDLE request must be carried out as a transaction. If
+ any part of the CREATE_HANDLE process fails, the entire operation can
+ be rolled back. For example, if the server fails to add values in
+ the <ValueList> to the new handle, it must return an error message
+ without creating the new handle. Any CREATE_HANDLE request that asks
+ to create a handle that already exists will be treated as an error.
+ In this case, the server will return an error message with the
+ <ResponseCode> set to RC_HANDLE_ALREADY_EXIST.
+
+ CREATE_HANDLE requests can also be used to create naming authorities.
+ Naming authorities are created as naming authority handles at the
+ GHR. Before creating a new naming authority handle, the server must
+ authenticate the client as the administrator of the parent naming
+ authority. Only administrators with the CREATE_NA privilege are
+ allowed to create any sub-naming authority. Root level naming
+ authorities may be created by the administrator of the root handle
+ "0.NA/0.NA".
+
+
+
+
+
+
+Sun, et al. Informational [Page 38]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+3.6.5. Delete Handle
+
+ Clients delete existing handles by sending DELETE_HANDLE requests to
+ the responsible handle server. The Message Header of the
+ DELETE_HANDLE request must set its <OpCode> to OC_DELETE_HANDLE.
+
+ The Message Body of any DELETE_HANDLE request is defined as follows:
+
+ <Message Body of DELETE_HANDLE Request> ::= <Handle>
+
+ where
+
+ <Handle>
+ A UTF8-String that specifies the handle.
+
+ The server that receives the DELETE_HANDLE request must first
+ authenticate the client as the administrator with the DELETE_HANDLE
+ privilege. Upon successful authentication, the server will proceed
+ to delete the handle along with any handle values assigned to the
+ handle. If successful, the server will return an RC_SUCCESS message
+ to the client.
+
+ Each DELETE_HANDLE request must be carried out as a transaction. If
+ any part of the DELETE_HANDLE process fails, the entire operation
+ must be rolled back. For example, if the server fails to remove any
+ handle values assigned to the handle (before deleting the handle), it
+ must return an error message without deleting the handle. This may
+ happen if the handle contains a value that has neither PUB_WRITE nor
+ ADMIN_WRITE permission. In this case, the server will return an
+ error message with the <ResponseCode> set to RC_PERMISSION_DENIED. A
+ DELETE_HANDLE request that asks to delete a non-existing handle will
+ also be treated as an error. The server will return an error message
+ with the <ResponseCode> set to RC_HANDLE_NOT_EXIST.
+
+ DELETE_HANDLE requests can also be used to delete naming authorities.
+ This is achieved by deleting the corresponding naming authority
+ handle on the GHR. Before deleting a naming authority handle, the
+ server must authenticate the client as the administrator of the
+ naming authority handle. Only administrators with the DELETE_NA
+ privilege are allowed to delete the naming authority. Root level
+ naming authorities may be deleted by the administrator of the root
+ handle "0.NA/0.NA".
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 39]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+3.7. Naming Authority (NA) Administration
+
+ The Handle System manages naming authorities via naming authority
+ handles. Naming authority handles are managed by the GHR. Clients
+ can change the service information of any naming authority by
+ changing the HS_SITE values assigned to the corresponding naming
+ authority handle. Creating or deleting naming authorities is done by
+ creating or deleting the corresponding naming authority handles.
+ Root level naming authorities may be created or deleted by the
+ administrator of the root handle "0.NA/0.NA". Non-root-level naming
+ authorities may be created by the administrator of its parent naming
+ authority.
+
+ For example, the administrator of the naming authority handle
+ "0.NA/10" may create the naming authority "10.1000" by sending a
+ CREATE_HANDLE request to the GHR to create the naming authority
+ handle "0.NA/10.1000". Before fulfilling the request, the server at
+ the GHR must authenticate the client as the administrator of the
+ parent naming authority, that is, the administrator of the naming
+ authority handle "0.NA/10". The server must also make sure that the
+ administrator has the NA_CREATE privilege.
+
+ The Handle protocol also allows clients to list handles or sub-naming
+ authorities under a naming authority. Details of these operations
+ are described in the following sections.
+
+3.7.1. List Handle(s) under a Naming Authority
+
+ Clients send LIST_HANDLE requests to handle servers to get a list of
+ handles under a naming authority. The Message Header of the
+ LIST_HANDLE request must set its <OpCode> to OC_LIST_HANDLE.
+
+ The Message Body of any LIST_HANDLE request is defined as follows:
+
+ <Message Body of LIST_HANDLE Request> ::= <NA_Handle>
+
+ where
+
+ <NA_Handle>
+ A UTF8-String that specifies the naming authority handle.
+
+ To obtain a complete list of the handles, the request must be sent to
+ every handle server listed in one of the service sites of the
+ responsible handle service. Each server within the service site will
+ return its own list of handles under the naming authority. The
+ Message Body of a successful LIST_HANDLE response (from each handle
+ server) is defined as follows:
+
+
+
+
+Sun, et al. Informational [Page 40]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <Message Body of LIST_HANDLE Response> ::= <Num_Handles>
+ <HandleList>
+ where
+
+ <Num_Handles>
+ Number of handles (managed by the handle server) under the
+ naming authority.
+
+ <HandleList>
+ A list of UTF8-Strings, each of which identify a handle
+ under the naming authority.
+
+ The LIST_HANDLE request may potentially slow down the overall system
+ performance. A handle service (or its service site) has the option
+ of whether or not to support such request. The server will return an
+ RC_OPERATION_DENIED message if LIST_HANDLE is not supported. The
+ server that receives a LIST_HANDLE request should authenticate the
+ client as a naming authority administrator with the LIST_HANDLE
+ privilege before fulfilling the request.
+
+3.7.2. List Sub-Naming Authorities under a Naming Authority
+
+ Clients send LIST_NA requests to handle servers to get a list of
+ sub-naming authorities under a naming authority. The Message Header
+ of the LIST_NA request must set its <OpCode> to OC_LIST_NA.
+
+ The Message Body of any LIST_NA request is defined as follows:
+
+ <Message Body of LIST_HANDLE Request> ::= <NA_Handle>
+
+ where
+
+ <NA_Handle>
+ A UTF8-String that specifies the naming authority handle.
+
+ To obtain a complete list of the sub-naming authorities, the request
+ must be sent to every handle server listed in any one of the service
+ sites of the GHR. Each server within the service site will return
+ its own list of sub-naming authority handles under the given naming
+ authority. The Message Body of a successful LIST_NA response (from
+ each handle server) is defined as follows:
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 41]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <Message Body of LIST_HANDLE Response> ::= <Num_Handles>
+ <HandleList>
+ where
+
+ <Num_Handles>
+ Number of handles (managed by the handle server) under the
+ naming authority.
+
+ <HandleList>
+ A list of UTF8-Strings, each of which identifies a sub-
+ naming authority user-specified naming authority.
+
+ LIST_NA requests must be sent to servers under the GHR that manages
+ all the naming authority handles. The LIST_NA request may
+ potentially slow down the overall system performance, especially the
+ GHS. A server (or service sites) under the GHR has the option of
+ whether or not to support such requests. The server will return an
+ RC_OPERATION_DENIED message if LIST_NA is not supported. The server
+ that receives a LIST_HANDLE request should authenticate the client as
+ a naming authority administrator with the LIST_NA privilege before
+ fulfilling the request.
+
+3.8. Session and Session Management
+
+ Sessions are used to allow sharing of authentication information or
+ network resources among multiple protocol operations. For example, a
+ naming authority administrator may authenticate itself once through
+ the session setup, and then register multiple handles under the
+ session.
+
+ A client may ask the server to establish a session key and use it for
+ subsequent requests. A session key is a secret key that is shared by
+ the client and server. It can be used to authenticate or encrypt any
+ message exchanged under the session. A session is encrypted if every
+ message exchanged within the session is encrypted using the session
+ key.
+
+ Sessions may be established as the result of an explicit
+ OC_SESSION_SETUP request from a client. A server may also
+ automatically setup a session when multiple message exchanges are
+ expected to fulfill a request. For example, the server will
+ automatically establish a session if it receives a CREATE_HANDLE
+ request that requires client authentication.
+
+ Every session is identified by a non-zero Session ID that appears in
+ the Message Header. Servers are responsible for generating a unique
+ Session ID for each outstanding session. Each session may have a set
+ of state information associated with it. The state information may
+
+
+
+Sun, et al. Informational [Page 42]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ include the session key and the information obtained from client
+ authentication, as well as any communication options. Servers and
+ clients are responsible for keeping the state information in sync
+ until the session is terminated.
+
+ A session may be terminated with an OC_SESSION_TERMINATE request from
+ the client. Servers may also terminate a session that has been idle
+ for a significant amount of time.
+
+3.8.1. Session Setup Request
+
+ Clients establish a session with a handle server with a SESSION_SETUP
+ request. A SESSION_SETUP request can also be used to update any
+ state information associated to an existing session. The Message
+ Header of the SESSION_SETUP request must have its <OpCode> set to
+ OC_SESSION_SETUP and <ResponseCode> to 0.
+
+ The Message Body of any SESSION_SETUP request is defined as follows:
+
+ <SESSION_SETUP Request Message Body> ::= <SessionAttributes>
+
+ where
+
+ <SessionAttributes>
+ A 4-byte unsigned integer followed by a list of session
+ attributes. The integer indicates the number of session
+ attributes in the list. Possible session attributes include
+ the <HS_SESSION_IDENTITY>, the <HS_SESSION_TIMEOUT>, and the
+ <HS_SESSION_KEY_EXCHANGE>. Each of these attributes is
+ defined as follows:
+
+ <HS_SESSION_IDENTITY> ::= <Key>
+ <Handle>
+ <ValueIndex>
+ where
+
+ <Key>
+ A UTF-8 string constant "HS_SESSION_IDENTITY".
+
+ <Handle>
+ <ValueIndex>
+ A UTF-8 string followed by a 4-byte unsigned
+ integer that specifies the handle and the handle
+ value used for client authentication. It must
+ refer to a handle value that contains the public
+ key of the client. The public key is used by
+ the server to authenticate the client.
+
+
+
+
+Sun, et al. Informational [Page 43]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <HS_SESSION_KEY_EXCHANGE> ::= <Key>
+ <KeyExchangeData>
+ where
+
+ <Key>
+ A UTF-8 string constant "HS_SESSION_KEY_EXCHANGE".
+
+ <KeyExchangeData>
+ One of the these tuples: <ClientCipher
+ <ClientCipher KeyExchange>,
+ <HdlCipher KeyExchange>, or
+ <ServerCipher KeyExchange>.
+ Each of these tuples is defined as follows:
+
+ <ClientCipher KeyExchange> ::= <Key>
+ <PubKey>
+ where
+
+ <Key>
+ A UTF-8 string constant "CLIENT_CIPHER".
+
+ <PubKey>
+ A public key provided by the client and used
+ by the server to encrypt the session key.
+
+ <HdlCipher KeyExchange> ::= <Key>
+ <ExchangeKeyHdl>
+ <ExchangeKeyIndex>
+ where
+
+ <Key>
+ A UTF-8 string constant "HDL_CIPHER".
+
+ <ExchangeKeyHdl>
+ <ExchangeKeyIndex>
+ A UTF-8 string followed by a 4-byte unsigned
+ integer. The <ExchangeKeyHdl> and
+ <ExchangeKeyIndex> refers to a handle value
+ used for session key exchange. The handle
+ value must contain the public key of the
+ client. The public key will be used by the
+ server to encrypt the session key before
+ sending it to the client.
+
+ <ServerCipher KeyExchange> ::= <Key>
+
+ where
+
+
+
+
+Sun, et al. Informational [Page 44]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ <Key>
+ A UTF-8 string constant "SERVER_CIPHER". This
+ tells the server that the client will be
+ responsible for generating the session key. The
+ server will have to provide its public key in
+ the response message and set the <ResponseCode>
+ to RC_SESSION_EXCHANGEKEY. The client can use
+ the server's public key to encrypt the session
+ key and send it to the server via a subsequent
+ SESSION_EXCHANGEKEY request.
+
+ <DiffieHellman KeyExchange> ::= <Key>
+ <DHParams>
+ where
+
+ <Key>
+ A UTF-8 string constant "DIFFIE_HELLMAN"
+
+ <DHParams>
+ The values used as input in the Diffie-
+ Hellman algorithm. It consists of three big
+ integers of variable length. Each big
+ integer is encoded in terms of a 4-byte
+ unsigned integer followed by an octet string.
+ The octet string contains the big integer
+ itself. The 4-byte unsigned integer
+ specifies the number of octets of the octet
+ string.
+
+
+ <HS_SESSION_TIMEOUT> ::= <Key>
+ <TimeOut>
+ where
+
+ <Key>
+ A UTF-8 string constant "HS_SESSION_TIMEOUT".
+
+ <TimeOut>
+ A 4-byte unsigned integer that specifies the desired
+ duration of the session in seconds.
+
+ Note that it should be treated as an error if the same session
+ attribute is listed multiple times in the <SessionAttribute> field.
+ When this happens, the server should return an error message with
+ <ResponseCode> set to RC_PROTOCOL_ERROR.
+
+ A SESSION_SETUP_REQUEST can be used to change session attributes of
+ any established session. This happens if the <SessionId> is non-zero
+
+
+
+Sun, et al. Informational [Page 45]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ and matches one of the established sessions. Care must be taken by
+ the server to prevent any unauthorized request from changing the
+ session attributes. For example, an encrypted session may only be
+ changed into an unencrypted session by a SESSION_SETUP_REQUEST with
+ an appropriate MAC in its Message Credential.
+
+3.8.2. Session Setup Response
+
+ The Message Header of the SESSION_SETUP response must set its
+ <OpCode> to OC_SESSION_SETUP. The <ResponseCode> of the
+ SESSION_SETUP response varies according to the SESSION_SETUP request.
+ It must be set to RC_SUCCESS if the SESSION_SETUP request is
+ successful and the server does not expect a session key to be
+ returned by the client.
+
+ The Message Body of the SESSION_SETUP response is empty unless the
+ request is asking for <HS_SESSION_KEY_EXCHANGE>. In this case, the
+ Message Body of the SESSION_SETUP response may contain the encrypted
+ session key from the server, or the server's public key, to be used
+ for session key exchange. The exact format depends on the content of
+ the <HS_SESSION_KEY_EXCHANGE> in the SESSION_SETUP request. If
+ <ClientCipher KeyExchange> or <HdlCipher KeyExchange> is given in the
+ SESSION_SETUP request, the Message Body of the SESSION_SETUP response
+ will contain the encrypted session key from the server and is defined
+ as follows:
+
+ <Message Body of SESSION_SETUP Response>
+ ::= <RequestDigest>
+ <EncryptedSessionKey>
+ [ <EncryptionAlgorithm> ]
+ where
+
+ <RequestDigest>
+ Message digest of the SESSION_SETUP request is as specified in
+ section 2.2.3.
+
+ <EncryptedSessionKey>
+ Session key is encrypted using the public key provided in the
+ SESSION_SETUP request. The session key is a randomly
+ generated octet string from the server. The server will only
+ return the <EncryptedSessionKey> if the <KeyExchangeData> in
+ the SESSION_SETUP request provides the public key from the
+ client.
+
+ <EncryptionAlgorithm>
+ (optional) UTF-8 string that identifies the encryption
+ algorithm used by the session key.
+
+
+
+
+Sun, et al. Informational [Page 46]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ If <ServerCipher KeyExchange> is given in the SESSION_SETUP request,
+ the server must provide its public key in the SESSION_SETUP response.
+ The public key can be used by the client in a subsequent
+ SESSION_EXCHANGEKEY request (defined below) for session key exchange.
+ In this case, the Message Header of the SESSION_SETUP response must
+ set its <ResponseCode> to RC_SESSION_EXCHANGEKEY. The Message Body
+ of the SESSION_SETUP response must include the server's public key
+ and is defined as follows:
+
+ <Message Body of SESSION_SETUP response>
+ ::= <RequestDigest>
+ <Public Key for Session Key Exchange>
+
+ where
+
+ <RequestDigest>
+ Message digest of the SESSION_SETUP request as specified in
+ section 2.2.3.
+
+ <Public Key for Session Key Exchange>
+ Public key from the server to be used for session key
+ exchange. It is encoded in the same format as the <PublicKey>
+ record in the HS_SITE value (see section 3.2.2 in [2]).
+
+3.8.3. Session Key Exchange
+
+ If the <ResponseCode> of a SESSION_SETUP response is
+ RC_SESSION_EXCHANGEKEY, the client is responsible for generating the
+ session key and sending it to the server. In this case, the client
+ can generate a session key, encrypt it with the public key provided
+ by the server in the SESSION_SETUP response, and send the encrypted
+ session key to the server in a SESSION_EXCHANGEKEY request.
+
+ The Message Header of the SESSION_EXCHANGEKEY request must set its
+ <OpCode> to OC_SESSION_EXCHANGEKEY and its <ResponseCode> to 0. The
+ Message Body of the SESSION_EXCHANGEKEY request is defined as
+ follows:
+
+ <Message Body of OC_SESSION_EXCHANGEKEY>
+ ::= <Encrypted Session Key>
+ [ <EncryptionAlgorithm> ]
+
+ where
+
+ <EncryptedSessionKey>
+ Session key encrypted using the public key provided in the
+ SESSION_SETUP response. The session key is a randomly
+ generated octet string by the client.
+
+
+
+Sun, et al. Informational [Page 47]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+
+ <EncryptionAlgorithm>
+ (optional) UTF-8 string that identifies the encryption
+ algorithm used by the session key.
+
+ During the session key exchange, the server receiving the exchange
+ key or session key has the responsibility of ensuring that the key
+ meets the security requirements defined in its local policy. If the
+ server considers the key being volunable, it must return an error
+ message to the client with <ResponseCode> set to
+ RC_SESSION_KEY_INVALID.
+
+3.8.4. Session Termination
+
+ Clients can terminate a session with a SESSION_TERMINATE request.
+ The Message Header of a SESSION_TERMINATE request must have its
+ <OpCode> set to OC_SESSION_TERMINATE and its <ResponseCode> to 0.
+ The message body of any SESSION_TERMINATE request must be empty.
+
+ The server must send a SESSION_TERMINATE response to the client after
+ the session is terminated. The server should only terminate the
+ session after it has finished processing all the requests (under the
+ session) that were submitted before the Session Termination request.
+
+ The message header of the SESSION_TERMINATE response must set its
+ <OpCode> to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE
+ response must have its <ResponseCode> set to RC_SUCCESS, and an empty
+ message body.
+
+4. Implementation Guidelines
+
+4.1. Server Implementation
+
+ The optimal structure for any handle server will depend on the host
+ operating system. This section only addresses those implementation
+ considerations that are common to most handle servers.
+
+ A good server implementation should allow easy configuration or
+ fine-tuning. A suggested list of configurable items includes the
+ server's network interface(s) (e.g., IP address, port number, etc.),
+ the number of concurrent processes/threads allowed, time-out
+ intervals for any TCP connection and/or authentication process, re-
+ try policy under UDP connection, policies on whether to support
+ recursive service, case-sensitivity for ASCII characters, and
+ different levels of transaction logging, etc.
+
+
+
+
+
+
+Sun, et al. Informational [Page 48]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ All handle server implementations must support all the handle data
+ types as defined in the "Handle System Namespace and Service
+ Definition" [2]. They should also be able to store handle values of
+ any application defined data type.
+
+ A handle server must support multiple concurrent activities, whether
+ they are implemented as separate processes or threads in the host's
+ operating system, or multiplexed inside a single name server program.
+ A handle server should not block the service of UDP requests while it
+ waits for TCP data or other query activities. Similarly, a handle
+ server should not attempt to provide recursive service without
+ processing such requests in parallel, though it may choose to
+ serialize requests from a single client, or to regard identical
+ requests from the same client as duplicates.
+
+4.2. Client Implementation
+
+ Clients should be prepared to receive handle values of any data type.
+ Clients may choose to implement a callback interface to allow new
+ modules or plug-ins to be added to support any application-defined
+ data types.
+
+ Clients that follow service referrals or handle aliases must avoid
+ falling into an infinite loop. They should not repeatedly contact
+ the same server for the same request with the same target entry. A
+ client may choose to use a counter that is incremented each time it
+ follows a service referral or handle alias. There should be a
+ configurable upper limit to the counter to control the levels of
+ service referrals or handle aliases followed by the client.
+
+ Clients that provide some caching can expect much better performance
+ than those that do not. Client implementations should always
+ consider caching the service information associated with a naming
+ authority. This will reduce the number of roundtrips for subsequent
+ handle requests under the same naming authority.
+
+5. Security Considerations
+
+ The overall Handle System security considerations are discussed in
+ "Handle System Overview" [1]; that discussion applies equally to this
+ document. Security considerations regarding the Handle System data
+ model and service model are discussed in "Handle System Namespace and
+ Service Definition" [2].
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 49]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ For efficiency, the Handle protocol includes a simple challenge-
+ response authentication protocol for basic client authentication.
+ Handle servers are free to provide additional authentication
+ mechanisms (e.g., SASL) as needed. Details of this will be discussed
+ in a separate document.
+
+ Data integrity under the Handle protocol is achieved via the server's
+ digital signature. Care must be taken to protect the server's
+ private key from any impersonation attack. Any change to the
+ server's public key pair must be registered (in terms of service
+ information) with the GHR.
+
+6. 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.
+
+7. Informative References
+
+ [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650,
+ November 2003.
+
+ [2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and
+ Service Definition", RFC 3651, November 2003.
+
+ [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+ 2279, January 1998.
+
+ [4] A. Freier, P. Karlton, P. Kocher "The SSL Protocol Version 3.0"
+
+ [5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7"
+ http://www.rsasecurity.com/rsalabs/pkcs/
+
+
+
+
+
+Sun, et al. Informational [Page 50]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+ [6] U.S. Federal Information Processing Standard: Digital Signature
+ Standard.
+
+ [7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
+ RFC 3370, August 2002.
+
+ [8] Braden, R., "FTP Data Compression", RFC 468, March 1973.
+
+ [9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+ 1992.
+
+ [10] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+ [11] D. Cohen, "On Holy Wars and a Plea for Peace", Internet
+ Experiment, Note IEN 137, 1 April 1980.
+
+ [12] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC
+ 3124, June 2001.
+
+ [13] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
+ Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
+
+ [14] Polk, W., Housley, R. and L. Bassham, "Algorithms and
+ Identifiers for the Internet X.509 Public Key Infrastructure
+ Certificate and Certificate Revocation List (CRL) Profile", RFC
+ 3279, April 2002.
+
+ [15] 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.
+
+ [16] M. Bellare and P. Rogaway. The Exact Security of Digital
+ Signatures - How to Sign with RSA and Rabin. In Advances in
+ Cryptology-Eurocrypt '96, pp.399-416, Springer-Verlag, 1996.
+
+ [17] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
+ for Message Authentication", RFC 2104, February 1997.
+
+ [18] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
+ Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 51]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+8. 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-262-5307
+ EMail: llannom@cnri.reston.va.us
+
+
+ Jason Petrone
+ Corporation for National Research Initiatives (CNRI)
+ 1895 Preston White Dr., Suite 100
+ Reston, VA 20191
+
+ Phone: 703-262-5340
+ EMail: jpetrone@cnri.reston.va.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sun, et al. Informational [Page 52]
+
+RFC 3652 Handle System Protocol (v2.1) November 2003
+
+
+9. 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 53]
+