One

When the requestor (subject) and resource (object) are in separate SC domains, several new options must be considered for the access control matrix. approach is to include all relevant subjects in the matrix that controls a particular object, which provides the object-oriented control that is felt to be needed. In effect, the object information is centralized at the SC responsible for that object, while the subject information is distributed; i.e., the access capabilities of a given user may be scattered across two or more SC's, such that each SC handles its own local users.

The alternative is to centralize the subject information, e.g., at the requestor's SC, and to distribute the access information for a given object. This latter approach has two major disadvantages: (1) the access checking is performed at the requestor-SC instead of the resource-SC so that the desired object-oriented protection is not provided, and, (2) any necessary global searches related to a given object are very time-consuming since the storage is subject-oriented at each SC. Therefore, the recommended approach is to include local and remote subjects in the access control matrix of the SC that protects a given object. The subject-profile that would be sent to the object-SC would include identification, clearance, and NTKC information, but would not include any new entries to the access control matrix.

If a given person is to be deleted from the list of subjects, that person would initially be deleted from his local SC, which would "break" his ability to access any of the network objects to which he previously had authorization. These remote SC's would be updated by an SC-to-SC message to purge the particular user from the access control matrix; a simple task since each SC has this information organized by subject. Either all possible SC's could be notified in this manner, or a table of relevant SC's could be kept as part of the user profile.

There are two major issues associated with how the access control tables should be updated: (1) whether it can be performed efficiently in an on-line mode, and (2) how to control the process. Each of these areas will be considered in the following paragraphs.

Assuming that the access information is

3.2.4.1 Feasibility of On-Line Update. handled as a set of linked lists, the update process involves searches, deletions, additions, and changes of blocks of information and pointers between these blocks. On-line update of this information appears feasible if a sufficiently dynamic storage management scheme is utilized, but the impact of such a scheme must be carefully considered in terms of its search speed and any complexity that it adds to the Security Controller (e.g., for proof of correctness considerations;

Updating becomes a matter of modifying the linked list representations of the (object, capability) pairs, which could be performed either on or off-line. By off-line updating, we mean a batch-processing method of regenerating the tables on a periodic basis, utilizing either the SC itself or some other machine for such processing. Conceivably, this processing could be running as a background task on the SC during its normal operation, but this would add complications well beyond the benefits. Usage of a redundant (stand-by) SC for such updates would be more feasible, but is not necessarily consistent with the optimal usage of such redundant equipment (see Section 3.7.2). Therefore, if off-line updating were chosen as the desired method, such updates should be performed on an auxiliary machine.

On-line updating would require additional SC programs and would require that storage be allocated dynamically or that sufficient reserve space be provided in advance for the updates. The linked list approach of Figure 3-2 might utilize a combination of these two schemes, with a pre-allocated profile block which could then be updated to include either direct authorizations, or pointers to (object-capability) lists such as access groups. In the initial mechanization, only the pre-allocated portion might be required, thereby

deferring the need to actually implement the dynamic portion. However, the basic design would include the ability to expand via the dynamic allocation scheme.

3.2.4.2 Controlling the On-Line Update Process. The minimal requirement for on-line update would be for a simple debug-like facility to allow changes to specified memory locations. However, changes to information within the SC must be made under very tightly controlled circumstances due to the potential consequences of erroneous profiles, etc.

One approach to providing this control is to only allow changes to be made from a single terminal (and perhaps by a single person) which can provide an arbitrarily high degree of physical and procedural protection. This centralized approach has a certain intuitive appeal, but is vulnerable to errors in the administrative pipeline that would feed change requests from the user community to the person responsible for making these changes, and also looses the "reasonableness checks" inherent in a distributed scheme in which updates would be made by persons involved in the activities.

The basic problem with distributed updates is the need for selective update controls. The selectivity aspects include the need to control that:

only the owner of an object can grant, modify, or remove
capabilities to that object.

these capabilities can only be granted to subjects that have
appropriate clearance and compartment requirements.

the only capabilities that can be changed are those related
to the owned object.

The needs can be met by the usage of a "trusted" routine that performs the updates on one's behalf after having made the necessary checks. A security officer would serve this role in the centralized approach, while a special SC update routine would be required in the distributed scheme. This update routine would itself be a subject, and in fact would be the owner of the access control matrix. As such, it could "bootstrap" the creation of the matrix from the initial triple, (update routine, access matrix, owner), to whatever current state the matrix may obtain. All requests for change would be via "messages" sent to the update routine, which would then check the authorization before actually making the changes.

3.3

THE SECURITY CONTROLLER MECHANISMS FOR ESTABLISHING A CONNECTION

If the requested access of a subject to an object is authorized, the SC must then create a working connection between these two parties. The notion of "creating a connection" involves several levels of protocol, and therefore is dependent upon the physical and logical organization of the network. However, we will assume that the following functions must be performed in any network, and will address the issues related to these aspects.

Control over the initial requestor-to-SC connection.

Determining the path for the control messages that are used

to create a working connection between the requestor and
the resource.

Handling exceptional conditions on a set-up attempt.

Crossing inter-network boundaries (gateways).

Initial control message contents, e.g., should requestor
profile information be sent?

3.3.1

Control Over the Initial Requestor-to-SC Connection

One of the requirements established in Section 2.2.1, was that the SC perform a Reference Monitor-like function, including the concern that it be always invoked. To ensure that this happens for each initial access request, one must force all such requests to be made via the SC, and can enforce this policy by taking advantage of the restrictive aspects of the cryptographic equipments, i.e., they will only pass meaningful information if the two ends have matching keys. Therefore, we can ensure that any requestor must initially contact the SC by setting the SC's initial crypto settings to some known condition (e.g., null), while the initial crypto settings of each resource would be known only by the SC.

The recommended requestor-to-SC "handshake" for their initial connection would be as follows. First, the requestor would "activate" a physical connection between itself and the SC, and would then send an identifying message of the form, "Hello, I'm device # xxx," to which the SC would respond by setting up a temporary set of working keys to protect any subsequent requestor-to-SC dialog. (If a quick test of device authenticity is desired, an echoed message can be utilized to ensure that both ends have matching cryptographic keys. This and other aspects will be considered in Section 4 which will discuss the cryptographic devices.)

3.3.2

Selection of the Path for Set-Up Control Messages

When the SC has determined that a requestor is valid and that the particular request is authorized, it must then set up a protected working connection between the requestor and the resource. The principal aspect of this is the insertion of the working keys into the cryptographic devices at the two ends, which would be performed by sending a special control message to each device.