tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3652

Informational
Pages: 53
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~handle

Handle System Protocol (ver 2.1) Specification

Part 1 of 2, p. 1 to 23
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
   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.

Top      ToC       Page 4 
      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.

Top      ToC       Page 5 
          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.

Top      ToC       Page 6 
         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.

Top      ToC       Page 7 
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.

Top      ToC       Page 8 
      .----------------------.
      |                      |  ; 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                                   |
      '---------------------------------------------------------------'

Top      ToC       Page 9 
2.2.1.1.  <MajorVersion> and <MinorVersion>

   The <MajorVersion> and <MinorVersion> are used to identify the
   version of the Handle protocol.  Each of them is defined as a one-
   byte unsigned integer.  This specification defines the protocol
   version whose <MajorVersion> is 2 and <MinorVersion> is 1.

   <MajorVersion> and <MinorVersion> are designed to allow future
   backward compatibility.  A difference in <MajorVersion> indicates
   major variation in the protocol format and the party with the lower
   <MajorVersion> will have to upgrade its software to ensure precise
   communication.  An increment in <MinorVersion> is made when
   additional capabilities are added to the protocol without any major
   change to the message format.

2.2.1.2.  <MessageFlag>

   The <MessageFlag> consists of two octets defined as follows:

                                               1   1   1   1   1   1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
      .---------------------------------------------------------------.
      |CP |EC |TC |       Reserved                                    |
      '---------------------------------------------------------------'

   Bit 0 is the CP (ComPressed) flag that indicates whether the message
   (excluding the Message Envelope) is compressed.  If the CP bit is set
   (to 1), the message is compressed.  Otherwise, the message is not
   compressed.  The Handle protocol uses the same compression method as
   used by the FTP protocol[8].

   Bit 1 is the EC (EnCrypted) flag that indicates whether the message
   (excluding the Message Envelope) is encrypted.  The EC bit should
   only be set under an established session where a session key is in
   place.  If the EC bit is set (to 1), the message is encrypted using
   the session key.  Otherwise the message is not encrypted.

   Bit 2 is the TC (TrunCated) flag that indicates whether this is a
   truncated message.  Message truncation happens most often when
   transmitting a large message over the UDP protocol.  Details of
   message truncation (or fragmentation) will be discussed in section
   2.3.

   Bits 3 to 15 are currently reserved and must be set to zero.

Top      ToC       Page 10 
2.2.1.3.  <SessionId>

   The <SessionId> is a four-byte unsigned integer that identifies a
   communication session between the client and server.

   Session and its <SessionId> are assigned by a server, either upon an
   explicit request from a client or when multiple message exchanges are
   expected to fulfill the client's request.  For example, the server
   will assign a unique <SessionId> in its response if it has to
   authenticate the client.  A client may explicitly ask the server to
   set up a session as a virtually private communication channel like
   SSL [4].  Requests from clients without an established session must
   have their <SessionId> set to zero.  The server must assign a unique
   non-zero <SessionId> for each new session.  It is also responsible
   for terminating those sessions that are not in use after some period
   of time.

   Both clients and servers must maintain the same <SessionId> for
   messages exchanged under an established session.  A message whose
   <SessionId> is zero indicates that no session has been established.

   The session and its state information may be shared among multiple
   handle operations.  They may also be shared over multiple TCP
   connections as well.  Once a session is established, both client and
   server must maintain their state information according to the
   <SessionId>.  The state information may include the stage of the
   conversation, the other party's authentication information, and the
   session key that was established for message encryption or
   authentication.  Details of these are discussed in section 3.8.

2.2.1.4.  <RequestId>

   Each request from a client is identified by a <RequestId>, a 4-byte
   unsigned integer set by the client.  Each <RequestId> must be unique
   from all other outstanding requests from the same client.  The
   <RequestId> allows the client to keep track of its requests, and any
   response from the server must include the correct <RequestId>.

2.2.1.5.  <SequenceNumber>

   Messages under the Handle protocol may be truncated during their
   transmission (e.g., under UDP).  The <SequenceNumber> is a 4-byte
   unsigned integer used as a counter to keep track of each truncated
   portion of the original message.  The message recipient can
   reassemble the original message based on the <SequenceNumber>.  The
   <SequenceNumber> must start with 0 for each message.  Each truncated
   message must set its TC flag in the Message Envelope.  Messages that
   are not truncated must set their <SequenceNumber> to zero.

