D3.9: Study on the Impact of Trusted Computing on Identity and Identity Management

Title: TRUSTED NETWORK CONNECT (TNC) SPECIFICATION OVERVIEW

Trusted Network Connect (TNC) Specification Overview

In May 2004 the TCG published the first specification [98] from the Trusted Network Connect (TNC) Work Group. This specification should be a vendor independent network standard that enhances network security by combining network access control with trusted computing. The goal is to integrate the concepts of trusted computing with existing network access control mechanisms. 

Concept of Trusted Network Connect

The overall goal of TNC is to prevent compromise of the hosts that connect to a network or other network resources and thus the network itself. The specification suggests platform authentication through a proof of identity in combination with the integrity status of the platform that wants to connect to a network. 

Therefore network access control is based on extended attributes like platform authentication (e.g. by using an AIK), endpoint compliance or software state information which are collected as described in section 3.1.4 and attested to a remote verifier. Based on the integrity information reported by the platform and its proof of identity the verifying instance is able to decide whether it is save to extend the network to that platform.

This kind of network access requires an extension of existing network access policies concerning endpoint compliance, network access, assessment, isolation and repairing. The endpoint compliance policy should establish a level of trust by ensuring that a machine that actually gets network access has a certain software state, e.g., that its operating system, services and applications are of specific versions and running properly. The access policy should also handle machine and/or user authentication before granting network access. A policy for assessment, isolation and remediation should ensure that machines that do not comply with security policies will not be able to get network access and are eventually repaired to meet the security policy requirements again in order to be able to regain network access. This can be done by isolating them in an separate network environment which only allows access to a special server that provides software or virus signature updates for the infected client. Since TNC should integrate with conventional network access control solutions it uses a common three party model consisting of an Access Requester (AR), a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP) as presented in figure 6. The AR might be a VPN Client or 802.1X Supplicant that requests access to a protected network. The AR’s request is processed by a PDP which might be a software component of a RADIUS (Remote Authentication Dial In User Service, see RFC 2865 and RFC 2866) server that validates the information provided by the AR (including platform authentication and integrity credentials) against previously defined network access policies. These policies should include integrity and identity aspects of the requesting platform. The PDP reports its decision (access granted or denied) to a PEP which might be a VPN gateway, switch, firewall or 802.11 Access Point that actually allows full or partial network access or denies it completely according to the PDP’s decision.

Fig6: The TNC Three Party Model 

TNC also aims to enhance existing authentication, authorization and accounting (AAA) protocols developed and standardized by the IETF such as RADIUS or Diameter (RFC 3588) by adding the ability to measure and report the state of the endpoint platform as part of the authentication and authorization process.

Currently Supported Technologies

There are several technologies available that provide support for the TNC architecture. These include network access, message transport and authentication server technologies of which an overview will be given in the next paragraphs like 802.1x [78].

IEEE 802.1X 

IEEE 802 [78] refers to a family of IEEE standards about local and metropolitan area networks. The IEEE 802.1 set of standards (collectively named 802.1X) are mainly concerned with port-based network admission control. 

Since TNC has been developed with respect to 802.1X the three party model presented in figure 7 matches to the model of IEEE 802.1X. The TNC AR corresponds to the 802.1X Supplicant which requests access to a network port at an Authenticator which maps to the PDP in the TNC model. The Supplicant will then be authenticated by an Authentication Server that is equivalent to the TNC PEP based on previously defined access policies. TNC will enhance 802.1X in the way that the Supplicant authenticates to the Authenticator by using a TPM protected authentication token (e.g., an AIK) and attested integrity measurements (see section 3.1.4) which should provide evidence of the Supplicant’s current system state. The Authenticator then verifies this information and validates it against given policies. 

Extensible Authentication Protocol 

The Extensible Authentication Protocol (EAP) as defined in RFC 3748 has been originally designed to transport authentication information in the context of PPP and dial-up services. Today EAP is also used in the context of 802.1X and other scenarios. Some EAP methods enable the transportation of integrity measurement information for use with mutual platform authentication. These are especially TLS based EAP methods (like EAP-TLS or PEAP) which can be extended by using the TLS-Attestation Extension protocol. 

Virtual Private Networks 

Virtual private networks (VPN) are virtual communication networks usually used to communicate securely over a public networks like the Internet. Many VPNs use the IPSec protocol to achieve authenticity, integrity and confidentiality of the transported data. IPSec often uses the Internet Key Exchange (IKE) [48] protocol for authentication and key exchange purposes. IKE can be enhanced by communicating integrity information as part of the mutual authentication and key establishment by adding integrity reporting after the IKE peers have authenticated. The next version of IKE, IKEv2 [65], supports EAP-based messages for peer authentication which can be used in combination with other EAP based approaches proposed by the TNC architecture that will be described below. 

Despite of IPSec-based VPNs there are also SSL- or TLS based VPNs. TLS provides security services on the transport layer. This protocol is mainly used to secure the communication between web servers and browsers by offering authentication and confidentiality. TLS can be enhanced to provide endpoint integrity by the TLS-Attestation Extension [99] protocol for delivering integrity measurements between client and server.

Point-to-Point Protocol 

The Point-to-Point Protocol (PPP) is commonly used to establish a direct connection between two nodes and is used by most Internet service providers for dial-up access to the Internet. Typically EAP is used over PPP to transport security related parameters which enables the use of the EAP-based approach described by the TNC that will be presented below. 

Transport Layer Security 

As already mentioned above, TLS can be extended for using integrity measurements for authentication purposes through the TLS-Attestation Extension protocol. TLS and SSL can be used to secure application-related communication including various web services protocols like SOAP. Thus HTTP can also be used to transport integrity measurement information when protected by TLS.  

RADIUS and Diameter  

RADIUS (RFC 2865) and Diameter (RFC 3588) are standardized authentication protocols. As already described above, RADIUS is a widespread authentication protocol which has been considered in the development of the TNC architecture. Extensions for Radius to support EAP are defined in RFC 3579 which enables the use of EAP for transporting integrity measurement information between the Clients (TNC AR), the Authenticator (TNC PEP) and the Authentication Server (TNC PDP). 

Diameter is an alternative to Radius. It uses attribute value pairs (AVP) to deliver various payloads relating to user authentication, service authorization, resource usage, etc. The Diameter protocol can be extended by adding new AVPs. Therefore it can be enhanced by introducing a new AVP for carrying integrity measurement information from the AR to the PDP.