refers to a public key used by the administrator, the verification-
response will contain the public key of the administrator.
Otherwise, the key-server will verify the challenge-response on
behalf of the requesting server and return the result in the
verification-response. The following diagram shows the control flow
of the authentication process where the key-reference refers to a
handle value that contains the administrator’s public (or secret) key
and the key-server is some other handle server.
-------- -------------
| | 1. client request. | |
| | -------------------------------> | |
| | | |
| | 2. session ID | |
| | + server’s challenge | |
| Handle | <------------------------------- | Handle |
| System | | server |
| client | 3. session ID | receiving |
| | + response to the challenge | client |
| | + administrator reference | request |
| | --------------------------------> | |
| | | |
| | 6. server acknowledgement | |
| | <------------------------------- | |
-------- -------------
| ^
4. Verification | | 5. verifi-
request | | cation
| | response
| | (signed)
V |
--------------------------
| The handle server (the |
| key-server) that manages |
| the key referenced by |
| the key-reference |
--------------------------
Figure 5.3: Authentication process requiring verification
from a second handle server
Secret key based authentication via a second handle server, i.e., the
key server, provides a convenient way to share a common secret key
(e.g., pass phrase) among handles managed by different handle
servers. However, it should not be used to manage highly sensitive
handles or handle data. The authentication process itself is
expensive and relies on a third party, i.e., the key-server, for
proper operation. Additionally, the secret key itself is subject to
dictionary attack since the key-server cannot determine whether the
verification-request comes from a legitimate handle server. A handle
service may set its local policy so that secret key based
authentication can only be carried out if the handle server
(receiving the client request) is also the key-server.
Local handle services may define additional local policies for
authentication and/or authorization. Handle System service
components may also choose to use other Internet authentication
mechanisms such as Kerberos [20] or some Transport Layer Security
protocol [21]. Details of these will be addressed in a separate
document.
6. Security Considerations
Handle System security considerations are discussed in the "Handle
System Overview" [1] and that discussion applies equally to this
document.
The Handle System delegates handle administration to each handle
administrator who may or may not be the server administrator. Handle
administrators are allowed to choose their own public/secret keys
used for authentication. The security of Handle System
authentication depends on the proper key selection and its
maintenance by the handle administrator. Handle administrators must
choose and protect their authentication keys carefully in order to
protect the handle data. Handle server implementations may deploy
policies that regulate the selection of public/secret keys used for
authentication. For example, a handle server may require that any
authentication key must be no less than certain number of bits. It
may also prohibit the use of secret keys because of the potential
dictionary attack.
The Handle System data model supports execution permission
(PUBLIC_EXECUTE, ADMIN_EXECUTE) for each handle value. While this
allows better sharing of network resources, it also raises many
security considerations. Execution privilege should be restricted
within the permissions of certain user account (corresponding to the
handle administrator) on the server to prevent system-wide
disruption. Switching between computing platforms for the server
should also be careful to avoid any unexpected behavior.
Implementations may choose not to support the execution permission,
or provide options so that it can be disabled.
To protect against any irresponsible use of system resource, handle
servers may implement quota control. The quota control can be used
to put limits on the number of handles under a naming authority, the
number of handle values allowed for any given handle, the maximum
size of any handle value, and the number of sub-naming authorities
under a naming authority. Handle servers must report error if the
result of a handle administration violates any of these limits.
7. 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.
8. References and Bibliography
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650,
November 2003.
[2] Mockapetris, P., "Domain Names - Concepts and Facilities," STD
13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] Yergeau, F., "UTF-8, A Transform Format for Unicode and
ISO10646", RFC 2279, January 1998.
[7] The Unicode Consortium, "The Unicode Standard, Version 2.0",
Addison-Wesley Developers Press, 1996. ISBN 0-201-48345-9
[8] Sun, S., Reilly, S. and L. Lannom, "Handle System Protocol (ver
2.1) Specification", RFC 3652, November 2003.
[9] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[10] 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.
[11] Federal Information Processing Standards Publication (FIPS PUB)
46-1, Data Encryption Standard, Reaffirmed 1988 January 22
(supersedes FIPS PUB 46, 1977 January 15).
[12] Federal Information Processing Standards Publication (FIPS PUB)
81, DES Modes of Operation, 1980 December 2.
[13] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423,
February 1993.
[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[15] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995.
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[17] CNRI Handle System Resolver, http://www.handle.net/resolver
[18] Grail browser home page, http://grail.sourceforge.net/
[19] Python language website, http://www.python.org/
[20] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[22] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[23] American National Standards Institute. ANSI X9.52-1998, Triple
Data Encryption Algorithm Modes of Operation. 1998.
9. 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-620-8990
EMail: llannom@cnri.reston.va.us
10. 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.