OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
set of ACL management APIs is provided to make these tasks easier, but the work
required remains nontrivial. The steps are covered in detail in Section 3.4 of this chapter.
3.3 Authentication Model
The DCE authentication model is currently based on the Kerberos shared secret key
protocol. In theory, the application-level interface to authentication is sufficiently
abstract that an alternative authentication protocol can be implemented. However, given
that none so far has been implemented, it would be difficult to define protocol-
independent authentication policies based on a realistic understanding of the behavior of
alternate authentication services or the as yet unspecified programmer’s interface to such
services. The policy recommendations of this section do, therefore, make the assumption
that Kerberos is the underlying authentication protocol. No guarantees can be given as
to their appropriateness if an alternative authentication protocol is implemented.
3.3.1 The DCE Authentication Model
The authentication mechanism is based on two fundamental constructs: principal
identities and secrets (keys). These are, in a sense, the fundamental data of
authentication. The basic authentication policy issues therefore have to do with how
applications manipulate this data: how they acquire their principal identities and how
they maintain the security of their secret keys. This section discusses these questions.
The following discussion assumes an understanding of the basic transactions of the
Kerberos protocol as implemented by DCE. That is, it assumes that you understand such
concepts as conversation keys, tickets, a trusted computing base, and the like, as
described in the AES/DC Security volume. It does not assume that you know anything
about the details of protocol encoding, encryption mechanisms, and so on.
At a very general level, authentication (Kerberos)-related activity takes place in three
stages:
1. Before any application can make use of the authentication service, some
administrative actions are required, mainly to establish the required principal
identities and related secret keys.
2. Some application-level actions are then required of the client and server
principals: fundamentally, the client must obtain validated credentials, and the
server must point the RPC runtime to the storage for its keys. Note that, strictly
speaking, the server need not itself obtain any credentials, as these are only used
by the client of the Kerberos exchange. However, since servers typically must also
act as clients (of the name service, for example), they will normally also need to
acquire credentials.
In the case of the client, the application-level actions required to obtain credentials
are normally carried out by a login program before the client is run, and the client
inherits valid credentials. Therefore, this stage of activity is not usually carried out
3− 4 Tandem Computers Incorporated 124246