The tNAC project aims to develop a trustworthy Network Access Control (NAC) solution. tNAC builds upon Turaya, the secure operating platform, and TNC@FHH, the open source Trusted Network Connect (TNC) implementation. By integrating the capabilities of Turaya, that are rooted in the Trusted Platform Module (TPM), and TNC@FHH, that gathers security relevant information about the endpoint, tNAC will ensure that only those endpoints that match the policy of the provider will be allowed to access the network. Endpoints that try to lie about their current security state will be detected.
tNAC composes of several components that are depicted in the following figure:
tNAC entities
Access Requestors (AR): These are endpoints that try to connect to a network that is protected by tNAC. ARs are running Turaya as operating system and special tNAC client software that is responsible for obtaining the necessary, security relevant data. Both mobile laptops and stationary desktop PCs can act as AR.
Policy Manager (PM): The network provider uses this component to define policies that are enforced by tNAC. In these policies, the network provider specifies the requirements that endpoints must fulfill in order to get access to the network.
Policy Decision Point (PDP): The PDP is the component that decides to what extent the requesting AR gets access to the network. It communicates with the tNAC client software on the AR to obtain security relevant data (the so called measurements). Based upon these measurements, the PDP decides if the AR fulfills the policy of the network owner and derives an access decision. The access decision can state that 1) access is allowed or 2) access is not allowed or 3) access is allowed but the AR is isolated in a special area of the network.
Policy Enforcement Points (PEP): PEPs are responsible to enforce the access decision that was made by the Policy Decision Point. There can be numerous PEPs in a tNAC environment. Two kinds of PEPs are edge switches and VPN gateways. After the PDP has derived the access decision, it informs the PEP that is responsible for the connecting Access Requestor about it.
Remediation Server (RS): tNAC supports Remediation. Remediation is a process that enables Access Requestors that are not compliant to one of the defined policies to change their configuration. The goal is that after these changes, the Access Requestor is compliant to one of the defined policies. The whole process takes place in a special, isolated area of the network. The Remediation Server is located in this area. It provides resources for the Access Requestor that can be used to obtain a policy compliant configuration (e.g. updates for the operating system, signatures for the anti virus software, etc.). tNAC detects this new configuration, evaluates it again based upon the defined policies and, in the best case, changes the access decision in order to allow access to the network.
The figure depicts two mobile laptops as Access Requestors (left hand side) and two stationary desktop PCs (right hand side) that connect to a tNAC protected network. One of the policies defined for the network specifies that endpoints must fulfill the following in order to get complete access:
For the mobile laptops, a VPN gateway acts as Policy Enforcement Point. One of the laptops fulfills the defined policy and gets complete access to the network (marked green). The other one violates the policy in several cases and is only allowed to access the isolated area of the network (marked red). Remediation is supported by the Remediation Server.
Almost the same applies for the stationary desktop PCs (one is policy compliant, the other is not). In this case, an edge switch acts as Policy Enforcement Point.
One of the most challeging tasks within tNAC is to ensure that the Access Requestor does not lie about its real security state.