3.6 TNCCS

The module TNCCS contains the logic to control an integrity attestation. The module can be used to implement either a TNCC or TNCS. Therefore, the module is structured as depicted in Fig. 6. The Client Facade provides an interface for a surrounding application to interact with a TNCC or TNCS. To execute an integrity attestation, the surrounding application has to create a connection, using the module TRANSPORT, first. Than the application must submit the connection to the Client Facade to embed the connection into a Session. After its creation, this Session uses the Connection and the module TRANSPORT for the transmission of messages as well as the module MESSAGE to encode and decode such messages.

A State Machine with various States is used inside a Session to control an integrity attestation. Therefor, every State implements a unique step of the integrity attestation process and controls whether messages have to be received or need to be transmitted for this step to be executed successfully. Messages, which have been received in a receiving State, are passed to the Handlers that are registered at the State Machine. An IF-TNCCS Message Handler can process messages that are addressed to a TNCC or TNCS. If necessary the handler may also create messages for transmission. Because a message to a TNCC or TNCS may contain the result of an integrity attestation, which is usually important for the surrounding application, the handler is able to extract such information and forward it to the surrounding application. On the contrary, the purpose of a Message Error Handler is not to process messages but exceptions that may occur during the reception of messages (e.g. exceptions concerning the message format or a value of a message). This handler is able to create error messages as a response to an exception for transmission to the origin of the faulty message. The IF-M Message Handler is responsible for messages, which are addressed to an IMC or IMV. The State Machine forwards these messages to this handler, while the handler forwards them to the IMC or IMV, which are known to it. Therefor, it is using Adapters. An Adapter controls an IMC or IMV and negotiates the methods, which are supported by an IMC or IMV (cf. section 3.1 and section 3.2) to forward messages. The Adapter may also be used to control the run-time an IMC or IMV is granted to process a message after it was forwarded by the handler. The available IMC and IMV, with their Adapters, are retrieved by the IF-M Message Handler at the beginning of an integrity attestation from the IMC/V Manager.

The IMC/V Manager is used by the Configuration Manager to initialize an IMC or IMV after it was loaded and to make it available for an integrity attestation. Therefor, the Configuration Manager is monitoring a configuration file (tnc_config s. [3, pp. 75-77] and [4, pp. 85-87]) that is specified by the TNC-WG to contain all IMC or IMV, which should be available for an integrity attestation. If a new IMC or IMV entry is added to the configuration file, the Configuration Manager will load the newly added IMC or IMV and request the IMC/V Manager to initialize the newly loaded IMC or IMV. On the other hand, if an existing IMC or IMV entry is removed, the Configuration Manager requests the IMC/V Manager to terminate the corresponding IMC or IMV. For this to work, an IMC or IMV has to support the methods, which are defined by the TNC-WG and are contained in the modules IF-IMC API and IF-IMV API.