OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
From the RPC point of view, the basic model is that servers are persistent entities in the
sense that they normally perform services on behalf of more than one client principal
session. This may mean that servers are persistent in time: that is, that they run for a long
time, possibly for as long as the machine they are running on is up and running. But
even servers that are invoked on demand (and therefore that run for a short period of
time) can be invoked by multiple clients and, during their short lives, may well perform
services for clients other than the invoker.
Clients, on the other hand, will typically be invoked by an interactive principal to run
within the scope of a single principal login session. Such clients can therefore usefully
acquire their credentials from the principal who invoked them. Note, however, that there
is nothing to require clients to behave in this manner. A persistent client can easily be
written that assumes its own identity, manages keys, and acquires and updates
credentials. The basic authentication policies described here can be easily extended to
cover this case.
For a client that runs with an inherited identity, the principal security problem—the
maintainance of its secrets—is reduced to the problem of maintaining the security of its
credentials while they are valid. The client is basically passive in this respect, depending
on the local operating system to prevent unauthorized access to the credential cache of
the DCE principal that initiates the client application. Direct management and discovery
of keys (for example, reading them from a configuration file) is not required of such
clients. Typically, such an application can do nothing about the security of the
principal’s keys used to acquire credentials, since all the authentication-related state is
inherited. The client’s real security responsibility is therefore negative: not to take any
action outside of the specified authentication policy model that could compromise
security for the identity with which it runs (for example, indiscriminately giving other
processes access to its credentials).
Clients may or may not be concerned with the identities of the servers they call. The
Kerberos authentication exchange is mutual in the sense that both clients and servers
must have genuine authentication identities to participate successfully. However, a
client may not trust a server simply because it can successfully authenticate to the client.
The client may want to make RPCs only to servers with specific principal identities that
it trusts. In this case, the client has the additional security task of safely maintaining a
list of acceptable server identities with which it is willing to communicate.
1
For the server, the basic authentication problem imposed by the DCE secret key
authentication protocol is the maintainance of keys. This depends on local operating
________________
1. This is another of the basic asymmetries of the Kerberos-based security mechanism. Servers can control client
access by demanding that the client be authenticated and then making authorization decisions based on the client’s
authenticated privilege attributes. Clients can only require that the servers they call be authenticated. This leaves
the client with three server authentication options:
1. The client doesn’t care about the identity of the server.
2. The client demands that the server be authenticated, but does not care which authenticated identity the
server uses.
3. The client only trusts principal identities known to it directly or indirectly, such as by being a member of a
trusted group.
Application steps for checking authenticated server identity are discussed in Section 3.3.
3− 6 Tandem Computers Incorporated 124246