An application that wishes to perform the server side of the Kerberos protocol exchange is principally concerned with managing its keys. Keys are normally stored in keytab files which must be in the local host file system. The server needs local system permission to read and write them, and they must be protected from any access by other local identities.
Note: Keytab files are normally created by administrative action. Be aware that the local identity or the process running rgy_edit determines the initial local ownership of files created by ktadd.
This means that the server needs its own local identity too, to correspond to its DCE identity. Keytab files should be owned by this local identity. The programmer or installer must arrange for the server to run under this local identity, and only a locally privileged user should have execute permission for the server. On UNIX systems this can be arranged by having the server run setuid( ) to the chosen local identity and giving execute permission only to specific local users.
Because the degree of integration between local and DCE login varies with DCE implementations, it is difficult to give more general advice about local identities. As the following paragraphs explain, however, it is generally not a good idea for the server to run with the DCE identity of a human user. If DCE and local identities are the same, the same guideline must be applied to local identities. That is, the server's local identity should not be that of a human user.
When a server is initialized, it will get its key from its keytab file. The keys installed in keytab files should not be tied to some human readable password: that is, they should be 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 (typeable 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.