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 possesses 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 Authentication.
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 The Key Management API describes the API they use. Administrators can remotely manage key tables and the keys in the tables by using the dcecp keytab object. This topic 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);
dced_binding_set_auth_info(dced_bh,
rpc_c_protect_level_default,
rpc_c_authn_default,
NULL,
rpc_c_authz_dce,
&status);
dced_list_get(dced_bh, &entries, &status);
for(i=0; i<entries.count; i++) {
generate_new_key(&key); /* application specific */
dced_keytab_change_key(dced_bh, &entries.list[i].id, &key, &status);
}
dced_list_release(dced_bh, &entries, &status);
dced_binding_free( dced_bh, &status);
dced_binding_create( )
This routine creates a dced binding to a dced service on a specified host. The binding handle created is used in all subsequent calls
to appropriate dced API routines. The keytab portion of the first argument represents the well-known name of the keytab service. When this string is used by itself, it refers to
the service on the local host.
dced_binding_set_auth_info( )
Accessing keytab data requires authenticated remote procedure calls. The dced_binding_set_auth_info( ) routine sets
authentication for the dced binding handle, dced_bh.
dced_list_get( )
Applications use the dced_list_get( ) routine to get a service's entire list of names.
generate_new_key( )
This application-specific routine generates the new key and fills in a dced_key_t data structure. This routine could use the
sec_key_mgmt_gen_rand_key( ) routine to randomly generate a new key.
dced_keytab_change_key( )
The dced_keytab_change_key( ) routine tries to change the principal's key in the security service's registry first. If that is successful, it
changes the key in the key table.
dced_list_release( )
Each call to the dced_list_get( ) routine requires a corresponding call to dced_list_release( ) to release the resources allocated for the
entry list.
dced_binding_free( )
Each call to the dced_binding_create( ) routine requires a corresponding call to dced_binding_free( ) to release the resources allocated
for a dced binding handle.
For more detailed key table management, applications can peruse a key table's list of keys by using the dced_keytab_initialize_cursor( ), dced_keytab_get_next_key( ), and dced_keytab_release_cursor( ) routines. Reading key table data remotely presents a greater security risk because data is sent over the network. For remote access, these routines actually get all the keys during one remote procedure call to be more efficient and to minimize the time keys are being sent over the network.
Earlier in this topic we described how to change the key of a key table with the dced_keytab_change_key( ) routine. The key table management service also provides the routines dced_keytab_add_key( ) and dced_keytab_remove_key( ) to control key modification in even greater detail.
Finally, you can create a new key table by using dced_keytab_create( ), or you can delete an existing key table by using dced_keytab_delete( ).