Naked endpoints on your net, and what to do about them
Naked endpoints on your net, and what to do about them

A "naked endpoint" is a system attached to your network that lacks a management agent, like a network access control (NAC) agent, used to obtain information for an access control decision. In your network, you most likely have a variety of endpoints that lack this capability, such as printers, VoIP phones, IP-enabled door locks, HVAC systems and more. The commonality of these clientless devices is they are typically not associated with a single user and have machine-centric operating systems that do not readily accommodate a third-party agent. Common practice is to manage around these devices, setting their network ports to open connectivity which circumvents the security provided by your NAC implementation. 

If you've deployed a NAC solution based on standards such as the Trusted Computing Group (TCG) Trusted Network Connect (TNC), you likely have agents installed on the managed systems, but not on your naked systems. You're getting benefits from the client installations, but you're likely to have statically provisioned access controls at best for your naked endpoints. Many end-users have been looking for a mechanism to dynamically provision access control for clientless systems, but vendors do not offer a standard method to perform this basic task, often implementing different methods across product lines. By lacking a standard configuration, it is difficult to ensure that the security configuration you architected is the one that you've implemented. Well you're in luck, because the TCG Trusted Network Connect Work Group has provided a new standard to assist in such a task – the TCG/TNC Clientless Endpoint Support Profile.

The TNC Clientless Endpoint Support Profile, CESP for short, provides a standardized schema to assist in admitting endpoints, such as printers, that lack a TNC client to your TCG/TNC-compliant network access control solution. While you may be statically managing this access today, what is the cost of managing that access—and how long do your clients wait for that access to be provisioned? As previously mentioned, lacking a standards-based approach increases the cost of managing these clients and provides risk of gaps in your security posture. By implementing a standards-based approach to admitting and controlling clientless systems, there is one configuration common across vendor products. This reduces the cost of managing multiple proprietary configurations to allow the network to accept and provision control for your clientless endpoints.

We're not talking just about costs here; it is also about managing your security posture. With a static implementation such as configuring the printer ports to a printer VLAN, any device plugged into that port has unchallenged access to the printer VLAN. This may sound rather benign – it is a printer. How much access does it have anyhow? Consider this: Other clientless devices are IP security cameras, VoIP phones, and IP-enabled door locks. The growth of clientless devices, and the percentage of network ports being statically configured, provides a growing number of security domains that would allow any device unchallenged access. This can have consequences, not just to our security posture but also compliance with industry regulations. This next part will explain how to put this to use in your network.

TNC Clientless Endpoint Support Profile version 1.0 provides an overview of the many different access request mechanisms for network-based access control. In the standard TNC model, the access requester is an endpoint with a TNC Client. TNC CESP provides a mechanism for systems that lack a TNC agent. In TNC CESP, there are two access requesters, endpoints that seek authorization via a TNC Client or supplicant such as 802.1X and policy enforcement points (PEPs) that support machine-based authorization using the endpoint's MAC address. Working with a standard such as 802.1X is straight forward. The options are well documented and policy decision points understand how to authenticate and authorize endpoints using it. However when using a system's MAC address as an identity, the PEP becomes the access requestor on behalf of the endpoint. This is an area where the TNC Clientless Endpoint Support Profile provides benefit.

Many vendors have a variety of systems to authorize a port based on the endpoint's MAC address, and that variety is the problem. You may have heard terms such as "MAC-bypass" or "MAC authentication." They work a little differently, but one thing is common – they are using an authentication mechanism to authorize an endpoint. TNC CESP identifies these MAC authorization systems, and the 1.0 standard guides vendors to a preferred method based on examples in RFC 3580. By using a standard method of authorizing an endpoint, NAC vendors will gain greater interoperability with network infrastructures and provide greater stability and choice. Implementing a standard eases the transition from statically provisioning the network to authorizing every endpoint. A basic transition would look like this.

Identify your endpoints. Let's start with those printers. You have two basic options, accept all printers based on their organization unique identifier (OUI), the first half of the MAC address which generally identifies the device manufacturer, or you could individually accept only printers identified to your network. The first option is easier to deploy (you don't need to inventory your systems) but is not as rigid as individually accepting each system based on a known list. The second option being more rigid will require change control mechanisms (add/deletes) to your NAC database. You have the option of deploying the system in a way that best suits your solution.

After you've identified the naked endpoints that you want to allow on your network, you start by identifying the access control enforcement method you'd like to use and what access those systems will have. Implementations vary by vendor and the TNC CESP identifies the following authorization mechanisms; allow/deny, authorize to VLAN, authorize to Filter-ID. Each of these options impacts your solution differently.

Consider the "allow/deny" option. This option is good if you want to secure provisioned ports to the devices that are supposed to be there. In our printer example, a person unplugging a printer and attaching another device will not be able to access the printer network without purposely reconfiguring their device to clone the MAC address of the printer that was attached. However, this option lacks the capability to dynamically configure the network port (PEP) to service the particular needs of each device.

The VLAN and Filter-ID options provide the same control options as allow/deny, but also provisions the network port (PEP) to support the device attached, based on its identity. This would allow a port with a printer attached to dynamically configure to serve the needs of a network-attached scanner or other network-attached office equipment, reducing operational burden. The Filter-ID option allows for vendor-specific implementations such as VLANs and port-based access control lists (ACLs) to be deployed at the access device, providing greater control at the network access layer.

This is just a quick review of the authorization options in the TNC Clientless Endpoint Support Profile. Left to discuss is an option in TNC CESP that integrates your policy decision point (PDP) with additional systems to extend the clientless network access control solution: TNC IF-MAP. TNC IF-MAP is a standard that allows for data sharing between TCG/TNC systems. In the CESP example, you may have an endpoint profiler that scans systems on your network. This profiler would identify systems and determine a normal operating state. If a system would appear to be running extra services, such as a laptop cloning a printer for access, the profiler would make that information available to the PDP via TNC IF-MAP protocol. This allows a greater level of control when implementing a clientless NAC solution, helping to detect false endpoints.

To summarize:

  • TNC Clientless Endpoint Support Profile provides a standard for authorizing endpoints that lack a functioning TNC client for the domain
  • MAC authorization defined in CESP, offers a mechanism to reduce operational expenses of provisioning NAC for systems without clients
  • Authorizing all the endpoints provides greater visibility to what systems are accessing the network and level of access they have
  • These techniques improve your security posture by authorizing all systems, providing additional benefit of generating logs that can be used in compliance reporting

More information on the TNC Clientless Endpoint Support Profile can be found at the Trusted Computing Group's website,, in the Trusted Network Connect Work Group pages.