From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3652.txt | 2971 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2971 insertions(+) create mode 100644 doc/rfc/rfc3652.txt (limited to 'doc/rfc/rfc3652.txt') 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. and + + The and 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 is 2 and is 1. + + and are designed to allow future + backward compatibility. A difference in indicates + major variation in the protocol format and the party with the lower + will have to upgrade its software to ensure precise + communication. An increment in is made when + additional capabilities are added to the protocol without any major + change to the message format. + +2.2.1.2. + + The 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. + + The is a four-byte unsigned integer that identifies a + communication session between the client and server. + + Session and its 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 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 set to zero. The server must assign a unique + non-zero 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 for + messages exchanged under an established session. A message whose + 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 + . 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. + + Each request from a client is identified by a , a 4-byte + unsigned integer set by the client. Each must be unique + from all other outstanding requests from the same client. The + allows the client to keep track of its requests, and any + response from the server must include the correct . + +2.2.1.5. + + Messages under the Handle protocol may be truncated during their + transmission (e.g., under UDP). The 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 . The + 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 to zero. + + + +Sun, et al. Informational [Page 10] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + +2.2.1.6. + + 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 . + +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. + + The stands for operation code, which is a four-byte unsigned + integer that specifies the intended operation. The following table + lists the 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 s can be found in + section 3 of this document. In general, clients use the to + tell the server what kind of handle operation they want to + accomplish. Response from the server must maintain the same + as the original request and use the to indicate the + result. + +2.2.2.2. + + The is a 4-byte unsigned integer that is given by a + server to indicate the result of any service request. The list of + 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 s can be found in + section 3 of this document. In general, any request from a client + must have its set to 0. The response message from the + server must have a non-zero to indicate the result. + For example, a response message from a server with set + to RC_SUCCESS indicates that the server has successfully fulfilled + the client's request. + +2.2.2.3. + + The 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 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 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 field are reserved and must be set to + zero. + + In general, servers must honor the specified in the request. + If a requested option cannot be met, the server should return an + error message with the proper as defined in the + previous section. + +2.2.2.4. + + The is a two-byte unsigned integer. The + in a request refers to the of + the HS_SITE value used by the client (to access the server). Servers + can check the 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 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 set to + RC_EXPIRED_SITE_INFO. + +2.2.2.5. + + The 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 set + to 0. If the server has to send a recursive request on behalf of the + client, it must increment the by 1. Any response + from the server must maintain the same 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 reaches a certain value. + +2.2.2.6. + + The 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. + + The is a 4-byte unsigned integer that specifies the + number of octets in the Message Body. The 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 in + the Message Header. The Message Body may be empty. The exact format + of the Message Body depends on the and the in + the Message Header. Details of the Message Body under each + and are described in section 3 of this document. + + For any response message, if the Message Header has its RD bit (in + ) set to 1, the Message Body must begin with the message + digest of the original request. The message digest is defined as + follows: + + ::= + + + where + + + 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. + + + 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 + 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: + | + |---------------------------------------------------------------| + | Type (UTF8-String) | + |---------------------------------------------------------------| + | + | SignedInfo: : 4-byte unsigned integer + | DigestAlgorithm: + | SignedData: + | + '---------------------------------------------------------------' + + where + + + 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. + + + An octet that identifies the version number of the Message + Credential. The version number specified in this document is + zero. + + + An octet that must be set to zero. + + + Two octets reserved for various cryptography options. + + + +Sun, et al. Informational [Page 18] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + + + ::= + + A reference to a handle value in terms of the and the + 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. + + + A UTF8-String that indicates the type of content in the + field (described below). It may contain HS_DIGEST if + contains the message digest, or HS_MAC if + contains the Message Authentication Code (MAC). The + field will specify the signature algorithm identifier if + contains a digital signature. For example, with the + field set to HS_SIGNED_PSS, the field will + contain the digital signature generated using the RSA-PSS + algorithm [16]. If the field is set to HS_SIGNED, the + field will contain the digital signature generated + from a DSA public key pair. + + ::= + + + where + + + A 4-byte unsigned integer that specifies the number of + octets in the field. + + + 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. + + ::= + + where + + + A 4-byte unsigned integer that specifies the number of + octets in the . + + + Contains the digital signature or the MAC over the + Message Header and Message Body. The syntax and + semantics of the signature depend on the field + + + +Sun, et al. Informational [Page 19] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + + and the public key referenced in the field. + For example, if the field is "HS_SIGNED" and + the public key referred to by the 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 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 field must set its to a zero-length UTF8-String + and its to the specified in the Message Envelope. + The field must contain the MAC in its field. + The MAC is the result of the one-way hash over the concatenation of + the session key, the , the , 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 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 ). Each + "Message Envelope i" must also set its to reflect the + size of the packet. The recipient of these truncated packets can + reassemble the message by concatenating these packets based on their + . + +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 and + 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 + 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 in the client's request. The client + should update the root service information if the 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 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 or other attributes + (under the ) 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 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 given in the HS_SITE value. The result is + the sequence number of the listed in the HS_SITE + value. For example, if the result of the modulation is 2, the + third listed in the should be + selected. The 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 to + OC_RESOLUTION (defined in section 2.2.2.1) and to 0. + + The Message Body for any query request is defined as follows: + + ::= + + + + where + + + A UTF8-String (as defined in section 2.1.4) that specifies + the handle to be resolved. + + + 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. + + + 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 + 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 but an empty + , the server should only return those handle values whose + indexes are listed in the . Likewise, if a query consists + of a non-empty but an empty , the server should + only return those handle values whose data types are listed in the + . + + When both and fields are non-empty, the server + should return all handle values whose indexes are listed in the + AND all handle values whose data types are listed in the + . + +3.2.2. Successful Query Response + + The Message Header of any query response must set its to + OC_RESOLUTION. A successful query response must set its + to RC_SUCCESS. + + The message body of the successful query response is defined as + follows: + + ::= [] + + + + where + + + Optional field as defined in section 2.2.3. + + + A UTF8-String that specifies the handle queried by the + client. + + + 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 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 set to + RC_SERVER_NOT_RESP. + + The server may return an error message with 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 (in the message header) as the one in + the original request. Each error condition is identified by a unique + 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): + + ::= [] + + [ ] + + where + + + Optional field as defined in section 2.2.3. + + + A UTF8-String that explains the error. + + + 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 + set to RC_VALUE_ALREADY_EXIST and add index 1 and 2 to the + . 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 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 + as the one in the original request and set its + 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: + + ::= [ ] + + [ ] + + where + + + Optional field as defined in section 2.2.3. + + + 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 is set to "0.NA/0.NA", + it is referring the client to the GHR. + + + An optional field that must be empty if the + 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 . The may contain an empty + UTF8-String if the HS_SITE values in the 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 + 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 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 + 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 + 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 as + the original request and set the to RC_AUTH_NEEDED. + The server must assign a non-zero unique in the Message + Envelope to keep track of the authentication. It must also set the + RD flag of the (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: + + ::= + + where + + + Message Digest of the request message, as defined in section + 2.2.3. + + + 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 + . If the client requested the server to sign the + 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 to + OC_CHALLENGE_RESPONSE and its to 0. It must also keep + the same (in the Message Envelope) as specified in the + challenge from the server. + + The Message Body of the CHALLENGE_RESPONSE request is defines as + follows: + + ::= + + + + + where + + + 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 + + + + + A UTF8-String that identifies the handle that holds the + public or secret key of the handle administrator. + + + A 4-byte unsigned integer that specifies the index of the + handle value (of the ) that holds the public or + secret key of the administrator. + + + Contains either the Message Authentication Code (MAC) or the + digital signature over the challenge from the server. If + the is "HS_SECKEY", the + 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( + + ) + + where the is the administrator's secret key + referenced by the and . The + is the Message Body portion of the + server's challenge. If the first octet in the + is set to 0x02, the MAC is generated + using + + SHA-1_Hash( + + ) + + A more secure approach is to use HMAC [17] for the + . The HMAC can be generated using the + and . A + with its first octet set to 0x11 indicates that the HMAC + is generated using the MD5 algorithm. Likewise, a + with its first octet set to 0x12 + indicates that the HMAC is generated using the SHA-1 + algorithm. + + If the is "HS_PUBKEY", the + 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 and + + + +Sun, et al. Informational [Page 31] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + + 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 + 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 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 + field matches the and . If no match + is found, but there are administrator groups defined, the server must + check if the and 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 and 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 + set to RC_NOT_AUTHORIZED. Otherwise, the server will + continue to authenticate the client as follows: + + If the is "HS_PUBKEY", the server will retrieve + the administrator's public key based on the and + . The public key can be used to verify the + against the server's . If the + matches the , the server will continue + to process the original request and return the result. Otherwise, + the server will return an error message with set to + RC_AUTHENTICATION_FAILED. + + If the 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 . + The verification request and its response are defined in the + following sections. The verification server will verify the + against the 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 + to OC_VERIFY_CHALLENGE and the to 0. + + The message body of the Verification-Request is defined as follows: + + ::= + + + + + where + + + A UTF8-String that refers to the handle that holds the + secret key of the administrator. + + + A 4-byte unsigned integer that is the index of the handle + value that holds the secret key of the administrator. + + + The message body of the server's challenge, as described in + section 3.5.1. + + + The from the client in response to + the server's , 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 matches the in the Verification- + Request. + + The Message Header of the Verification-Response must set its + to RC_SUCCESS whether or not the + matches the . The RD flag in the field should + also be set (to 1) since the 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: + + + ::= + + where + + + Contains the message digest of the Verification-Request. + + + An octet that is set to 1 if the + matches the . Otherwise it must be set to + 0. + + The verification server may return an error with set + to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the + does not exist, or the and 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 to OC_ADD_VALUE. + + The Message Body of the ADD_VALUE request is encoded as follows: + + ::= + + + where + + + A UTF8-String that specifies the handle. + + + + + +Sun, et al. Informational [Page 34] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + + + 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 to the . 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 raises an error, the entire + operation must be rolled back. For any failed ADD_VALUE request, + none of the values in the should be added to the + . The server must also send a response to the client that + explains the error. For example, if a value in the has + the same index as one of the existing handle values, the server will + return an error message that has the set to + RC_VALUE_ALREADY_EXISTS. + + ADD_VALUE requests can also be used to add handle administrators. + This happens if the 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 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 to OC_REMOVE_VALUE. + + The Message Body of any REMOVE_VALUE request is encoded as follows: + + ::= + + + where + + + 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 + + + + 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 . 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 from the + . 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 raises an error, the + entire operation must be rolled back. For any failed REMOVE_VALUE + request, none of values referenced in the should be + removed from the . 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 + 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 to + OC_MODIFY_VALUE. + + The Message Body of any MODIFY_VALUE request is defined as follows: + + ::= + + + where + + + 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 + + + + + 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 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 , 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 raises an error, the + entire operation must be rolled back. For any failed MODIFY_VALUE + request, none of values in the 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 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 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 + 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 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 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: + + ::= + + + where + + + A UTF8-String that specifies the handle. + + + A 4-byte unsigned integer followed by a list of handle + values. The integer indicates the number of handle values + in the list. The 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 to the new . 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 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 + 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 to OC_DELETE_HANDLE. + + The Message Body of any DELETE_HANDLE request is defined as follows: + + ::= + + where + + + 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 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 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 to OC_LIST_HANDLE. + + The Message Body of any LIST_HANDLE request is defined as follows: + + ::= + + where + + + 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 + + + ::= + + where + + + Number of handles (managed by the handle server) under the + naming authority. + + + 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 to OC_LIST_NA. + + The Message Body of any LIST_NA request is defined as follows: + + ::= + + where + + + 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 + + + ::= + + where + + + Number of handles (managed by the handle server) under the + naming authority. + + + 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 set to + OC_SESSION_SETUP and to 0. + + The Message Body of any SESSION_SETUP request is defined as follows: + + ::= + + where + + + 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 , the , and the + . Each of these attributes is + defined as follows: + + ::= + + + where + + + A UTF-8 string constant "HS_SESSION_IDENTITY". + + + + 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 + + + ::= + + where + + + A UTF-8 string constant "HS_SESSION_KEY_EXCHANGE". + + + One of the these tuples: , + , or + . + Each of these tuples is defined as follows: + + ::= + + where + + + A UTF-8 string constant "CLIENT_CIPHER". + + + A public key provided by the client and used + by the server to encrypt the session key. + + ::= + + + where + + + A UTF-8 string constant "HDL_CIPHER". + + + + A UTF-8 string followed by a 4-byte unsigned + integer. The and + 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. + + ::= + + where + + + + +Sun, et al. Informational [Page 44] + +RFC 3652 Handle System Protocol (v2.1) November 2003 + + + + 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 + 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. + + ::= + + where + + + A UTF-8 string constant "DIFFIE_HELLMAN" + + + 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. + + + ::= + + where + + + A UTF-8 string constant "HS_SESSION_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 field. + When this happens, the server should return an error message with + set to RC_PROTOCOL_ERROR. + + A SESSION_SETUP_REQUEST can be used to change session attributes of + any established session. This happens if the 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 + to OC_SESSION_SETUP. The 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 . 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 in the SESSION_SETUP request. If + or 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: + + + ::= + + [ ] + where + + + Message digest of the SESSION_SETUP request is as specified in + section 2.2.3. + + + 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 if the in + the SESSION_SETUP request provides the public key from the + client. + + + (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 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 to RC_SESSION_EXCHANGEKEY. The Message Body + of the SESSION_SETUP response must include the server's public key + and is defined as follows: + + + ::= + + + where + + + Message digest of the SESSION_SETUP request as specified in + section 2.2.3. + + + Public key from the server to be used for session key + exchange. It is encoded in the same format as the + record in the HS_SITE value (see section 3.2.2 in [2]). + +3.8.3. Session Key Exchange + + If the 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 + to OC_SESSION_EXCHANGEKEY and its to 0. The + Message Body of the SESSION_EXCHANGEKEY request is defined as + follows: + + + ::= + [ ] + + where + + + 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 + + + + + (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 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 + set to OC_SESSION_TERMINATE and its 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 + to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE + response must have its 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] + -- cgit v1.2.3