OSF DCE Application Development Guide--Introduction and Style Guide

Security
explicitly by clients. In the case of the server, these activities are usually carried
out by the server explicitly. The reasons for this difference are one of the topics
covered in the discussion that follows.
3. Authentication related RPC protocol activity is then carried out transparently by
the RPC runtime during each call.
In addition, server application code needs to make authorization decisions based on the
assumption that authentication has been carried out, but these belong more properly to
the realm of authorization, as described in Section 3.4.
Note that the application code proper need only concern itself with item 2 in the above
list. This item is therefore the appropriate realm for policy recommendations about
application-level authentication. Item 1 is an administrative task required for the
installation and maintainance of the application. Nevertheless, the required
administrative actions depend on how the application treats authentication and are,
therefore, indirectly a policy concern for the application programmer. What this policy
guide recommends is essentially a standard application security model that results in a
standard administrative task. Note that, once the administrative and application setup
covered by items 1 and 2 have been performed, item 3 is handled transparently by the
RPC runtime.
3.3.2 Application-Level Authentication
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.
124246 Tandem Computers Incorporated 3−5