for different semantic and syntactic interpretations. A better approach from the point of view of keeping the design clean and straightforward is to break these two needs into separate messages, i.e., having the resource contact the SC to obtain the profile information when it learns of the need for this data. The disadvantage of this scheme is the need for an additional connection to the SC (i.e., by the resource), but this should result in minimal delay since all operations would be computer-generated.

3.3.6 Control Over Play-Back of Connection Creation Messages Protection must be added to preclude the unauthorized establishment of a connection via play-back of a recorded (legitimate) connection creation message. This requires that some aspect of the connection creation sequence be different for each connection, such that a previous message would not be valid for subsequent usage. Either the initialization or the message content. could be modified, e.g., using a different initial encipherment or a connection sequence number respectively.

A variation of this same threat would be to attempt to deny service on a legitimate connection by playing back a connection creation message to one end of an existing connection. This threat should be precluded in the design by only accepting such connection creation messages when the mechanism is in an initiate mode of operation.

There may be circumstances in which certain terminals require that predefined working connections be created implicitly by an "off-hook" operation at the terminal. This operation would give the effect of a dedicated line between. the two entities, and as such would not be subject to SC approval or disapproval. However, the crypto keying might be by means of the normal SC-initiated key distribution (with an implicit authorization), and the SC could thereby

maintain audit information on the usage of the connection.

If two or more recipients are to receive a given message, either a single broadcast message can be sent to be received by all such sites, or the message can be repeated for each recipient. This choice must depend on the message protocols and communications media involved. The addition of network security mechanisms such as the SC and ICD's introduces a new constraint on such messages, namely all recipients must be approved by the SC and all of the appropriate ICD's must be keyed for the receipt of such messages. If broadcast messages are feasible and desired in a given net, the SC must be extended to handle the functions of multiple destination authorization and keying.

Network access for usage at an unclassified level could be possible if a given HOST machine allowed mixed operations of classified and unclassified work, or if the network includes both types of HOST systems. The SC could be utilized to establish an unclassified connection by creating a null key for the dialog, or if such usage is particularly common, such keying might be allowed by a manual operation at the terminal/ICD. The set of classified HOST's and the set of unclassified HOST's could share a given communications net, but remain logically (and securely) separate by means of the crypto keying. Only if one or more HOST's appeared in both nets simultaneously would the two nets have any overlap of concern.

3.4

THE SC/HOST-LEVEL MECHANISMS FOR CONTROLLING CONNECTION USAGE

Once a working connection has been established by the SC, its usage is primarily under the control of the requestor/resource ends and their respective cryptographic devices. Protection is needed against several forms of misuse which will be discussed in the following paragraphs.

The HOST's can misuse a connection by multiplexing multi-user traffic over a connection established for a single user, and can also mis-label the sensitivity of information sent over the connection. These problems must remain as sole responsibilities of the HOST computers. However, the network can provide some added controls in the area of accidental misusage, since checks can be made on the validity of addressing and classification fields relative to the values initially set up.

Other forms of protection can also apply against the play-back of recorded cipher-text messages. If such messages are cryptographically self-synchronizing, they can appear as valid messages, but protection can be added by a combination of HOST and cryptographic level checks such as connection or message sequence numbers, time-stamps and check sums (to detect maliciously inserted bit

changes). The use of sequence numbers introduces a new level of synchronization which must be considered. Several forms of usage control are required for recovery from errors such as the loss of a message, a message arriving when not expected, and crash-generated problems in an operating system. These problems have some security side-effects (e.g., possible loss of cryptographic or message sequence synchronization), and thereby can have operational impacts.

When the usage of a connection is completed, the SC should be notified so it can "close-out" its audit record for that request. Questions arise as to which end of the connection should notify the SC, or should both, particularly if they reside in different SC domains. Other questions relate to whether the notification of completion requires the full identification/authentication prelude, and whether some special SC action is necessary to ensure that the cryptographic keying for the connection is reinitialized.

3.5

SC/HOST-LEVEL MECHANISMS FOR MONITORING

The SC will need to maintain certain status information for each requestor that is in some state of requestor-to-SC dialog, or that has an outstanding connection which the SC has created. This information is essentially all the SC knows about a particular request, and can become the basis for the SC's

audit record. Other information could also be included such as whether any erroneous password attempts were made (prior to stating it correctly), and whether any unauthorized requests were made.

Certain threshold conditions should cause an immediate abort and/or alarm for an abnormal requestor-to-SC dialog such as mis-stating a password three times in a row. Other monitoring tests require more of a historical perspective to determine if a penetration attempt has been made, and could best be performed in combination with other information that might be maintained in a Network Security Center which would be the focal point for the analysis of SC and HOST-gathered audit information. More detailed investigation is required to determine the viability of such a center (or set of centers), since there are open questions related to:

How to combine and correlate the audit information from
the various sources.

What network performance degradation occurs due to trans-
mitting the audit information.

What procedures should be followed to ensure the validity

of the audit data, e.g., whether HOST-to-Net Security Center
connections should be set up via the SC.

Where audit data interpretation should be performed, e.g. central or distributed checking.

What audit interpretation tools are required, and in

particular what new tools are needed due to the distributed
nature of the source of audit information.

The need for some integrated audit interpretation seems necessary due to the difficulties in interpretation of the otherwise fragmented audit trail which may involve two or more SC's, multiple HOST's, etc. However, we will leave

this as an open issue that requires additional attention in the detailed design phase of the network development.

The Network Security Center would also be a logical candidate to handle the coordination functions related to updating the SC mechanism (e.g., code changes), for recertification as required, for updating cryptographic device "private keys," etc.

The network security assurance functions fall into four major categories: (1) certification of the SC mechanisms, (2) handling of SC data such as profiles, (3) self-checking, and (4) the necessary physical and procedural controls. These areas include both initialization and on-going aspects, which must be considered in the design and operational usage of the mechanisms.

The principal impact of the certification requirement is on the system design, since any after-the-fact attempts to demonstrate system integrity would tend to be fruitless. The entire design process should be oriented towards the use of the best available methods of program development (e.g., structured programming and chief programmer team approaches) as well as ensuring that additional security needs are also met. For example, in most programming environments, a program is considered to be correct if it does what it was supposed to do. Due to the security implications of the SC, its programs must do that, and only that, as well as having well defined failure modes (e.g., fail-secure operation). Therefore, the need for certification causes the following design constraints. First, the selection of an implementation language must be based on the abilities of the language to support structured programming and proof of correctness techniques. This language should also serve as a convenient and expressive tool for design and documentation, since one aspect of accreditation