Top      ToC       Page 11 
2.2.1.6.  <MessageLen>

   A 4-byte unsigned integer that specifies the total number of octets
   of any message, excluding those in the Message Envelope.  The length
   of any single message exchanged under the Handle protocol is limited
   by the range of a 4-byte unsigned integer.  Longer data can be
   transmitted as multiple messages with a common <RequestId>.

2.2.2.   Message Header

   The Message Header contains the common data elements among any
   protocol operation.  It has a fixed size of 24 octets and consists of
   eight fields.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      .---------------------------------------------------------------.
      |                     OpCode                                    |
      |---------------------------------------------------------------|
      |                     ResponseCode                              |
      |---------------------------------------------------------------|
      |                     OpFlag                                    |
      |---------------------------------------------------------------|
      |     SiteInfoSerialNumber      | RecursionCount|               |
      |---------------------------------------------------------------|
      |                     ExpirationTime                            |
      |---------------------------------------------------------------|
      |                     BodyLength                                |
      '---------------------------------------------------------------'

   Every message that is not truncated must have a Message Header.  If a
   message has to be truncated for its transmission, the Message Header
   must appear in the first truncated portion of the message.

   This is different from the Message Envelope, which appears in each
   truncated portion of the message.

2.2.2.1.  <OpCode>

   The <OpCode> stands for operation code, which is a four-byte unsigned
   integer that specifies the intended operation.  The following table
   lists the <OpCode>s that MUST be supported by all implementations in
   order to conform to the base protocol specification.  Each operation
   code is given a symbolic name that is used throughout this document
   for easy reference.

Top      ToC       Page 12 
       Op_Code    Symbolic Name            Remark
      ---------   -------------            ------

          0       OC_RESERVED              Reserved
          1       OC_RESOLUTION            Handle query
          2       OC_GET_SITEINFO          Get HS_SITE values

        100       OC_CREATE_HANDLE         Create new handle
        101       OC_DELETE_HANDLE         Delete existing handle
        102       OC_ADD_VALUE             Add handle value(s)
        103       OC_REMOVE_VALUE          Remove handle value(s)
        104       OC_MODIFY_VALUE          Modify handle value(s)
        105       OC_LIST_HANDLE           List handles
        106       OC_LIST_NA               List sub-naming authorities

        200       OC_CHALLENGE_RESPONSE    Response to challenge
        201       OC_VERIFY_RESPONSE       Verify challenge response

        300
         :        { Reserved for handle server administration }
        399

        400       OC_SESSION_SETUP         Session setup request
        401       OC_SESSION_TERMINATE     Session termination request
        402       OC_SESSION_EXCHANGEKEY   Session key exchange

   A detailed description of each of these <OpCode>s can be found in
   section 3 of this document.  In general, clients use the <OpCode> to
   tell the server what kind of handle operation they want to
   accomplish.  Response from the server must maintain the same <OpCode>
   as the original request and use the <ResponseCode> to indicate the
   result.

2.2.2.2.  <ResponseCode>

   The <ResponseCode> is a 4-byte unsigned integer that is given by a
   server to indicate the result of any service request.  The list of
   <ResponseCode>s used in the Handle protocol is defined in the
   following table.  Each response code is given a symbolic name that is
   used throughout this document for easy reference.

Top      ToC       Page 13 
      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

Top      ToC       Page 14 
   Response codes under 10000 are reserved for system use.  Any message
   with a response code under 10000 but not listed above should be
   treated as an unknown error.  Response codes above 10000 are user
   defined and can be used for application specific purposes.

   Detailed descriptions of these <ResponseCode>s can be found in
   section 3 of this document.  In general, any request from a client
   must have its <ResponseCode> set to 0.  The response message from the
   server must have a non-zero <ResponseCode> to indicate the result.
   For example, a response message from a server with <ResponseCode> set
   to RC_SUCCESS indicates that the server has successfully fulfilled
   the client's request.

