Authorization and access control are widely studied problems, and therefore will not be stressed here except to note the following design principles:

No requestor shall have any access privileges which

are not required to perform its function (need-to-know). As a corollary to this, access to resources shall be separated (compartmentalized) whenever such separation adds to security (reference Jones; JON-73).

2.

3.

Least Common Mechanism

There shall be minimal shared (common) mechanisms,
other than those that are expressly there for secu-
rity purposes (reference Popek; POP-74).

Reference Monitor Approach

Access control mechanisms must be such that they are:
(1) always invoked, (2) isolated from unauthorized
alteration, and (3) accredited as being trustworthy.
(Note: The Security Controller approach which we will
develop is analogous to the Reference Monitor, but
is only involved in the initial phase of the use of
a resource.) (Reference Anderson; AND-72.)

4. Object Versus Path Protection

Protection can be provided to either the object itself
and/or the path to the object. (Note: The network
aspects are almost entirely path-oriented protection).

2.2.2

Authorization Checking At Local And Remote Nodes

When a requested resource is in the same local domain as the requestor, the access authorization check can be made at that Security Controller by comparing the requestor's capabilities profile against the requirements profile of the resource. If the resource is not at the local domain, two additional operations are required: (1) discovering where the resource is, and (2) sending either the requestor's profile to the resource or vice-versa.

The first operation, finding the resource, can be resolved by any of the following methods:

Using tables in some predefined network
service facility.

In the short term, network users could be expected to know the physical location of the requested resources, but provisions should be made for an evolutionary trend towards more implicit schemes such as the directory approaches. However, such service functions should not be mixed with critical security functions in a manner that complicates the security mechanisms and makes certification more difficult.

In addition to discovering where a resource is located, we are also concerned with the choice of which profile should be sent to the other's Security Controller for checking. The alternatives are:

Send requestor's profile to the resource SC for checking.

· Send resource's profile to the requestor SC for checking.

Do both, i.e., checking at both SC's.

The first option has a certain intuitive appeal--you take the key to the lock, not vice-versa. The second has a disturbing aspect since the requestor node checks its own request instead of having the protection (checking) at the remote node, which is presumably responsible for the

resource.

Checking at both requestor and resource SC's introduces an additional level of checking, i.e., to see if both agreed that the request was authorized. This could be performed by sending both check-results to either SC (in which case the previous arguments apply again in a recursive manner), or by an implicit scheme in which each SC takes some separate action, which must match if the requested connection is to be usable. Since this added complexity has no apparent benefit, the scheme will not be considered further, and only the first method (checks at the resource SC) will be considered in subsequent sections.

Several entities are involved in almost every computer transaction, e.g., a person, a terminal, a HOST computer, and a process. Each of these entities must be authorized to either receive, process, or transport the information being handled. The logical intersection of these authorizations* will

*In some situations, the authorizations may be other than the logical intersection, e.g., the use of statistical programs as discussed in the following section.

establish the level of information which can be sent via this sequence of entities (WEI-69), but a further step-by-step authorization' check is also necessary to ensure that only the proper entity (or entities) are the ultimate recipients of the information, e.g., one entity may be authorized to process, but not to copy the information.

In some instances, a requestor will be connected to a HOST which will, in turn, need to access other resources on the requestor's behalf. This need can iteratively grow to the general N-th party authorization problem, which extends the previously discussed N-th party authentication problems. Authorization is a larger problem than authentication since the latter is strictly binary at each intermediate requestor. In contrast, the authorizations of each intermediate requestor may differ, as may the authorization needs when information is processed at the different nodes along the chain. Two different approaches are possible: (1) continually subsetting the authorizations as necessary so that the final privileges are the intersection of those of the original requestor and all intermediate nodes, thereby ensuring that no intermediate node gets any information for which it is not authorized (WEI-69), and (2) handling the authorizations iteratively on a pairwise basis, so that the N-th level will provide any requested information for which the N-1'st is authorized, and leave the burden of further controls on passing of data to that HOST. This approach allows the use of so-called "statistical programs" in which specific details are lost, e.g., "what is the average value of the class of xxx's," instead of "what is the value of a particular xxx" which might be sensitive. Of course, the latter may be the result of a cleverly devised statistical request, a well known problem that is also outside the scope of this network investigation. We consider the possibility of such programs since we want the network design to be such that it can accommodate new advances if and when they become available.