scheme is only somewhat better, being basically the same as that utilized by many networks today in which a given requestor's password is known by all appropriate sites.

Use of pair-wise unique codes avoids the problem of the first two schemes, and is a viable approach for a relatively small number of entities, as would be expected in the case of the SC's. The fourth approach would apply the Security Controller notion recursively to create another level of control, a super-SC, that would control SC-to-SC connections. This scheme was suggested by Branstad (ibid) as a possible solution, and although it appears to be feasible, it seems to be an added complication that is not warranted by sufficient added security, and it also introduces a centralized mechanism which must be extremely reliable, since if it is down, it would cause a loss of all inter-domain network usage. Therefore, we have not pursued this hierarchical approach, but have instead assumed that SC-to-SC controls would be handled by the SC's themselves, with the pair-wise unique codes or keys being the most viable and secure solution of these four possibilities. Knowledge of either passwords and/or cryptographic keying parameters can be utilized for this purpose.

3.1.5 The SC Role in N-th Party Authentication

The general aspects of N-th party authentication were discussed in Section 2 and four requirements were derived which will be expanded here in terms of what the SC can do to help mediate this situation. These four requirements

were:

A method is needed to notify a user of attempted access on his
behalf: The SC could be designed such that it would notify
the original requestor of such N-th party accesses, although
other constraints may not make this feasible to carry out. For
example, a user's terminal may have a single "port" which is
busy (i.e., tied to a HOST), or may not be able to receive calls
(initiate only). Similarly, the process may be a deferred batch
job in which case the user may not be on the system at the time.

Therefore, the only generally applicable solution seems to be to notify the requestor after the fact, e.g., as part of the audit information and printed with the eventual output to the user. Note: a subverted HOST could delete the print-out record, but could not nullify the SC's audit log.

• A mechanism to ensure that the user can control access on his behalf: Depending on the default condition chosen, the user controls would be either (a) allowed unless explicitly precluded, or (b) precluded unless explicitly allowed (or some combination).

The same as the second requirement, but applied at each step:
The same basic notions apply, although the number of possible.
combinations increases, e.g., usage of a set of one-time passwords
or the same one repeatedly, the possibility of involving two or
more SC's (if the N-th party servers are in different domains),
etc.

Some maximum number of levels of N-th party access: This choice would be very dependent upon other decisions, e.g., whether the SC was to set up and retain N one-time passwords for the subsequent N-th party accesses. (The approach is analogous to the manner in which some computers limit the number of levels of indirect addressing.)

The general problem of N-th party authentication is complicated by the combinatorics of the situation, and requires additional research to establish a proper conceptual framework from which adequate controls can be developed. However, there does not appear to be any conflict between the Security Controller approach and the known N-th party requirements.

After the SC has identified and authenticated a requestor, it must determine if the requested access to resources is authorized. This check is basically a table look-up operation, and therefore raises the interrelated concerns of: (1) what information should be in the table, (2) how the table should be organized, (3) how the table should be utilized, and (4) how table updates should be made. We will consider each of these areas in the following paragraphs.

Access authorization can be viewed as a three-dimensional access matrix of a set of subjects having access to a set of objects, and having a set of capabilities on those objects as described in Section 2. Complications begin to surface when one considers the actual meanings of these three axes. For example, a subject may be a person, or the composite of a person and a terminal, or perhaps of the person, terminal, and process (es) operating on his behalf. Other subjects may have no specific person involved (i.e., a process which performs a function but does not do so on behalf of a specific person). some processes may operate with higher capabilities than the person on whose behalf they are operating (e.g., statistical programs that produce "open" results from sensitive data). These factors present complications and issues which must be addressed.

Also,

Let us first consider the subject axis of the matrix. Certainly persons must be included as entries since persons are the "ultimate consumers" of sensitive information, and are the only accountable entities in the network (at least the only ones that are punishable). Since the composite of a user and a terminal may have some lesser capabilities than that of the user (or conceptually some greater capabilities), then we must decide how this composite capability will be handled. Clearly, we do not want to consider each user terminal combination as a subject; the list would rapidly become too long. What we really want is the composite capability, which can be obtained by a

combination of table look up processing. Therefore, the list of subjects should include: persons, terminals, and processes; and the composite capability of any combination of these subjects can then be computed based on the appropriate circumstances. Note that this structure will allow userless or terminal-less processes, userless terminals, etc., leaving to the table entries and computing algorithms the matter of enforcing a given access control policy.

The object axis will include any or all of the subjects, as well as HOST computers, files, etc., depending on the level of access control expected of the SC. Initially, only HOST-level access would probably be controlled by the SC (although access to certain files might also be handled) but the mechanisms should be sufficiently general to allow later extensions to other objects.

For each subject-object pair, a set of capabilities (possibly null) defines the privileges which that subject has to that object. Like the subjects and objects, each capability must have a unique global name, i.e., WRITE must have the same meaning for any subject - object pair. (Note: This requires that each network HOST computer be able to map these globally defined terms into its own access control interpretations if the SC is to be able to authorize accesses on a conditional basis such as "can append to a file, but not modify.")

3.2.2 Organization of the Table

The three-dimensional matrix is a conceptual model of the access control structure, in which the access privileges of a subject to an object are defined in the vector associated with that (subject-object) pair. The composite of all such capability vectors for a given user results in a plane of objects and capabilities, just as a particular object has an associated plane of subjects and capabilities.

While this three-dimensional structure is a useful conceptual model, it is not suitable for any kind of direct implementation. Even though one could map this structure into the single-dimension address space of a computer, the matrix is typically very sparse, and only the non-zero triples of user

object, capabilities need be stored. Secondly, a reasonable amount of factoring is possible such as by listing the object-capability pairs for each user, or conversely, listing the subject-capability pairs for each object.

Other forms of compacting are possible such as identifying common access groups, where an access group is defined to have a specified set of object-capability pairs. Any subject having all of these pairs is considered to be a member of the group, and that subject's profile need only list these groups (by assigned group names), thereby reducing the amount of information that must be stored, at the cost of some additional processing time.

One standard scheme of grouping is by need-to-know categories (NTKC's). It is an implementation of the principle of least privilege that applies particularly well to manual/paper and pencil security environments in which persons can access (read) and perhaps generate sensitive information if they are authorized, i.e., a member of the NTKC. The concept of NTKC's becomes more complex in a computer environment in which many different privileges (capabilities) may exist, the files of the NTKC may reside at different HOST computers, etc. However, a sufficient generality can be obtained by considering object names to be of the form: <object name> = <NTKC>•<file>, in which various fields can be null, i.e., implied factoring of all such entities. Therefore, an object can be a NTKC, a HOST computer, a file within a given HOST, etc. Various controls and constraints can be implicit in the access control table information, such as the need for a person to be in two particular NTKC's before having access to a resource, or conversely having access only if the person is in one, but not both, of the NTKC's. Access groups which contain implicit information of this form must be carefully considered in the design of the routines which are to be utilized for updating the access control tables (to be considered in section 3.2.4). The security classification levels of Top Secret, Secret, and Confidential can also be easily handled by implicit considerations in creating the table entries. If an object requires a TS clearance level for access, only those persons can have this object included in their access lists. This implicit approach has one major side-effect, namely that subjects other than persons (e.g.,