Architecture of tnc@fhh 0.4.x

This article describes the architecture of tnc@fhh 0.4.x. Therefore, the components which are used are listed and described, as well as the sequence of an EAP-TNC-authentication. For a more basic overview of TNC, see Trusted Computing and Trusted Network Connect in a Nutshell. For concrete contents of the mentioned configuration files and/or for detailed installation instructions, see the HowTos in the wiki.

Overview

tnc@fhh in its actual version (TNCUtil v0.4.4, NAA-TNCS v0.4.4, FreeRADIUS EAP-TNC-patch v0.4.5) consists of several components. There are modules for external programs, dynamic libraries and configuration files, which the most of are in relation to some other components.

Components

• TNCUtil (libTNCUtil.a, header-files in /usr/local/include/TNCUtil/): TNCUtil delivers some utility functions that are use by other components. Furthermore, it includes a framework for developing IMC/IMV pairs.
• NAA-TNCS (libNAA-TNCS.so, header-file naatncs.h in /usr/local/include/): NAA-TNCS is the implementation of both the NAA and TNC-Server component as proposed by the TNC architecture. It is implemented as shared object that is plugged into a FreeRADIUS server.
• EAP-TNC-module: This plug-in mechanism is realised by extending FreeRADIUS with a new EAP-module called EAP-TNC. This module is responsible for exchanging EAP-TNC packets between FreeRADIUS and NAA-TNCS.
• IMVs & IMCs (libIMV/IMC[…].so): IMVs are the validating components who communicate with the IMCs on the clientside, and return a recommendation regarding to a IMV/IMC-pair-specific policy.
• FreeRADIUS: FreeRADIUS is a open-source Radius-server, which has EAP-functionality.
• wpa_supplicant: Currently, wpa_supplicant is used as NAR and TNCC cause it natively supports TNC and does not need any modification.

Configuration files

Additionally there are several configuration files for all of the components.

• /etc/tnc_config: defines the location of the shared objects of the installed IMVs.
• /etc/tnc/imv_[…].policy: the policy-file for a specific IMV
• /usr/local/etc/raddb/eap.conf: holds the configuration of the EAP-module, which includes EAP-TTLS and EAP-TNC.
• /usr/local/etc/raddb/dictionary.tnc: defines a new attribute TNC-Status, and three values (Access, Isolate, None)
• /usr/local/etc/raddb/dictionary: includes the TNC dictionary file
• /usr/local/etc/raddb/sites-enabled/default: configuration that is used after an successful authentication for mapping an TNC-Status (Access, Isolate, None) to a VLAN-ID

Operational sequence

1. Initiation of the modules

On the startup of FreeRADIUS, the EAP-module and the corresponding configuration file are loaded. In the course of loading the EAP-module, the EAP-TTLS and the EAP-TNC-modules are also loaded. The default-type for EAP is EAP-TTLS, as EAP-TNC has to be run inside of a secure tunnel. Therefore, EAP-TTLS is configured to use EAP-TNC as its inner method, and it is also configured to send the reply-attributes from the inner method to the NAS, as EAP-TNC holds the result of the authentication.

2. Initiation of the TNC-authentication

When the first EAP_IDENTITY_RESPONSE (with EAP-TNC as the EAP-type) was received by FreeRADIUS, the method tnc_initiate from the EAP-TNC-module is called, which initiates the EAP-TNC-session. In the beginning it checks if the packet is inside TTLS. Afterwards an connection ID is calculated and the connection is created. This is done by a method of NAA-TNCS, which is located in an shared object and provided via a header-file. The method first loads all installed IMVs which are listed in /etc/tnc_config and informs them that a new handshake has begun. tnc_initiate then builds the EAP-TNC-packet by setting all attributes in the request-structure of FreeRADIUS and settings the current stage to AUTHENTICATE. Finally, the first EAP_TNC_RESPONSE is send to the peer.

3. Ongoing TNC-authentication

When a EAP_TNC_RESPONSE (and the current stage is AUTHENTICATE) is received, the tnc_authenticate-method within the EAP-TNC-module is called. It basically forwards the EAP-TNC-data to the NAA-TNCS and forms an appropriate EAP_RESPONSE. Again, the NAA-TNCS-shared object is used to send the EAP-TNC-message to the TNC-Server where all the messages from the EAP-TNC packet are extracted (from TNCCS-Batch to TNCCS-messages and IMC/IMV-messages). The IMC/IMV messages are forwarded to the respective IMVs, which in turn can send a response or provide a recommendation to the TNCS. Regarding to the resulting connection state, the handshake is either still ongoing (when one or more IMCs/IMVs have to exchange more messages) or the handshake is finished. In the last case, the internal FreeRADIUS server-side-attribute TNC-Status is set. TNC-Status is defined in the dictionary-file dictionary.eaptnc and has the values “Access”, “Isolate” or “None”. Finally, an EAP-Response-Package is send back to the client/AR.

4. After an successful TNC-authentication

When the authentication was successful, FreeRADIUS uses the entries in the post-authentication-section of the default-policy. By using the unlang-language, the value of TNC-Status is read and VLAN-settings (Tunnel-Type, ID) are added to the reply, which is then send from FreeRADIUS to the PEP. Diagram of the components and their relations.

This picture shows all components that are used on the serverside of tnc@fhh.