<RequestDigest>
Message digest of the SESSION_SETUP request as specified in
section 2.2.3.
<Public Key for Session Key Exchange>
Public key from the server to be used for session key
exchange. It is encoded in the same format as the <PublicKey>
record in the HS_SITE value (see section 3.2.2 in [2]).
3.8.3. Session Key Exchange
If the <ResponseCode> of a SESSION_SETUP response is
RC_SESSION_EXCHANGEKEY, the client is responsible for generating the
session key and sending it to the server. In this case, the client
can generate a session key, encrypt it with the public key provided
by the server in the SESSION_SETUP response, and send the encrypted
session key to the server in a SESSION_EXCHANGEKEY request.
The Message Header of the SESSION_EXCHANGEKEY request must set its
<OpCode> to OC_SESSION_EXCHANGEKEY and its <ResponseCode> to 0. The
Message Body of the SESSION_EXCHANGEKEY request is defined as
follows:
<Message Body of OC_SESSION_EXCHANGEKEY>
::= <Encrypted Session Key>
[ <EncryptionAlgorithm> ]
where
<EncryptedSessionKey>
Session key encrypted using the public key provided in the
SESSION_SETUP response. The session key is a randomly
generated octet string by the client.
<EncryptionAlgorithm>
(optional) UTF-8 string that identifies the encryption
algorithm used by the session key.
During the session key exchange, the server receiving the exchange
key or session key has the responsibility of ensuring that the key
meets the security requirements defined in its local policy. If the
server considers the key being volunable, it must return an error
message to the client with <ResponseCode> set to
RC_SESSION_KEY_INVALID.
3.8.4. Session Termination
Clients can terminate a session with a SESSION_TERMINATE request.
The Message Header of a SESSION_TERMINATE request must have its
<OpCode> set to OC_SESSION_TERMINATE and its <ResponseCode> to 0.
The message body of any SESSION_TERMINATE request must be empty.
The server must send a SESSION_TERMINATE response to the client after
the session is terminated. The server should only terminate the
session after it has finished processing all the requests (under the
session) that were submitted before the Session Termination request.
The message header of the SESSION_TERMINATE response must set its
<OpCode> to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE
response must have its <ResponseCode> set to RC_SUCCESS, and an empty
message body.
4. Implementation Guidelines
4.1. Server Implementation
The optimal structure for any handle server will depend on the host
operating system. This section only addresses those implementation
considerations that are common to most handle servers.
A good server implementation should allow easy configuration or
fine-tuning. A suggested list of configurable items includes the
server’s network interface(s) (e.g., IP address, port number, etc.),
the number of concurrent processes/threads allowed, time-out
intervals for any TCP connection and/or authentication process, re-
try policy under UDP connection, policies on whether to support
recursive service, case-sensitivity for ASCII characters, and
different levels of transaction logging, etc.
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].
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/
[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
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
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.