OSF DCE Application Development Guide--Core Components

DCE Host Services
2.8 Managing Server Key Tables
Keys for servers are analogous to passwords for human users. Keys also play a major
role in authenticated remote procedure calls. Keys have some similarities with
passwords. For example, server keys and user passwords have to follow the same change
policy (or a more stringent one) for a given host or cell. This means that, just as a user
has to periodically come up with a new password, a server has to periodically generate a
new key. It is easy to see that a human user protects a password by memorizing it. But a
server ‘‘memorizes’’ a key by storing it in a file called a key table.
It is more complex for a server to change keys than it is for a human user to change a
password. For example, a human user needs to only remember the latest password, but a
server may need to maintain a history of its keys by using version numbers so that
currently active clients do not have difficulty completing a remote procedure call. When
a client prepares to make authenticated remote procedure calls, it obtains a ticket to talk
with the server. (The security registry of the authentication service encrypts this ticket
by using the server’s key, and later the server decrypts the ticket when it receives the
remote procedure call.)
Timing can become an issue when a client makes a remote procedure call because tickets
have a limited lifetime before they expire, and servers must also change their keys on a
regular basis. Assuming the client posesses a valid ticket, suppose that, by the time the
client makes the call, the server has generated a new key. If a server maintains versions
of its keys, the client can still complete the call. Authentication is described in detail in
Chapter 23.
A key table usually contains keys stored by one server, and it must be located on the
same host as that server. However, a key table can hold keys for a set of related servers,
as long as all the servers reside on the same host. Servers usually maintain their own
keys, and Chapter 30 describes the API they use. Administrators can remotely manage
key tables and the keys in the tables by using the dcecp keytab object. This section
describes the API routines that management applications can use to manage the key
tables and keys of other servers on the network.
Suppose you discover that a server or an entire host’s security has been compromised.
Applications can use the dced_keytab_change_key() routine to change a key table’s
key. The following example shows how to reset the key for all key tables on a specified
host:
dced_binding_handle_t dced_bh;
dced_entry_list_t entries;
unsigned32 i;
error_status_t status;
dced_key_t key;
dced_binding_create("keytab@hosts/somehost",
dced_c_binding_syntax_default,
&dced_bh,
&status);
124245 Tandem Computers Incorporated 2− 25