[1629] in Kerberos
Re: Server (srvtab) ticket management.
daemon@ATHENA.MIT.EDU (Joe Pato)
Mon Nov 4 20:49:51 1991
From: pato@apollo.com (Joe Pato)
Date: Mon, 4 Nov 91 17:14:44 EST
To: rapatel@theophilus.rutgers.edu ( Rakesh Patel)
Cc: kerberos@Athena.MIT.EDU
In-Reply-To: rapatel@theophilus.rutgers.edu ( Rakesh Patel), mon, 4 nov 91 14:03:40
I am wondering how people are managing updates to srvtab from their
kerberos server. If you wanted to generate a new random key for a
kerberized server on a remote machine at a frequent interval (daily or
weekly), what would you do? It seems that if the srvtab fails to be
updated, the consqeunces of the services depending upon it may be a
problem for many sites. What procedures are recommended to ensure
that the keys are kept synchronized properly, but still updated
frequently? Suggestions? BTW, we are using Kerberos 5 not version 4.
Rakesh Patel,
Rutgers University.
The OSF DCE includes a "key management" library that will update keys in both
the local keytab and the network server in a synchronized manner. This library
includes a function which is intended to run in a background thread that will
generate new random keys at appropriate intervals - this operation allows
applications to ignore learning about expiration policy, while still changing
their key appropriately. This is part of the DCE and is designed to be
authentication system independent. DCE 1.0 is implemented using Kerberos V5,
but the DCE API is targetted for use with other authentications systems as
well. The full "sec_key_mgmt" library includes other functions to perform
synchronized updates generate a random key,
/* s e c _ k e y _ m g m t _ m a n a g e _ k e y
*
* Change the principal's key on a regular basis determined by the local
* cell's policy. This function will run indefinitely - it will never
* return during normal operation. It should be invoked from a thread
* that has been devoted to managing keys.
*
* This function queries the DCE registry to determine the passwd
* expiration policy that applies to the named principal. It then
* idles until a short time before the current key is due to expire
* and then uses the sec_key_mgmt_generate_key function to produce
* a new random key. (This function updates both the local key store
* and the DCE registry). This function also invokes
* sec_key_mgmt_garbage_collect as needed.
*
* Argument Usage:
* INPUT
* authn_service ** select the underlying authentication scheme
* arg ** key acquisition function argument (same value
* that is passed to rpc_server_register_auth_info.)
* principal_name ** names the principal whose key is to be changed
*
* ** see NOTE on authenticated RPC related arguments above.
*
* OUTPUT
* err error status if any.
*
* Errors:
* sec_key_mgmt_e_key_unavailable Old key not present, unable to use
* it to set a client side authentication
* context.
* sec_key_mgmt_e_authn_invalid Authentication service invalid.
* sec_key_mgmt_e_unauthorized Caller unauthorized to perform op.
*/
void sec_key_mgmt_manage_key (
[in] sec_key_mgmt_authn_service authn_service,
[in] void * arg,
[in] char * principal_name,
[out] error_status_t * err
);
-- Joe Pato
Cooperative Object Computing Division / East
Hewlett-Packard Company
pato@apollo.hp.com
-------
