DCE Authentication

· The security server responding to client login requests without verifying that the user knows the password

· The use of user passwords, which are notoriously weak, to encrypt plaintext data that is then sent across the network

These practices are subject to attacks in which the attacker obtains network transmissions and proceeds to attack them offline to elicit user's passwords. These kinds of attacks, if successful, can compromise the security of a DCE cell (and of all other cells in a trust relationship with that cell.)

DCE authentication reduces the likelihood of such attacks succeeding by providing for

· Preauthentication of principals making login requests (that is, by having the DCE Security Service verify the identity of the requestor before responding to the request)

· The use of strong keys to encrypt all network transmissions involving validation between security clients and servers

Four levels of authentication, ranging from most to least secure, and representing decreasingly strict preauthentication protocols. By attaching an instance of the pre_auth_req ERA (described in the following topic) to the principal, administrators can control the minimum level of preauthentication that the security server will accept when authenticating the principal.

The preauthentication protocols are:

· The public key protocol, which provides the highest level of security. A principal that does not have this level of security at login may not be able to use certain applications that do use public key authentication.

By default, public key login is disable. To enable public key authentication, see the next topic.

· The third-party protocol, which provides a high level of security. No lesser level of preauthentication should be specified for any principal unless a reason is compelling enough to do so. (See the comment on cell_admin in the next bullet.) DCE Version 1.1 clients always construct authentication requests with this protocol, except in cases where they are unable to do so because the machine session key, which is required to construct third-party requests, is unavailable (for example, at cell startup, or when the secval process is down.)

· The timestamps protocol, which provides an intermediate level of security. Timestamps preauthentication should be specified only for principals (such as cell administrators and noninteractive principals) who must be able to operate when the client is unable to construct a third-party authentication request as previously described.

In these cases, the client constructs and forwards a timestamps login request.

In particular, the cell administrator must have timestamps login capability, since cell_admin must be able to log in to set up the initial machine key during initial configuration of the cell.

· The DCE Version 1.0 (Kerberos V5) protocol, which is used to authenticate pre-DCE Version 1.1 clients only, and provides no preauthentication security.

More:

Enabling the Public Key Authentication Protocol

Managing User Authentication

Public Key Interoperability Between DCE Versions