OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
randomly generated and updated frequently (as enforced by administrative policy). This
means that servers do not have DCE passwords; passwords should be used for human
login only.
In general, the domains of human and nonhuman users should be separate. For example,
a human user needs a password from a restricted domain (typable on the keyboard),
hence keys tied to passwords are generally less secure than keys not tied to passwords.
Furthermore, when keys are tied to passwords, key management is much harder.
Servers therefore should acquire their own nonhuman, server-specific identities.
Requiring a small amount of administrative overhead to set up a DCE identity for a
server-specific principal is not an onerous task for a server that is not frequently
installed. In an identity-based security system, the server’s principal name is the
essential persistent security datum for a server. Its importance is in some ways
equivalent to that of the server’s bindings.
One might complain that keeping keys in a keytab file places all of the server security
burden on the local operating system, and this is correct. But an alternative scheme,
such as requiring a user password to start a server, does nothing to improve on this.
Indeed, it is the cardinal fact of DCE security that, on any local system, it is only as
secure as the local operating system upon which it runs. It is therefore a sound policy to
make this dependency explicit rather than erecting an illusory layer of DCE security on
top of it.
3.3.6 Default Server Authentication Steps
The default model for server authentication consists of the following steps:
1. The server specifies a server-specific keytab file and server-specific principal
name when it calls rpc_server_register_auth_info().
2. The server acquires valid credentials for its server-specific identity via a series of
sec API calls.
3. The server does periodic key management by establishing a separate thread that
calls sec_key_mgmt_manage_key(). This keeps the server’s key up to date
according to local key management policies and thus prevents the server from
becoming inoperable because of an expired key.
4. The server contains code to check and, if necessary, revalidate and recertify its
credentials when undertaking operations that require valid credentials (such as
name service export and unexport operations).
The following sample functions, reproduced from the sample DCE application reprinted
in full in Appendix A, implement credential acquisition, credential revalidation, and key
management.
3− 10 Tandem Computers Incorporated 124246