One of the obvious conclusions to be drawn from the general discussion of DCE authentication is that application-level client and server authentication responsibilities are highly asymmetrical:
· Clients typically inherit identities, while servers assume them implicitly.
· Clients are concerned with credentials while servers are concerned with keys.
The reasons for these asymmetries have to do both with the underlying asymmetry of the Kerberos model and with an underlying model of RPC client and server behavior that is also asymmetrical.
From the Kerberos point of view, the basic model is that a client acquires and holds tickets (credentials), valid for some period of time. These function as temporary proxies for the client's secret. The server, on the other hand, makes use of no such proxy: it needs constant access to its secrets in order to decrypt new client requests and discover the applicable conversation keys.
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.
Note: 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 does not 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 Authentication Model.
For the server, the basic authentication problem imposed by the DCE secret key authentication protocol is the maintenance of keys. This depends on local operating system access control to the key storage (typically a so-called keytab file) for the DCE principal identity used by the server. However, since servers normally also need to acquire credentials (in order to behave as clients of other services), application programmers need to think carefully about how the server identity is acquired. In general, it is not satisfactory to have servers run with credentials inherited from human logins. For one thing, this requires the server to share keys with human users. This means that the server either needs to have access to the default key storage used by human principals (typically the default keytab file, probably owned by root) or it needs to keep separate copies of user keys in local storage. Both of these schemes decrease the security of keys, and the latter makes key management difficult.
A straightforward scheme that meets these requirements is to have the server identity supplied by the invoker (or a configuration file) and have the server assume this identity via a series of security service calls. The only administrative overhead is in establishing at least one principal and the required keytab file. This is typically handled through dced facilities.