2.2.2.3.  <OpFlag>

   The <OpFlag> is a 32-bit bit-mask that defines various control
   options for protocol operation.  The following figure shows the
   location of each option flag in the <OpFlag> field.

                                              1   1   1   1   1   1
      0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
      .---------------------------------------------------------------.
      |AT |CT |ENC|REC|CA |CN |KC |PO |RD |    Reserved               |
      |---------------------------------------------------------------|
      |                              Reserved                         |
      '---------------------------------------------------------------'

       AT   -  AuThoritative bit.  A request with the AT bit set (to 1)
               indicates that the request should be directed to the
               primary service site (instead of any mirroring sites).  A
               response message with the AT bit set (to 1) indicates
               that the message is returned from a primary server
               (within the primary service site).

       CT   -  CerTified bit.  A request with the CT bit set (to 1) asks
               the server to sign its response with its digital
               signature.  A response with the CT bit set (to 1)
               indicates that the message is signed.  The server must
               sign its response if the request has its CT bit set (to
               1).  If the server fails to provide a valid signature in
               its response, the client should discard the response and
               treat the request as failed.

       ENC  -  ENCryption bit.  A request with the ENC bit set (to 1)
               requires the server to encrypt its response using the
               pre-established session key.

Top      ToC       Page 15 
       REC  -  RECursive bit.  A request with the REC bit set (to 1)
               asks the server to forward the query on behalf of the
               client if the request has to be processed by another
               handle server.  The server may honor the request by
               forwarding the request to the appropriate handle server
               and passing on any result back to the client.  The server
               may also deny any such request by sending a response
               with <ResponseCode> set to RC_SERVER_NOT_RESP.

       CA   -  Cache Authentication.  A request with the CA bit set (to
               1) asks the caching server (if any) to authenticate any
               server response (e.g., verifying the server's signature)
               on behalf of the client.  A response with the CA bit set
               (to 1) indicates that the response has been
               authenticated by the caching server.

       CN   -  ContiNuous bit.  A message with the CN bit set (to 1)
               tells the message recipient that more messages that are
               part of the same request (or response) will follow.  This
               happens if a request (or response) has data that is too
               large to fit into any single message and has to be
               fragmented into multiple messages.

       KC   -  Keep Connection bit.  A message with the KC bit set
               requires the message recipient to keep the TCP
               connection open (after the response is sent back).  This
               allows the same TCP connection to be used for multiple
               handle operations.

       PO   -  Public Only bit.  Used by query operations only.  A query
               request with the PO bit set (to 1) indicates that the
               client is only asking for handle values that have the
               PUB_READ permission.  A request with PO bit set to zero
               asks for all the handle values regardless of their read
               permission.  If any of the handle values require
               ADMIN_READ permission, the server must authenticate the
               client as the handle administrator.

       RD   -  Request-Digest bit.  A request with the RD bit set (to 1)
               asks the server to include in its response the message
               digest of the request.  A response message with the RD
               bit set (to 1) indicates that the first field in the
               Message Body contains the message digest of the original
               request.  The message digest can be used to check the
               integrity of the server response.  Details of these are
               discussed later in this document.

Top      ToC       Page 16 
   All other bits in the <OpFlag> field are reserved and must be set to
   zero.

   In general, servers must honor the <OpFlag> specified in the request.
   If a requested option cannot be met, the server should return an
   error message with the proper <ResponseCode> as defined in the
   previous section.

2.2.2.4.  <SiteInfoSerialNumber>

   The <SiteInfoSerialNumber> is a two-byte unsigned integer.  The
   <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of
   the HS_SITE value used by the client (to access the server).  Servers
   can check the <SiteInfoSerialNumber> in the request to find out if
   the client has up-to-date service information.

   When possible, the server should fulfill a client's request even if
   the service information used by the client is out-of-date.  However,
   the response message should specify the latest version of service
   information in the <SiteInforSerialNumber> field.  Clients with out-
   of-date service information can update the service information from
   the Global Handle Registry.  If the server cannot fulfill a client's
   request due to expired service information, it should reject the
   request and return an error message with <ResponseCode> set to
   RC_EXPIRED_SITE_INFO.

2.2.2.5.  <RecursionCount>

   The <RecursionCount> is a one-byte unsigned integer that specifies
   the number of service recursions.  Service recursion happens if the
   server has to forward the client's request to another server.  Any
   request directly from the client must have its <RecursionCount> set
   to 0.  If the server has to send a recursive request on behalf of the
   client, it must increment the <RecursionCount> by 1.  Any response
   from the server must maintain the same <RecursionCount> as the one in
   the request.  To prevent an infinite loop of service recursion, the
   server should be configurable to stop sending a recursive request
   when the <RecursionCount> reaches a certain value.

2.2.2.6.  <ExpirationTime>

   The <ExpirationTime> is a 4-byte unsigned integer that specifies the
   time when the message should be considered expired, relative to
   January 1st, 1970 GMT, in seconds.  It is set to zero if no
   expiration is expected.

Top      ToC       Page 17 
2.2.2.7.  <BodyLength>

   The <BodyLength> is a 4-byte unsigned integer that specifies the
   number of octets in the Message Body.  The <BodyLength> does not
   count the octets in the Message Header or those in the Message
   Credential.

2.2.3.  Message Body

   The Message Body always follows the Message Header.  The number of
   octets in the Message Body can be determined from the <BodyLength> in
   the Message Header.  The Message Body may be empty.  The exact format
   of the Message Body depends on the <OpCode> and the <ResponseCode> in
   the Message Header.  Details of the Message Body under each <OpCode>
   and <ResponseCode> are described in section 3 of this document.

   For any response message, if the Message Header has its RD bit (in
   <OpFlag>) set to 1, the Message Body must begin with the message
   digest of the original request.  The message digest is defined as
   follows:

      <RequestDigest> ::= <DigestAlgorithmIdentifier>
                          <MessageDigest>

         where

            <DigestAlgorithmIdentifier>
            An octet that identifies the algorithm used to generate the
            message digest.  If the octet is set to 1, the digest is
            generated using the MD5 [9] algorithm.  If the octet is set
            to 2, SHA-1 [10] algorithm is used.

            <MessageDigest>
            The message digest itself.  It is calculated upon the
            Message Header and the Message Body of the original request.
            The length of the field is fixed according to the digest
            algorithm.  For MD5 algorithm, the length is 16 octets.  For
            SHA-1, the length is 20 octets.

   The Message Body may be truncated into multiple portions during its
   transmission (e.g., over UDP).  Recipients of such a message may
   reassemble the Message Body from each portion based on the
   <SequenceNumber> in the Message Envelope.

Top      ToC       Page 18 
2.2.4.  Message Credential

   The Message Credential is primarily used to carry any digital
   signatures signed by the message issuer.  It may also carry the
   Message Authentication Code (MAC) if a session key has been
   established.  The Message Credential is used to protect contents in
   the Message Header and the Message Body from being tampered with
   during transmission.  The format of the Message Credential is
   designed to be semantically compatible with PKCS#7 [5].  Each Message
   Credential consists of the following fields:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      .---------------------------------------------------------------.
      |           CredentialLength                                    |
      |---------------------------------------------------------------|
      |   Version     |    Reserved   |       Options                 |
      |---------------------------------------------------------------|
      |
      |   Signer: <Handle, Index>
      |
      |---------------------------------------------------------------|
      |           Type      (UTF8-String)                             |
      |---------------------------------------------------------------|
      |
      |   SignedInfo: <Length> : 4-byte unsigned integer
      |               DigestAlgorithm: <UTF8-String>
      |               SignedData: <Length, Signature>
      |
      '---------------------------------------------------------------'

   where

      <CredentialLength>
      A 4-byte unsigned integer that specifies the number of octets in
      the Message Credential.  It must be set to zero if the message has
      no Message Credential.

      <Version>
      An octet that identifies the version number of the Message
      Credential.  The version number specified in this document is
      zero.

      <Reserved>
      An octet that must be set to zero.

      <Options>
      Two octets reserved for various cryptography options.

Top      ToC       Page 19 
      <Signer> ::= <HANDLE>
                   <INDEX>
      A reference to a handle value in terms of the <HANDLE> and the
      <INDEX> of the handle value.  The handle value may contain the
      public key, or the X.509 certificate, that can be used to
      validate the digital signature.

      <Type>
      A UTF8-String that indicates the type of content in the
      <SignedInfo> field (described below).  It may contain HS_DIGEST if
      <SignedInfo> contains the message digest, or HS_MAC if
      <SignedInfo> contains the Message Authentication Code (MAC).  The
      <Type> field will specify the signature algorithm identifier if
      <SignedInfo> contains a digital signature.  For example, with the
      <Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will
      contain the digital signature generated using the RSA-PSS
      algorithm [16].  If the <Type> field is set to HS_SIGNED, the
      <SignedInfo> field will contain the digital signature generated
      from a DSA public key pair.

      <SignedInfo> ::=  <Length>
                        <DigestAlgorithm>
                        <SignedData>
         where

            <Length>
            A 4-byte unsigned integer that specifies the number of
            octets in the <SignedInfo> field.

            <DigestAlgorithm>
            A UTF8-String that refers to the digest algorithm used to
            generate the digital signature.  For example, the value
            "SHA-1" indicates that the SHA-1 algorithm is used to
            generate the message digest for the signature.

            <SignedData> ::=  <LENGTH>
                            <SIGNATURE>
               where

                  <LENGTH>
                  A 4-byte unsigned integer that specifies the number of
                  octets in the <SIGNATURE>.

                  <SIGNATURE>
                  Contains the digital signature or the MAC over the
                  Message Header and Message Body.  The syntax and
                  semantics of the signature depend on the <Type> field

Top      ToC       Page 20 
                  and the public key referenced in the <Signer> field.
                  For example, if the <Type> field is "HS_SIGNED" and
                  the public key referred to by the <Signer> field is
                  a DSA [6] public key, the signature will be the
                  ASN.1 octet string representation of the parameter R
                  and S as described in [7].  If the <Signer> field
                  refers to a handle value that contains a X.509
                  certificate, the signature should be encoded according
                  to RFC 3279 and RFC 3280 [14, 15].

   The Message Credential may contain the message authentication code
   (MAC) generated using a pre-established session key.  In this case,
   the <Signer> field must set its <HANDLE> to a zero-length UTF8-String
   and its <INDEX> to the <SessionId> specified in the Message Envelope.
   The <Signature> field must contain the MAC in its <SIGNATURE> field.
   The MAC is the result of the one-way hash over the concatenation of
   the session key, the <Message Header>, the <MessageBody>, and the
   session key again.

   The Message Credential in a response message may contain the digital
   signature signed by the server.  The server's public key can be found
   in the service information used by the client to send the request to
   the server.  In this case, the client should ignore any reference in
   the <Signer> field and use the public key in the service information
   to verify the signature.

   The Message Credential can also be used for non-repudiation purposes.
   This happens if the Message Credential contains a server's digital
   signature.  The signature may be used as evidence to demonstrate that
   the server has rendered its service in response to a client's
   request.

   The Message Credential provides a mechanism for safe transmission of
   any message between the client and server.  Any message whose Message
   Header and Message Body complies with its Message Credential suggests
   that the message indeed comes from its originator and assures that
   the message has not been tampered with during its transmission.

2.3.  Message Transmission

   A large message may be truncated into multiple packets during its
   transmission.  For example, to fit the size limit of a UDP packet,
   the message issuer must truncate any large message into multiple UDP
   packets before its transmission.  The message recipient must
   reassemble the message from these truncated packets before further
   processing.  Message truncation must be carried out over the entire

Top      ToC       Page 21 
   message except the Message Envelope.  A new Message Envelope has to
   be inserted in front of each truncated packet before its
   transmission.  For example, a large message that consists of

      .--------------------------------------------------------.
      |  Message Envelope  |  Message Header, Body, Credential |
      '--------------------------------------------------------'

   may be truncated into:

         .--------------------------------------------.
         |  Message Envelope 1 |  Truncated_Packet 1  |
         '--------------------------------------------'
         .--------------------------------------------.
         |  Message Envelope 2 |  Truncated_Packet 2  |
         '--------------------------------------------'

            ......

         .--------------------------------------------.
         |  Message Envelope N |  Truncated Packet N  |
         '--------------------------------------------'

   where the "Truncated_packet 1", "Truncated_packet 2", ..., and
   "Truncated_packet N" result from truncating the Message Header, the
   Message Body and the Message Credential.  Each "Message Envelope i"
   (inserted before each truncation) must set its TC flag to 1 and
   maintain the proper sequence count (in the <SequenceNumber>).  Each
   "Message Envelope i" must also set its <MessageLength> to reflect the
   size of the packet.  The recipient of these truncated packets can
   reassemble the message by concatenating these packets based on their
   <SequenceNumber>.

3.  Handle Protocol Operations

   This section describes the details of each protocol operation in
   terms of messages exchanged between the client and server.  It also
   defines the format of the Message Body according to each <OpCode> and
   <ResponseCode> in the Message Header.

3.1.  Client Bootstrapping

3.1.1.  Global Handle Registry and its Service Information

   The service information for the Global Handle Registry (GHR) allows
   clients to contact the GHR to find out the responsible service
   components for their handles.  The service information is a set of
   HS_SITE values assigned to the root handle "0.NA/0.NA" and is also

Top      ToC       Page 22 
   called the root service information.  The root service information
   may be distributed along with the client software, or be downloaded
   from the Handle System website at http://www.handle.net.

   Changes to the root service information are identified by the
   <SerialNumber> in the HS_SITE values.  A server at GHR can find out
   if the root service information used by the client is outdated by
   checking the <SerialNumber> in the client's request.  The client
   should update the root service information if the <ResponseCode> of
   the response message is RC_EXPIRED_SITE_INFO.  Clients may obtain the
   most up-to-date root service information from the root handle.  The
   GHR must sign the root service information using the public key
   specified in the outdated service information (identified in the
   client's request) so that the client can validate the signature.

3.1.2.  Locating the Handle System Service Component

   Each handle under the Handle System is managed by a unique handle
   service component (e.g., LHS).  For any given handle, the responsible
   service component (and its service information) can be found from its
   naming authority handle.  Before resolving any given handle, the
   client needs to find the responsible service component by querying
   the naming authority handle from the GHR.

   For example, to find the responsible LHS for the handle "1000/abc",
   client software can query the GHR for the HS_SITE (or HS_SERV) values
   assigned to the naming authority handle "0.NA/1000".  The set of
   HS_SITE values provides the service information of the LHS that
   manages every handle under the naming authority "1000".  If no
   HS_SITE values are found, the client can check if there is any
   HS_SERV value assigned to the naming authority handle.  The HS_SERV
   value provides the service handle that maintains the service
   information for the LHS.  Service handles are used to manage the
   service information shared by different naming authorities.

   It is possible that the naming authority handle requested by the
   client does not reside at the GHR.  This happens when naming
   authority delegation takes place.  Naming authority delegation
   happens when a naming authority delegates an LHS to manage all its
   child naming authorities.  In this case, the delegating naming
   authority must contain the service information, a set of
   HS_NA_DELEGATE values, of the LHS that manages its child naming
   authorities.

   All top-level naming authority handles must be registered and managed
   by the GHR.  When a server at the GHR receives a request for a naming
   authority that has been delegated to an LHS, it must return a message
   with the <ResponseCode> set to RC_NA_DELEGATE, along with the

Top      ToC       Page 23 
   HS_NA_DELAGATE values from the nearest ancestor naming authority.
   The client can query the LHS described by the HS_NA_DELAGATE values
   for the delegated naming authority handle.  In practice, the ancestor
   naming authority should make itself available to any handle server
   within the GHR, by replicating itself at the time of delegation.
   This will prevent any cross-queries among handle servers (within a
   service site) when the naming authority in query and the ancestor
   naming authority do not hash into the same handle server.

3.1.3.  Selecting the Responsible Server

   Each handle service component is defined in terms of a set of HS_SITE
   values.  Each of these HS_SITE values defines a service site within
   the service component.  A service site may consist of a group of
   handle servers.  For any given handle, the responsible handle server
   within the service component can be found following this procedure:

      1. Select a preferred service site.

         Each service site is defined in terms of an HS_SITE value.  The
         HS_SITE value may contain a <Description> or other attributes
         (under the <AttributeList>) to help the selection.  Clients
         must select the primary service site for any administrative
         operations.

      2. Locate the responsible server within the service site.

         This can be done as follows: Convert every ASCII character in
         the handle to its upper case.  Calculate the MD5 hash of the
         converted handle string according to the <HashOption> given in
         the HS_SITE value.  Take the last 4 bytes of the hash result as
         a signed integer.  Modulo the absolute value of the integer by
         the <NumOfServer> given in the HS_SITE value.  The result is
         the sequence number of the <ServerRecord> listed in the HS_SITE
         value.  For example, if the result of the modulation is 2, the
         third <ServerRecord> listed in the <HS_SITE> should be
         selected.  The <ServerRecord> defines the responsible handle
         server for the given handle.

3.2.  Query Operation

   A query operation consists of a client sending a query request to the
   responsible handle server and the server returning the query result
   to the client.  Query requests are used to retrieve handle values
   assigned to any given handle.


Next RFC Part