• 802.1x support
• TPM support
• VPN support
• XACML policy support
• IMV/IMC pairs for tNAC
• Integrating a TNC-Client into Turaya
• Policy Management
• Remediation
• System Management

802.1x is supported by the tNAC components to allow for port-based enforcements towards clients. This means, that the port a client device is connected to is closed until a successful TNC handshake is done. 

The components of a 802.1x architecture correspond to the overall tNAC components (Access Requestor, Policy Enforcement Point and Policy Decision Point) as follows:

- Supplicant = AR

- Authenticator = PEP (a 802.1x capable switch)

- Authentication Server = PDP (a server running FreeRADIUS, communicating via the RADIUS-protocol with the PEP)

The XACML specification provides an extensible schema for defining policies. This can be used to define the different policies for each IMC/IMV pair and the TNC server itself. It supports user-specific policies and therefore fine grained policies.

Architecture:

To add the possibility of XACML evaluation there must be additions to the TNC PDP and the IMVs, as well as a new component called the XACML PDP, which evaluates incoming requests against given policies.

• IMVs with support for XACML
  • After receiving all measurements from its corresponding IMC, the IMV has to encapsulate these measurements within a XACML request and send it to a known XACML PDP. After receiving a response, it has to parse the decision and pass it to the TNC server.
• TNC PDP with support for XACML
  • The TNC server has to encapsulate all IMV recommendations within a XACML request. This request is then checked by the XACML PDP against a TNC server policy, that defines what recommendation each IMV has to fulfill, to grant network access to the AR.
• XACML PDP
  • The XACML PDP is responsible for receiving incoming XACML requests, evaluate them against a appropriate policy (that holds policy entries for the specific user of the AR) and send the results back.

Flow of operations: 

1. With the use of the EAP-TTLS and EAP-MD5 module of FreeRADIUS, the username of the AR's user is determined via MD5 in a TLS secured tunnel.
2. The AR and PDP start the TNC handshake.
3. When the values from the IMC are received by the IMV, these values are combined in a XACML request, together with the username for this connection.
4. The request is then send to the XACML PDP.
5. The XACML PDP evaluates the request by using the configured polices. All values as well as the username have to fulfill the policy.
6. The XACML PDP then creates a XACML response, which can be a ''permit'' or ''deny''. Additional information like a ''isolate''-recommendation is encapsulated in so called ''obligations''.
7. The response is send back to the PDP, who generates the recommendation for this IMV. When the XACML evaluation fails, a local evaluation can be done.
8. When the TNC handshake ends, the TNC server evaluates all IMV recommendations, by also generating and sending a XACML request.
9. After the XACML PDP evaluated the request and send back the response, the TNC server can generate a recommendation for the whole connection and thus enforce it through the PEP.

To achieve the different goals of the tNAC project, three different IMC/IMV pairs were created. They were created using the imunit-library of tnc@fhh.

IMC/IMV pair for ClamAV antivirus software

This IMC/IMV pair checks attributes of the ClamAV antivirus software. It recognizes if the software is installed and running, and also checks the version of its main engine and signatures. The values are then compared to values in a policy. If the state of the ClamAV on the AR is not compliant to the policy, the IMV will give a Isolate-recommendation; this would allow the AR to update ClamAV and to remediate itself.

IMC/IMV pair for Attestation

This IMC/IMV pair provides the functionality to securely obtain the measurements of the TPM and to validate them on the side of the PDP. To do so, the value of the Platform Configuration Register is quoted with an AIK by the IMC and send to the IMV, which compares the PCR and AIK to known values within its policy.

Parts of this policy look like the following:

# PCR values of reference system

# pcrX=<20 byte SHA-1 hash as 40 characters ASCII string>

pcr0=a234567890123456789012345678901234567890

...

# Known AIKs, identified by fingerprint of X.509 AIK credential

aik=DC:30:E6:EA:F1:97:5D:90:E6:AE:D0:A3:C8:62:5C:61:93:9B:96:4B

...

One can also specify, if all PCR values shall be send at once, or every PCR value within a single Tspi_TPM_Quote, which allows to check which PCR has caused the authentication to fail.

IMC/IMV pair for platform identification

The second IMC/IMV pair that makes use of the TPM is used to identify a device. It uses a non-migratable key whose private part is bound to the platform of the TPM. With the public part of that key, a X.509 certificate is generated and stored within an arbitrary key infrastructure within the tNAC network. Inside the authentication phase, it is checked if the AR owns an appropriate and therefore known key.