OSF DCE Administration Guide--Core Components

OSF DCE Administration Guide—Core Components
30.6.1 DCE Version 1.1 Authentication
With the addition of user preauthentication, DCE Version 1.1 authentication addresses
certain security deficiencies in the Kerberos V5 authentication protocols, used as the
basis for the DCE authentication protocol in versions previous to DCE Version 1.1.
These deficiencies result from
• 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 Version 1.1 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
There are three 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 section) 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 following:
• The third-party protocol, which provides the highest level of security. No lesser level
of preauthentication should be specified for any principal unless there is a
compelling reason 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.
30 − 8 Tandem Computers Incorporated 124243