The

it can provide an implicit authentication of the terminal. (The reader might argue that such a device thereby becomes part of the terminal. issue is less clear when this authentication is provided by a cryptographic device, which will be the case in a later section of the report.)

We assume that environment-dependent entities such as a terminal which must be operated within a special room, are dependent upon physical and procedural controls to ensure that these restrictions are maintained. Alternate authentication-like mechanisms could be included (e.g., the terminal is in the room and the door is locked) by an extension to the notion of the attached authentication device as mentioned above.

If an entity is to serve a dual or multiple role, the two or more identification/authentication mechanisms required must be provided by some usagedependent feature such as a special key, coded card, etc. For all practical purposes, such an entity would be viewed by the network as being separate, but mutually exclusive, devices. Here again, physical and procedural control of terminal access would be required.

In all of the above instances, the authentication must be made initially, on an on-going basis, and at any system discontinuities. The forms of authentication are varied, and depend upon the entity and the particular needs of the system. Reference (FAR-72A) gives a summary of existing identification/authentication methods.

Networking also creates identification/authentication problems beyond those of a single computer system. In the multi-system (network) environment, the various systems (HOST computers) must also be identified and authenticated. One aspect of this issue is whether processes on the HOSTS should be considered as entities which require such identification/authentication, either as a requestor of network services and/or as a server.

Since the HOST

will have complete access to the data of its processes, including any

authenticators which they might have, the use of process level authenticators does not protect against malicious HOST behavior. However, it does provide

a degree of protection against accidental spillage (e.g., address error).

2.1.3

Distributed Versus Centralized Authentication Checking Authenticators may tend to become less effective (e.g., more easily stolen and forged) in a network environment since passwords, etc. are needed at multiple computer sites and therefore tend to be: (1) the same at all sites, (2) of longer duration between changes due to the logistics problems in changing them, and (3) vulnerable to compromise at any one of the multiple sites (the "weakest link in the chain" effect). These problems are caused by the inherent weaknesses in distributed authentication checking where the authentication (e.g., passwords) can be forged if known. The solution requires either centralized checking or non-forgeable mechanisms.

The use of a centralized authentication checker (part of the "Security
Controller" which we will define later) is in reality a hybrid scheme,
with checking being distributed to the level of a given region or domain,
but being centralized within each domain. Local checking is needed for
logistics reasons, at both the user (requestor) and server (resource).
However, this does not imply that only the centralized check would be made;
distributed authentication checks could also be made, either as a two step
check for particularly sensitive resources, or as part of an evolutionary
approach to developing a secure network from a set of independent sites.

Such checking could also be by means of a duplicated facility in order to provide a secondary or back-up capability such that a failure in the primary checking mechanism does not result in a loss of network access. logistics problems of managing a duplicated data base of users, passwords,

However, the

etc. must be carefully considered. Some indication should also be made that network access is being made via the secondary source of authorization approval.

An additional aspect of authentication important in the network environment is N-th party authentication, e.g., when one site must operate on behalf of another, which itself is operating on behalf of yet another, but in all cases for some "ancestoral" user who initiated the request.

Two basic issues arise from this problem: (1) the extent to which the original requestor should be involved, and (2) the amount of information that should be carried along with the N-th party request. first issue, the original requestor might:

Explicitly specify the N parties involved

Addressing the

Specify that some level of N-th party access is probably

required, but with the parties left undefined.

Not be aware of the need.

The first option is not generally realistic, and would typically apply only for certain single level indirect accesses. The second and third options are more likely, and require several aspects of protection including:

1.

A method to notify a user that accesses are being
made (or attempted) on his behalf. Even if accesses
are transparent to the user, the fact that they are
being performed may need to be made available, at
least as an option.

2.

A mechanism to ensure that the user can control accesses on his behalf, e.g., a one-time password, (given to the user by the SC), that the HOST would have to get (from the user) before being able to make an access on his behalf.

3.

The same protection as in (2), but applied at each

step of an N-th party scheme. (Should the user be
involved in each step, or only at the first?)

4.

Determination of the default conditions for N-th party

accesses; i.e., whether allowed or precluded.

5. Some maximum number of levels for the N-th party
accesses, e.g., N no greater than two or three.

The second basic aspect of N-th party authentication is how much information must be carried along at each stage of the chained requests. At a minimum, each stage must know the previous stage. The only other alternative which seems to have merit is that of carrying along information on all previous stages, i.e., a "trail" to the N-parties and their sequence. The advantages of this scheme are:

To simplify audit data interpretation

To provide an explicit "return path" for results

To detect and avoid loops, (e.g., A calls B, who calls
C, who calls A, etc.)

The "trail" alternative has the disadvantages of extra overhead and the open-ended length of the related data structure and storage requirements. Other aspects of the N-th party problem will be considered under authorization issues in section 2.2.4.

Identification and authentication typically precede the request for access to some network resource, since knowledge of the requestor is necessary to determine if the requested access is authorized. The information which defines the rights of requestors to access various protected objects (HOST computers, files, etc.) is basically the information indicated in a

Lampson/Denning (LAM-69) three-dimensional authorization matrix as in

Figure 2-1, although actual mechanizations vary considerably from system to system. For our purposes, we will assume that every requestor has a capability profile (e.g., a "C-List") which consists of essentially the list of objects to which he has access, and the relevant privileges on those objects. Similarly, an object might have an access requirements profile (e.g., the list of requestors who have access to it and their privileges), so that an access request is authorized when the requestor's and object's profiles match.

The access profile information can be considered part of a more global security profile, which would also contain identifiers, etc. The term "profile" is used quite loosely in the literature, so we will not give it a rigid definition in this report. However, we will define profile-related information at various steps to discuss its possible form, content, size, error control, etc. as these relate to other issues.

Since the issues of access authorization can often be considered as extensions of those of authentication, we must consider many of the same general topics such as composite entities, N-th party situations, etc. These issues will be explored in the following sequence.

1. Access authorization design principles