Browse Prior Art Database

Key Manager for Multiple Distributed Computing Environment Servers

IP.com Disclosure Number: IPCOM000116458D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 103K

Publishing Venue

IBM

Related People

Lin, P: AUTHOR

Abstract

A method for centralizing the key management task in the Open Software Foundation's Distributed Computing Environment (OSF DCE) is disclosed. The method enables the keys of multiple servers (typically all servers located on a given machine) to be managed by one key manager.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Key Manager for Multiple Distributed Computing Environment Servers

      A method for centralizing the key management task in the Open
Software Foundation's Distributed Computing Environment (OSF DCE) is
disclosed.  The method enables the keys of multiple servers
(typically all servers located on a given machine) to be managed by
one key manager.

      In OSF DCE, each server that uses DCE security (e.g., through
authenticated remote procedure call) shares a key with the DCE
security server.  This key, which is the equivalent of a password for
a human user, must be changed periodically.  Currently, this is done
by having each server set up a thread for managing its own key, which
adds to application complexity and resource consumption.

      The key manager described in this disclosure maintains a key
store which contains a key set (current and N previous keys, as in
OSF DCE) for each server.  This key store can be implemented in
several ways, including:
  o  As a file protected by local access control
  o  As part of the machine's local security registry.

      The OSF DCE key management code is already architected to
support alternate forms of key storage.  This code is structured into
the following layers:
  o  Sec_key_mgmt_* routines: Key management interfaces exposed to
      application programmers
  o  Krb5_kt_* routines: Primitives key store operations, e.g., read
      from and write to key store
  o  Implementation of the krb5_kt_* primitives for a particular form
      of key storage, e.g., the krb5_ktf_* routines for file-based
      storage.  This is the layer to be supplied by the key manager.

      As an example, local-registry-based key storage can be added by
adding a set of krb5_ktl_* routines at the lowest layer to implement
the krb5_kt_* primitives over the local registry.

      Once the krb5_kt_* primitives have been implemented for the
given form of key storage, servers can use the (unchanged)
sec_key_mgmt_* and krb5_kt_* interfaces to retrieve their keys for
ticket decryption.

      There are at least two possible ways in which a server wishing
to have its key managed can interact with the key manager.
  o  Registration at server start-up time
     -  With this method, a server wishing to have its key managed
         registers with the key manager at start-up time.  At
         shut-down time, it de-registers with the key manager.
      -  If multiple instances of a server reside on the same machine
         (e.g., for load balancing), each of the servers can register
         with the key manager independently.  The key manager treats
         duplicate requests to manage the key of a given server
         principal as a single request.  Since there is only one
         updater of the server's key (i.e., the key manager),
problems
         related to having multiple upd...