OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
22.6 Authentication, Authorization, and Data Protection in
Brief
When one principal talks to another in a distributed computing environment, there is a
risk that communications between the two will provide a means for compromising the
security of one or the other. For example, a client may attack a server, or a server may
set a trap for clients. An attack is most likely to succeed if the malevolent principal can
convince its victim that it is something other than what it really is (an attacker), and/or
that it possesses authorization that it does not really have. A counterfeit identity and/or
authorization data grants an attacker access that it presumably would not otherwise have,
and so provides an opportunity for the attacker to do damage.
One way an attacker might obtain counterfeit credentials is to intercept network
transmissions between a client and a server, and then attempt to decipher (and perhaps
modify) the transmitted data. If the attacker is able to intercept and decipher a
principal’s authentication or authorization information, it can later use this data to
masquerade as an authentic principal with proper authorization.
DCE security protects against these kinds of attacks. It contains features that enable
principals to
• Detect whether data they receive has been modified in transit
• Be certain that an attacker will be unable to decipher any authentication and
authorization data it may succeed in intercepting
DCE security gives DCE principals confidence that the identity and authorization of
principals they communicate with are authentic.
Figure 22-1 is an extremely condensed and highly stylized representation of the
essentials of DCE security in terms of the DCE shared-secret authentication protocol and
the DCE authorization protocol. Unless we note otherwise, assume that discussions in
the security chapters of this guide refer to these two protocols, used in conjunction with
one another.
The following is a description of the events depicted in the illustration:
1. Principal A (which could be an attacker masquerading as Principal A) requests
authentication of its identity from the authentication service. This request is
encrypted using several keys, one of which is a key derived from the password
supplied by Principal A. A copy of Principal A’s key also exists in the registry
database, having been stored there when the principal’s account was created (or
when the password was changed). It is thus available to the authentication service.
The authentication service then obtains the registry’s copy of Principal A’s key and
uses it to decrypt Principal A’s authentication request. If the decryption succeeds,
the keys are the same; Principal A is therefore authenticated and the authentication
service replies with information that enables Principal A to ask the privilege
service to authenticate its privilege attributes. (Privilege attributes are data used in
making authorization decisions; they consist of the principal’s name and group
memberships.) If Principal A fails to get authenticated privilege attributes (also
referred to as credentials), it may simply assert its privilege attributes to Principal
B.
22 − 4 Tandem Computers Incorporated 124245