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.
The following figure 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 topics 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.
2. Principal A now makes a request to Principal B to perform some operation that requires the c permission to object d, and presents its certified privilege attributes. Principal B may grant or deny c access to d after examining the ACL that protects object d. (An ACL associates the privilege attributes of principals with permissions to an object.) If c is one of the permissions listed in the ACL granted to Principal A, then Principal A is allowed to perform the operation; if the c permission is not granted, A is denied access.
Shared-Secret Authentication and DCE Authorization in Brief
Had the authentication service been unable to decrypt the principal's authentication request, the principal would have been unauthenticated and, as a consequence, unable to acquire certified privilege attributes from the privilege service. In that case, Principal A might have simply asserted its privilege attributes to B; that is, claimed them for itself, without the benefit of having the privilege service certify this data as being genuine. Had Principal A then presented asserted privilege attributes to Principal B, then B might have denied the requested permission or granted it, depending on whether B grants permissions to unauthenticated principals, and whether c is among the permissions that B grants to such principals.
If Principals A and B are especially sensitive to security concerns, they may request that transmitted data be checked for integrity to establish whether it has been modified in transit, and possibly also encrypted to ensure that the data is unintelligible to any party other than Principals A and B.