for the particular dialog. The null key would only be utilized for sending a clear "HELLO/id" message that identifies the requesting ICD, and only as a result of the "request for connection" signal being applied (a manual button depression in this figure). The private key would only be utilized for distributing working keys (i.e., to decipher a working key as received from the Master-ICD at the SC). This distribution would be via embedded control commands detected by the "Control Detector" box, and therefore shunted to the working key register instead of being passed on to the data processing equipment as clear text information.

Other needs in the ICD will become apparent as we proceed, but this simple model is adequate for our initial discussions.

4.1

THE ICD IDENTIFICATION/AUTHENTICATION MECHANISMS

As mentioned in the introduction, the canned "HELLO/id" message would include identification information, e.g., "HELLO, THIS IS #412." Since this message

1

However,

would be sent in the clear, it could easily be read and/or forged. this does not really matter since it is merely an identifier, and does not authenticate the ICD in any way. Instead, the Master ICD at the SC would then look up the unique private key of this particular ICD, and utilize it to send a temporary working key to the requesting ICD. The fact that the two ends can subsequently communicate in the temporary working key is implicit authentication, since only these two entities would know the private key.

2

2

The design must preclude the threat in which a forged hello/id message is sent to the SC such that the SC will re-key an ICD that is in use, thereby destroying an authorized connection. A special initialization mode should be adequate protection.

Katzan (KAT-73) summarized a similar security handshake scheme that he attributes to Feistel, Notz, and Smith of IBM.

A special test message "handshake" might be utilized as a quick test that such communication exists. (Note that the test message must be more than a simple "echo-back" since that would work in any case. Any deterministic response is adequate.)

Authentication of the ICD is important for several reasons, including (1) the assurance that it provides that one end is not spoofing the other, and (2) the implicit authentication that it provides to its attached data processing equipment (as long as appropriate physical and procedural controls are maintained). It might also provide a mechanism by which a given device could have two or more roles, e.g., could operate at either Secret or Top Secret levels at different times during the day. This would require that either two or more identifiers and private keys be "wired in" to the ICD or that the effective id/private key be the composite of that of the ICD and values provided by the data processing equipment. Either case would require an extension to our simple model of Figure 4-2.

One could extend the composite id/private key notion to include the person utilizing the data processing equipment, but there does not appear to be any advantage to such an arrangement.

Therefore,

The strength of the protection provided by the ICD's is completely dependent upon the secrecy of the private keys, but since they are only to be utilized for enciphering working keys, there is limited vulnerability to their repeated usage. (The working keys are essentially random numbers.) their replacement at selected intervals would be primarily to limit the duration of exposure if a key were compromised. Update would be via some non-network means such as manual distribution and insertion.

4.2

THE ICD ACCESS REQUEST/AUTHORIZATION MECHANISMS

The primary authorization function of the ICD is its role in effectively blocking communication between two entities until that communication has been authorized and established by the SC. As such, it serves an enforcement role that requires all requestors to go through the SC, thereby ensuring that it is always invoked.

A second area which can be controlled by the ICD is that of handling devices that dynamically change their security level. This control is an extension of the idea of providing an ICD with a set of two or more identifiers and authenticators, such that the device can serve a multiple role. For example, a HOST computer could operate at the Secret level most of the day with its ICD having one identifier/authenticator pair, but could change to Top Secret for a period of time, during which its identifier/authenticator pair would be modified by either selecting a second set of values or by forming a composite with HOST-provided data.

There is also an inherent authorization issue involved in the master/slave control structure of the ICD's, with the SC having the Master-ICD and the various requestor/resource entities having slave devices. This distinction is, of course, due to the special needs of the SC, and the desire to clearly separate the issues related to ICD's from those at the user/HOST level. The Master-ICD would be the only device that would "know" the private keys of the ICD's in that particular SC domain, as well as the pair-wise keys for setting up SC-to-SC communications.

4.3

ACCESS CONTROL AT THE ICD LEVEL; ESTABLISHMENT OF CONNECTIONS

As mentioned earlier, the control over the creation of connections is basically by means of the controlled establishment of working keys by the SC. It can enforce this control since only the ICD of the SC is (1) initialized to understand the clear HELLO/id message, and (2) able to establish working keys via the private key mechanism.

Since all communications between the SC and the other entities will be by. means of bit-serial (half-or full-duplex) paths, the control and data information must share the same channels, just as is typically the case for the various line disciplines which mix control and data in the same stream. We can therefore assume that the key distribution scheme must be based on the usage of embedded control commands, which must be recognized and acted upon at the appropriate time and place.

A connection is created when identical working keys have been inserted at the two end ICD's, and as discussed in Section 3.3, there are several options as to how this distribution might actually be handled. In one case, the SC/MasterICD would send the keys to the two ends by means of separate control messages, thereby "priming" the two ICD's so that they can communicate. The other alternatives were variations of a relay scheme in which the Master-ICD would send both copies of the working key to one ICD, which would then remove its copy (and related commands) and relay the rest on to the second ICD.

This approach to key distribution requires that an ICD not only be able to relay messages, but also be able to extract and execute control commands that are "addressed" to it. Several issues need to be considered in this regard,

including:

What control primitives should be provided for the ICD's.

How should the embedded control commands be addressed to the
appropriate ICD that is to act upon them (since a relayed
connection-creation message would involve at least three ICD's).
How can one ensure that the private key of the second ICD is
not "exposed" during the relay process (i.e., whether the relay-
ing ICD could gain any information regarding the other's private
key).

How should these primitives be formed into appropriate control
strings to set up the matching keys via the use of the private
keys.

Should commands be executed "on the fly" or only after error-
checking.

How should the Master-ICD be notified of the status of the
connection establishment.

How should connections be terminated (normal and error
conditions).

Each of these issues will be discussed in more detail in the following paragraphs.

The basic issues involved in selecting the ICD control primitives are that they (1) form a sufficient set to meet the known requirements, (2) are openended (i.e., capable of being extended as new requirements become known), and (3) are simple to understand and implement. Three variations of the control primitives were developed within these guidelines, and lead us to the conclusion that, at a minimum, two primitives were required; one to insert a new working key and the second to "skip over" a particular text string without scanning it for control commands (transparent text). A third primitive-like consideration was that of how and when the private key should be "commanded." In two of the designs, this was handled explicitly; either by a "Set Private Key" command or by a special flag in the "Insert New Key" command to indicate that the key is really to be the private key. In the other design, the private key was inserted automatically after having sent out the "HELLO/id" message, with the implicit understanding that the next message to be sent to it would be a working key (enciphered in the private key). (In multiplexed ICD's, these commands and "modes" should be considered on a per channel basis.) Other control primitives were added in certain cases as the designers considered a larger context of the networking environment (e.g., the need for message leaders and primary/ secondary keys for enciphering. the message text and leaders differently). We will discuss these auxiliary commands after considering some variations of the two basic commands.

4.3.1.1 Insertion of Working Keys. Our various test designs considered several ways that the new working key would be inserted; differing primarily in whether the insertion would be on input and/or output (e.g., of a Storeand-forward Relay message). One design allowed the choice to be made explicitly via a field in the command string. A second restricted key changes to output, and the third allowed changes only on input. Having all three allows maximum flexibility, but at the cost of having a much larger set of potentially valid sequences that might result in maliciously or accidentally induced security problems. For example, it would be possible for someone to play the role of the SC and spoof a requestor under the circumstances in which the "HELLO/id" message is sent in the clear and the SC is to respond by sending "Set Private Key" in the clear followed by "Insert Working Key"