A principal trusts the DCE Security Service (registry service/KDS/privilege service) to authenticate other principals in its cell because it trusts the cryptographic algorithms and protocols, and the security of the code and data of the security service itself (which is trusted because it is part of the DCE network trusted computing base). The DCE Security Service can authenticate all principals in its cell because it shares a secret key with each of them. A client principal that wants to talk to a foreign server principal (that is, a principal in another cell) must acquire a ticket targeted to that server. As always, such a ticket must be encrypted in the secret key of the foreign server, else the server will not trust the ticket. The client cannot get such a ticket from its own local security service, because only the foreign security service, not local security service, knows the secret key of the foreign server. Therefore, some means must be devised by which the two instances of the security service can securely convey information about their respective principals to one another (without actually divulging secret keys of principals to foreign security services, which would be a security risk).
Besides the fact that it is trusted a priori, a cell's KDS is an exceptional principal in this other respect: other kinds of principals share their secret keys with the local security service, whereas the KDS's key is private to the KDS; that is, it is known to no other principal. Thus, one problem that intercell authentication must overcome is the means by which the KDS in one cell may trust that in another cell without either of them having to share their private keys (which would again introduce an unacceptable security risk).
Note: With respect to cryptographic keys, the term secret refers to keys that are (securely) shared between a bounded set of two (or more) principals, while private refers to keys that are known to only a single principal, and public to keys that are known to an unbounded set of principals (potentially to all principals). The cryptographic algorithms and protocols that are currently supported by DCE all depend on secret key technology' (typified by DES), even though a small number of private keys (those of KDSs) are used. There is an entire theory of "public key technology'' that is not currently supported by DCE.
The solution to this problem is a small extension of the shared-secret authentication model previously discussed in this topic. Namely, a new principal is invented specifically for cross-cell authentication, and two entries for this principal are made, one each in the registry service databases of the two mutually authenticating cells. The two entries have the same secret key. These two special registry service database entries are known as mutual authentication surrogates, and the two cells that maintain mutual authentication surrogates are called trust peers. It is through their surrogates that the two instances of the KDS can convey information about their respective principals to one another (though the two KDSs never communicate directly with one another, nor do the surrogates), thus enabling a client principal from one cell to acquire a ticket to a server principal in another cell.
An authentication surrogate is a true principal in the sense that it is represented by an entry in a registry service database, but it is not an autonomous participant in authenticated communications in the same sense that, for example, a client or a server is. Rather, it is more like an alias that is assumed by a cell's KDS when it communicates with foreign clients. The establishment, via surrogates, of a trust peer relationship between two cells is an explicit expression of mutual trust in the two KDSs on the part of the cell administrators who establish the relationship. Administrators use the rgy_edit tool to create surrogates and establish the trust relationship. Administrators who do not trust one another's cells must not establish such a relationship.