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 topic 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 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 Authorization.
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.