OSF DCE Application Development Guide--Core Components

DCE Security Service
23.3.1 Authentication Service Surrogates
A principal trusts another principal in its cell because it trusts the Authentication
Service to authenticate all principals that are members of the cell, except for the
Authentication Service itself, which its member principals trust a priori. The
Authentication Service can authenticate all principals in its cell because it shares a
secret key with each of them. A principal that wants to talk to a foreign principal (that
is, a principal in another cell) must acquire a ticket to that principal. Furthermore, the
ticket must be encrypted in the secret key of the foreign principal, or else the foreign
principal may disregard the initiator of the conversation. The local principal cannot get
such a ticket from its own Authentication Service because the local Authentication
Service does not know the secret keys of any foreign principals. Therefore, there must
be some other means by which the two instances of the Authentication Service can
securely convey information about their respective principals to one another.
Besides the fact that it is trusted a priori, a cell’s Authentication Service is an
exceptional principal in this other respect: other kinds of principals share their secret
keys with the local Authentication Service, whereas the Authentication Service’s key
is private; that is, known to no other principal. Thus, one problem of intercell
authentication is the means by which the Authentication Service in one cell may
communicate securely with that in another cell without either of them having to share
their private keys, which would introduce an unacceptable security risk.
Note: The Kerberos network authentication specification makes a distinction
between the terms ‘‘secret’’ and ‘‘private.’’ The term ‘‘secret’’ refers to
data that is known to two principals, and the term ‘‘private’’ refers to
data that is known to only one principal. We make the same distinction
in this guide.
The solution to this problem is an extension of the Shared-Secret Authentication
model previously discussed in this chapter; that is, an entry in the Registry database of
one cell specifies the same secret key as that in an entry in the other cell’s Registry
database. The two Registry 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 two instances of the Authentication
Service are enabled to convey information about their respective principals to one
another, thus enabling a principal from one cell to acquire a ticket to a principal in
another cell.
An authentication surrogate is a principal in the sense that it is represented by an entry
in a Registry database, but it is not an autonomous participant in authenticated
communications in the same sense that, for example, a user or a server is. Rather, it is
more like an alias that is assumed by a cell’s Authentication Service when it
communicates with a trust peer. The establishment of a trust peer relationship between
two cells is an implicit expression of mutual trust in the two Authentication Services
on the part of the cell administrators who establish the relationship; administrators use
the rgy_edit tool to establish the relationship.
23−26 Tandem Computers Incorporated 124245